Office: (Office 2010) Transactions

Bei Daten in einem lokalen (temporären) Backend hast Du ganz allein die Kontrolle und störst keine möglichen Mitbenutzer der Datenbank. Das lokale Backend könnte mit allen wesentlichen Detail vorbereitet sein, so dass nur ein Kopieren an einen definierten Speicherort und ein Verknüpfen der Tabellen notwendig wäre, was kaum Aufwand darstellt. Mit einer Kaskade von Anfügeabfragen schiebst Du dann die zu bearbeitenden Daten (oder Portionen davon) in dieses Backend, bereitest Alles auf und führst innerhalb einer Transaktion je nach Gegebenheit und Deinem Regelwerk Aktualisierungs-, Lösch- und Anfügeabfragen aus. Ggf. nimmt man sich jetzt die nächste Portion vor.

Nach dem Kappen der Verknüpfung kann danach das lokale Backend von der Platte wieder gelöscht werden.

Die Tatsache, dass Etwas programmatisch zu bewerkstelligen ist, muss nicht heißen, dass dieses Etwas auch gut ist. Nun, die Entscheidung für einen Weg musst Du natürlich selbst treffen.

 

Hi Wof,

bezüglich des Events. Es kann sein, dass Du zuerst was in einem UF ausführst, das einen Bezug zum HF hat und dadurch der Event im HF blockiert wird bis du zum Beispiel eine andere Akton im HF machst. Da reicht auch schon mal ein klick in ein UF oder woanders hin. Hatte ich mal und der Fehler äußerte sich ähnlich.

FG
trekking

 

\@Nouba: Mir schien die Verwendung von Transaktionen naheliegend, weil sich meist nur ein einziger Benutzer in der DB befindet, der diese spezielle Datenpflegefunktion durchführt. Andere Nutzer haben erst gar keinenZugriff auf diese Funktion.

@trekking: Hi. Interessant. Aber die UFos haben bisher keine einzige Event-Routine. Die Datenquellen sind Tabellen und die Verknüpfungen sind ID-Felder im HF vom Hauptdatensatz. Mir ist das völlig schleierhaft...

 

Steht in den Formular-Eigenschaften beim entsprechenden Ereignis [Ereignisprozedur]?

Mich würde nebenbei interessieren, um welche Art Daten es sich handelt,
da mir die Vorstellungskraft für ein Szenario fehlt, bei dem Änderungen an
einem Hauptdatensatz und mehreren verbundenen Unterdatensätzen
vorgenommen werden, die letztendlich wieder verworfen werden sollen.

Für den Fall einer Umsetzung, würde ich persönlich eher eine Lösung mit
temporären Tabellen oder, noch wahrscheinlicher, mit disconected Recordsets
bevorzugen.

 

\@Marsu. Äh... das weiß ich jetzt gar nicht. Kann sein, dass ich die Prozedur Form_Open im VB-Editor angewählt habe. Aber damit steht es doch wohl auch automatisch in den Eigenschaften des Formulars, oder?
Leider hab ich grad keine Möglichkeit, das zu prüfen, da ich die nächsten Tage nicht an diesem Arbeitsplatz sein werde.
Dennoch werde ich versuchen eine Möglichkeit für dieses Multiformular-Undo auszutüfteln.

Art der Daten und Szenario ist dies:
Es werden Rezepturen verwaltet. Es gibt 3 Tabellen mit Zutaten:
A) Grundsubstanzen
B) Zusatzmittel
C) Weitere Zusätze
Es gibt eine Tabelle für die Rezepturen und deren Stammdaten, wie Name, Erstellungsdatum, Bearbeiter, etc. und drei Verweisen auf die Materialtabellen.
Ein Rezept besteht aus
a) einem oder mehrerer Grundsubstanzen die mit Mengenangaben in der A Tabelle notiert sind
b) einem oder mehrer Zusatzmittel die in der B Tabelle gespeichert sind (ebenfalls mit Mengenangaben)
c) einem oder mehreren weiteren Zusatzmitteln, die in der C Tabelle stehen

Das Formular zeigt eine Rezeptur, deren Stammdaten (Rezepturname, Erstellungsdatum, Rezepturnummer, etc.) und 3 UFos für die Bestandteile
Die UFos zeigen jeweils in einem Grid eine Liste von Bestandteilen und Mengenangaben.

Wenn ich also eine Rezeptur anzeige, kann ich z.B. ein Zusatzmittel hinzufügen, oder z.B. die Mengenangabe von einer der Grundsubstanzen ändern, oder sogar eine Zusatzsubstanz ganz herauslöschen.
Im aktuellen Formular kann ich mit dem CancelButton eben nur Änderungen an den Stammdaten zurücknehmen. Wär jedoch schön, wenn damit auch die Änderungen an den 3 Materialtabellen zurückgenommen werden könnten.

