Office: (Office 2010) Transactions

\@trekking:
Ich bin auch nicht nachtragend und freu mich durchaus, dass er trotz der Kontoverse weiterhin mit mir spricht. *wink.gif*

Aber, Moment mal. In Deiner Antwort: Nutze ich jetzt BeginTrans/CommitTrans/Rollback, oder die temporären Tabellen, oder die disconnected Recordsets? Klingt als würde ich alles zugleich nutzen.

Lass mal rekapitulieren: Temp-Tabellen:
Ich lade die Daten für die Unterformulare vor dem Anzeigen (in Form_Open oder Form_Load) z.B. mittels Abfragen in temporäre Tabellen (oder auch mit einfachen SQL Executes "Insert Into"). Dann kann ich machen, was ich will.
Click auf Cancel, mache ich Me.Undo und verwerfe die temp. Tabellen.
Click auf Save, dann kann ich mit SQL-Delete die alten Datensätze löschen und mittels SQL-Insert Into die geänderten einfügen.
Das klingt nach nem Plan, den ich auch durchaus kapiere.

Das mit den disconnected Recordsets interessiert mich trotzdem auch.
Wenn ich da Cancel drücke, ist klar: Die geänderten Recordsets werden verworfen und neu geladen.
Und bei Save hab ich aber noch nicht verstanden, was passieren muss: Wie mach ich das "die Connection wieder öffnen und updateBatch machen"?

 

Hi Wof,

Deine Rekapitulation ist fast i.O. *Smilie

Die Temporären Tabellen würde ich mit Execute füllen. Am besten in Form Load aufrufen und in einer eigenen Sub (oder Function mit Bool als Rückgabe) abarbeiten. Zuvor natürlich die TempTabs leeren.

Hat der User Änderungen gemacht und will diese verwerfen, dann einfach die Sub (Function) wieder aufrufen und alles ist wie vorher. (Also kein Undo)

Sollen die Änderungen gespeichert werden, dann musst Du dies in einer Transaktion kapseln, da Du ja die alten Datensätze löschen willlst und neue einfügen. Machst Du dies ohne Transaktion und ein Fehler tritt auf sind die alten Daten schon weg und ncoh keine neuen drin (zum Beispiel)

Bezüglich updateBatch kannst Du google bemühen und wirst einige gute Englsiche Beiträge finden *Smilie

Hoffe es ist jetzt klarer *Smilie

VG
trekking

 

Noch nicht völlig.
Das Undo wirkt ja nur auf die Daten im Hauptformular.

Und das Speichern soll dann so aussehen?
...BeginTrans
Execute "Delete * from Rezeptur Where RezepturNr="&CurrentRez
Execute "Insert * From TempTable Into Rezeptur"
..commitTrans
Nur so proforma. Ist noch präzise auszuformulieren.

 

Hi Wof,

ein Undo gibt es dann im HF. Allerdings arbeite ich immer komplet ungebunden und da spar ich mir sowas. *Smilie

Dein Proforma ist in Ordnung *Smilie

VG
trekking

 

\@trekking,

Komplett ungebunden heißt aber auch Verzicht auf eine Datenblatt- und auf eine Endlosformulardarstellung - oder wie ist der Hinweis auf Deine wiederholt betonte Arbeitsweise zu verstehen?

 

\@Nouba
Warum heißt komplett ungebunden verzicht auf Datenblätter oder Endlosformulare?
Dazu kannst Du disconnected Recordsets benutzen *Smilie
Geht wunderbar.

Der Hinweis war eher darauf bezogen, dass wir zuvor über Disconnected RS geschrieben hatten.

VG
trekking

 

\@trekking,

man müsste sein Verständnis für den Begriff gebunden definieren. Für mich gilt ein Formular als ungebunden, wenn weder sein RecordSource noch sein Recordset verwendet wird - Dein Verständnis des Begriffs dürfte wohl nicht mit dem meinen deckungsgleich sein. *Smilie

 