Äh... disconnected Recordsets? Meinst Du Recordsets, die ohne Tabellen oder Abfragen einfach so mit Daten gefüllt werden? Kenn ch zwar, hab aber noch nie damit gearbeitet. Ebenso sind mir der Umgang mit den Änderungs und Anfügeabfragen nicht so sehr vertraut.
Was mach ich, wenn in der A-Tabelle ein Datensatz geändert, in B einer gelöscht und in C einer geändert und einer hinzugefügt wurde? Wie erstelle ich dann die Aktionsabfragen? Ist recht kompliziert, scheint mir.
BeginTrans und Rollback schienen mir da einfach äh... einfacher.

 

Ich hab mal eine ganz einfache Beispiel-DB erzeugt, die die Situation und die Erfordernisse aber ziemlich exakt wiedergibt.
Ich denke, ein Beispiel sagt mehr als 100 Worte Beschreibung.
Das (rasch zusammengeschossene) Formular zeigt die jeweilige Rezeptur und deren Bestandteile.
Die Buttons haben hier noch keine Funktion, dienen nur der Verdeutlichung, wo ich hinwill.
Bitte schauts euch mal an und sagt was dazu.
Im Moment mach ich im Verwerfen-Button einen Me.Undo, wodurch alle Änderungen an den Stammdaten zurückgenommen werden, nicht aber die an den Unterformularen (und deren Tabellen).

 

Hi Wof,

nach Deiner Beschreibung würde stimme ich Marsu zu und würde disconnected recordsets nehmen. Diese kannst Du ja entsprechend bearbeiten. Also Datensätze hinzufügen und löschen. Macht Dein User Cancel, dann würdest Du einfach die UFOS wieder mit den Disconnected RS füllen. Will Dein User aber speichern, dann reconnectest Du und schreibst die Daten in die Tabelle.

Das gleiche würde auch mit temporären Tabellen im Frontend gehen. Der wesentliche Vorteil davon ist (wie bei den DiscRS), dass es in einer Mehrbenutzerumgebung ohne Probleme verwendbar ist.

VG
trekking

PS: Habe Dein Beispiel nicht angesehen, da ich leider jetzt keine Zeit habe. Sorry

 

\@wol,
den Tabellenaufbau würde ich ganz anders gestalten:
Tabelle Zutaten
Tabelle Rezepte
Tabelle mit Verknüpfung von Rezepten und Zutaten und Verhältnisse, Reihenfolge usw.

Solange es von den Entitäten her geht - und hier geht es auf alle Fälle - gibt es nur eine Tabelle für die Definition der Zutaten.
Alles andere ist Wahnsinn, sobald ein System minimale Komplexität erreicht.

Bezüglich Rezepten kann man natürlich verschiedene Wege gehen.
Die Frage wäre für mich, wie die Rezepte entstehen.
Überlegt man sich die, wenn man das Rezept erstellt, oder existiert es bereits und wird nur gespeichert?

Ich würde ein Rezept, dass getestet wurde nicht mehr ändern.
Das Ergebnis des Rezeptes wird dokumentiert und dann wird ein neues Rezept mit veränderten Zutaten erstellt.
Dazu kann man ein bestehendes einfach kopieren und verändern.
Weil was für einen Sinn hat eine EDV mäßige Verarbeitung, wenn man keine History mit Bewertungen für die verschiedenen Zutaten eines Rezeptes macht.

Edit:
Transaktionen sind in diesem Kontext wie mit Kanonen auf Spatzen schießen.

 

Tja, ich würds gern etwas genauer erklären.
Wenn ein Rezept erstellt wird, werden Grundzutaten aus einer Tabelle existierender Bestandteile ausgewählt. Die Zusatzmittel kommen aus einer Tabelle existierender Zusatzmittel. (Ich hätts auch etwas anders gestaltet, aber so isses nunmal).
In meinem Beispiel hab ich die Tabellen mit existierenden Bestandteilen nicht integriert. Wozu auch. Das Problem ist ja, die Änderungen aus den Bestandteiltabellen rückgängig machen zu können.
Des weiteren ist die Anordnung und Verknüpfung der vorhandenen Tabellen nicht unbedingt verkehrt, wenn mans logisch betrachtet.

Ich hab halt in meinem Exempel versucht, die relevanten Strukturen zu isolieren und aufzuzeigen, wo ich ansetze. Da sind die Tabellen, auf die es ankommt und die Verknüpfungen, und die kann ich nicht ändern.

@markus: Ist im Prinzip schon so, wie Du es sagst.
Tatsächlich werden Rezepte neu erstellt und von vorherigen Versionen abgeleitet, aber die letzte Version unterliegt halt immer Änderungen: Ach nein, wir lassen die Olive beim Martini weg, nehmen statt weißen den roten Martini.
Voila, Martini 3.0.
Ach neee, wir nehmen statt der Olive ne Kirsche. Also Änderung an Martini 3.0.

@trekking: Wie würde ich das mit den disconnected recordsets denn anstellen? Der Begriff ist mir nicht so geläufig. Ich kann mit Recordsets zwar umgehen, aber was macht diese disconnected und wie reconnecte ich die?

 

Hi Wof,

liest Du hier