Unter ungebunden verstehen einige ein Formular, wenn es zur Laufzeit an keine Datenquelle (Tabelle / Abfrage / Recordset) gebunden ist => Eigenschaft RecordSource. Typisch für ein gebundenes Formular ist dann, dass Steuerelemente des Formulars (Detailbereich) an Felder der Datenquelle gebunden sind => Eigenschaft ControlSource.
Welcher Zustand da beim Öffnen des Formulars oder der Datenbank selber vorliegt, ist da uninteressant.

Ohne RecordSource hat man keine Records (Datensätze), die man sehen, editieren, anlegen usw. könnte. Datenblätter und Endlosformulare funktionieren über Datensätze, während ein Einzelformular auch einen Haufen an ungebundenen Feldern beherbergen kann.

Verstehst Du das gleiche unter ungebunden?

 

@trekking1,
hast du denn schon mal Batch Aktualisierungen in Verbindung mit einem Access Formular eingesetzt oder zumindest getestet?
Kann ich mir nicht vorstellen. *Smilie

 

DonKarl arbeitet da mit ADO Recordsets, nicht mit den hauseigenen DAOs. Würde das mit den "eingebauten" DAO Recordsets auch gehen? Oder haben die diese ActiveConnection-Eigenschaft nicht?

 

\@Wof
M.W. geht das nur mit ADO recordsets. Zumindest habe ich bisher noch nichts in DAO gesehen oder gelesen. Kann es mir auch nicht vorstellen.

@Nouba
Ja dem stimme ich zu, dass wir das different sehen. Es kommt wohl auf die Betrachtungsweise an. Sehe ich mein FE als ungebunden von einer Datenquelle oder sehe ich das Formular als ungebunden von einer Datenquelle (Tabelle, Abfrage, Recordset) Meine Sichtweise ist die des FE ohne Datenquelle. Also ob ich zum Beispiel eine dauerhafte Verbindung zu einem SQL-Server offen lassen muss,, da ich Tabellen per ODBC eingebunden habe oder eben mir die Daten dann hole wenn ich diese benötige (von wo auch immer). Wenn Ihr mir (Du und Ebs) aber sagt, dass es sich ausschließlich und nur auf Formularebene beziehen darf, dann werde ich meine Schreibweise da gerne anpassen. *Smilie

@markus
Habe das eher anders gemacht. Disconnected Recordset als Objekt in einer Klasse gespeichert. Diesen dann verändert. Also Werte hinzugefügt, gelöscht etc. Jeweils dem Datenblatt den dRS zugewiesen und dadurch aktualisiert. Anschließend den dRS wieder connected und ein update gemacht. Allerdings hat sich dann noch einiges dazuergeben und ich habe den dRS quasi nur wie eine Temp Tabelle benutzt um die Anzeige flotter zu aktualisieren anstatt die Ganzen Daten wieder vom Server herunterzuladen. Gehört also nicht zu meinem Standard *Smilie
Mit einem Tabellenblatt habe ich folgendes gemacht. Den dRS wieder als Objekt in einer Klasse eingelesen und ein zusätzliches Ja/Nein Feld eingefügt, das in der ursprünglichen Tabelle nicht da ist. Der Benutzer kann dann das ja/nein Feld entsprechend anklicken und ich kann den dRS Durchlaufen um bei den DS eine Aktion zu starten die mit ja geflagt sind. Da gabs kein UdateBatch (Denke wäre aber möglich), ist aber total interessant das so zu machen, da es interessante Möglichkeiten bietet. Denke das kommt Deiner Frage ziemlich nah *Smilie

VG
trekking

 

Entschuldige, trekking, aber eurem elaborierten Code kann ich nicht mehr ganz folgen.

Kann ich mir nur vorstellen, wenn das Recordset nur einen Record enthält. Ansonsten, wie willst Du wissen, wieviele Records da drin sind und wie handhabst Du das in Klassen?