http://donkarl.com/Downloads/AEK/AEK9_RecordSets.zip

Allerdings ist das in der Regel für eine Frontend/Backend Version gedacht. Ich glaube irgendwie, dass es bei dir mit Temporären Tabellen einfacher gehen würde.

VG
trekking

PS; Sorry hatte immer noch keine Zeit das BE anzusehen, aber das hat Markus ja getan *Smilie

 

Dann versuche doch mal, von einem Deiner Unterformulare in Deiner Erzeugung ein Recordset abzunehmen oder zuzuweisen.

Meine Empfehlung: Wenn man Formulare und deren Eigenschaften, Ereignisse und Methoden verwenden will, sollte man auch Formulare als Unterformulare in ein Hauptformular einbinden statt nur Tabellen einzukleben.
Bei dem angezeigten Arbeitsfortschritt sollte zudem ein Fertigstellungstermin nicht für die nähere Zukunft anvisiert werden.

 

Nur komisch, dass das aus deinen Ausführungen und dem Beispiel gar nicht hervorgeht.

[QUOTE
Ach neee, wir nehmen statt der Olive ne Kirsche. Also Änderung an Martini 3.0.[/quote]

Da reicht es doch einfach eine Eingabe zu korrigieren, ohne alles andere zurückzusetzen.

 

\@Markus: Richtig. Aber wenn Du es nachliest, haben wir in meinem Beispiel die Olive zuerst ganz weggelassen. (Eintrag aus Tabelle 3 gelöscht).
Und jetzt fügen wir ne Kirsche hinzu. (Neuer Eintrag in Tabelle 3).

Ich weiß nicht, obs irgendwie klar wird. Wenn ich gerade dabei bin, den Martini zu editieren und die Olive gerade gegen ne Kirsche ausgetauscht habe, und mir dann denke: Neinneinnein, das will ich doch nicht. Cancel. Zurück. Nochmal von vorne. Egal, was ich sonst noch geändert habe. Nochmal drüber nachdenken. Etc. pp.
Cancel drücken und zurück zum Ausgangspunkt, als ich Ändern gedrückt hatte. Das ist das Ziel. Ob ich nun eine Zutat oder den Rezeptnamen geändert hab.
@ebs:

Was soll das bedeuten? Ich hab doch Unterformulare als Unterformulare eingefügt. Deren Datenquellen nunmal auf Tabellen verweisen.

Wahrscheinlich wirst Du mir jetzt wieder erklären wollen, ich sei irgendwie dumm, aber ich versteh wirklich nicht, was Du mir damit sagen willst. Konstruktiv klingt es jedenfalls nicht.
Mein Beispiel sollte nur aufzeigen, wie die bestehenden Daten miteinander verknüpft sind.

@trekking: Prima, danke. Jetzt weiß ich, wie man einen "disconnected recordset" herstellt. Man erzeugt ihn über ActiveConnection und setzt diese anschließend zu Nothing. Das ist sehr aufschlussreich. Wusste ich noch nicht. Aber wie krieg ich das jetzt "reconnected" und die getanen Änderungen an den Recordsets wieder in die Tabellen gekleistert? Abspeichern in Textdateien nutzt mir da nichts.

 

P.S.: @trekking: Das mit den temporären Tabellen schwirrt mir momentan auch als plausible Lösung im Kopf herum.
Mir ist nur nicht ganz klar, wie ich die Änderungen an den temporären Tabellen wieder in die tatsächlichen Tabellen zurückbringe.
Es kann ja sein, dass ich in Tabelle 1 nur einen Eintrag geändert, inder 2 einen gelöscht und in der 3 einen hinzugefügt habe.
Ich bin noch nicht so versiert, dass ich das jetzt ad-hoc mit Änderungsabfragen hinbekäme.

 

Hi Wof,

das schreibst Du anhand des Schlüssels zurück. Gehe davon aus, dass Du die neuen Werte behalten willst. Du hast aus deiner 1 - Tabelle ja den Schlüssel.
Hier nutzt du dann eine Transaktion.
Also Beginn trans
Dann löschen aller vorhanden Datensätze auf den n-Seiten.
Nun mit SQL die Temporären Tabellen unter dem Schlüssel entsprechend mit SQL und execute einfügen.
Commit trans

Gibt es einen Fehler, dann bircht er ab und Du hast immerhin den Urpsrungsdatensatz erhalten. (Dazu musst du aber unbedingt roll back in die Fehlerbehandlung schreiben um es sauber zu beenden.

Wegen des Disconnected Recordsets. einfach die Connection wieder öffnen und dann updateBatch machen. Allerdings wirst du ihn dazu als Objekt speichern müssen, was in einer Klasse sehr gut geht.

VG
trekking

PS: Lass dich von Eberhard nicht ärgern. Hatte auch schon meien Spaß mit ihm. Allerdings muss ich sagen, dass er mir trotzdem an einigen Stellen schon geholfen hat und daüfr bin ich ihm dankbar. Und er war ob meiner Kommentare auch nicht nachtragend. Auch dafür Danke *Smilie