Anyway, um mal wieder auf meine Problematik zurück zu kommen: Dass ich ADO benutzen muss, wirft folgende Fragen auf:
a) welche Library benutze ich?
In meinen früheren VB6-Projekten war das die "Microsoft Active X Data Objects 2.8" (oder so) library.
b) ist die auf meinem Zielcomputer überhaupt vorhanden? Hab ich nämlich noch nicht getestet. (Und kann es vorerst auch nicht, bis ich wieder dort am Computer bin).
c) Was, wenn nicht? Kommt die automatisch mit Office? Auf meinem Computer sind die natürlich alle drauf, weil ich VB6 installiert hab.
Da sind auch noch so Sachen wie "Microsoft Active X Recordset 6.0 (oder so)" dabei, die ich noch nie genutzt habe.

 

Hallo,

also, das dauert ja jetzt schon ganz schön lange bis da was zustande kommt *grins
Habe dir mal eine BDB zusammengestellt...

Ich kenne Eberhard schon sehr, sehr lange und habe ihn schon mein Herz geschlossen *Smilie.
Also, bitte nicht so deftige Worte. Er hat das nicht verdient.
Er ist ein sehr intelligenter Mensch und man muss seine Interpretationen
eben verstehen versuchen und nicht gleich einen Angriff auf sich selbst vermuten!

Zurück zum Thema, ich habe dir in die BDB nur eine Ufo eingestellt sowie auch nur einen Button.

Diesen Edit- oder Save-Button verstehe ich nicht.
Was ich nicht sichern muss, muss ich auch nicht durch einen Button extra noch bedienen
sowie auch den Edit-Button... für was... entweder darf man oder darf man nicht und das
kann/darf aber nicht von einem Button abhängig sein *wink.gif*
Aber, wie du möchtest... das ist eben nur eine "Rollback-Version"
Habe es nur kurz getestet, also... das ist nun deine Aufgabe, falls sie dich interessiert
ist es gut, falls nicht ist es für mich genauso gut *Smilie
Sie funktioniert jedenfalls.

PS: ach ja, neue DS werden natürlich nicht rückgestellt... auf was denn dann auch *Smilie
würde dann nur auf eine Löschvariante hinausführen... was auch möglich wäre.

 

Hi Wof,

brauchst Du auch nicht *Smilie. Das mit der Klasse ist für Deine Anwendung vermutlich eh nicht notwendig und war mehr dazu da Markus Frage zu beantworten *Smilie (Außerdem gibt es nur einen kleinen Abschnitt der Ganzen Anwendung wieder *MalZurVorsorgeSchreibeDamitNichtWiederEinerKommtUndSagtWarumDasInEineKlasse*)
Wieviele DS in dem Recordset sind kannst Du einfach über RecordCount ermitteln es ist ja nach wie vor ein Recordset ob in einer Klasse oder nicht *Smilie

Zu Deinen Fragen:
a) Hängt von Deiner Acess Version ab in 2013 die version 6.1
b) Ist in Access beinhaltet
C) erübrigt sich mit b

Würde es an Deiner Stelle trotzdem mit TempTabellen machen.

@Alfred
Bezüglich Ebs bin ich nicht ganz Deiner Meinung. Nicht dass ich Ihn nicht schätzen würde und (mittlerweile) seine Ratschläge. Ein inteligenter Mensch wie er sollte auch eine hohe soziale Kompetenz entwickeln und sich empathisch zeigen. Nicht jeder kann ihm immer gleich folgen oder sieht Dinge eben etwas differentiert. Mit einer entsprechenden Wortwahl könnte er hier sicher solche Mißverständnisse vermeiden. Aber das ist eine andere Geschichte *Smilie

VG
trekking

 

Passt schon, finde den Thread eh schon sehr lustig.
Etwas Verwirrung passt da ganz gut dazu.

LGM