Hallo alle...

- das mit der Transaktionssteuerung ist mir klar und ist auch häufig in Gebrauch.

folgende Situation:

- ein Formular mit Eingabefeldern aus verschiedenen Tabellen.
- die Eingaben des gesamten Formulars sind in eine Transaktion gepackt.
- beim Start - StartTransaktion , beim Schließen Commit oder Rollback je nach Benutzereingabe

- innerhalb des Formulars sollte der Einfachheit halber ein neuer Auftrag erzeugt werden.
- die Erzeugung des Auftrages ist für sich eine Transaktion.

da beide Transaktionen zwangsläufig in einander verschachtelt sind, wird der Auftrag nur beim Commit der ersten Transaktion erzeugt...ist ja richtig.
---läßt sich das mit einem Trick umgehen, daß beide Transaktionen nicht verschachtelt sondern parallel laufen ?

Danke für Infos

Um Gottes willen, willst Du die Transaktion offen halten, während der Benutzer zur Mittagspause ist, sich zusäuft, ins Krankenhaus muss, dann zur Reha und schließlich in den Ruhestand? Dann ist die Transaktion bis zum Sankt Nimmerleinstag offen und blockiert alles und jeden.

Nee, nee.

Lieber so:

markieren

Code:

Daten laden.
Daten verändern lassen.
Daten speichern:
  Transaktion starten
  Prüfen, ob in der Zwischenzeit Daten verändert wurden und Konflikte lösen
  Daten in die DB
  Transaktion Committen

Alternativ kannst Du dir eine Lock-Tabelle basteln, in der die zur Bearbeitung geladenen Objekte befinden. Vor dem Laden 'zum Bearbeiten' prüfst Du, ob der Datensatz schon in der Tabelle ist, wenn ja, sagst Du 'tut mir leid, der Datensatz ist gesperrt'.

Auch das hat Nachteile, wenn eben der andere zur Mittagspause geht und bla bla bla.

Ich bevorzuge die sanfte Methode der Konfliktlösung, die nur dann auftritt, wenn mehrere Leute die gleichen Daten eines Datensatzes ändern. Und wann passiert das denn? Bei schlecht organisierten Chaosabteilungen?

Delphi bietet übrigens so einen Mechanismus mit den TClientDatasets und dem 'Reconcile-Dialog'..

prinzipiell hast Du ja Recht...

- die Form enthält mehrere Registerkarten wo Daten aus verschiedenen Tabellen eingefügt, gelöscht, bearbeitet werden.
- einige Daten sind Listen in DBGrid´s wo Daten per Append / Delete die Query verändern.
- da die Query´s gleich ein SQL absetzen muß ich das in einer Transaktion abfangen, da alle Informationen nur gemeinsam in die Tabellen eingetragen werden dürfen.

- der Gedanke mit der offenen Transaktion gefällt mir selbst nicht wirklich.

wenn ich den Inhalt der Querys erst nach 'Bestätigung' schreiben könnte wäre das Problem vom Tisch.

Seit wann kann Zeos mehr als eine Transaktion verwalten ? Habe ich was verpasst ?

Gibt es unter Zeos nicht soetwas wie 'CachedUpdates'?

Und wenn nicht, dann trenne dich von datensensitiven Steuerelementen.

Objekt laden => darstellen => verändern => Objekt speichern.

würde ich mal durchlesen :

http://www.delphipraxis.net/internal...ansaktion+zeos

Zeos lässt sich vielleicht mit FB 1.0 einsetzen, aber der Rest seit 2003/4 ?? fehlt so ziemlich.

Zitat von Hansa:

würde ich mal durchlesen :

http://www.delphipraxis.net/internal...ansaktion+zeos

Zeos lässt sich vielleicht mit FB 1.0 einsetzen, aber der Rest seit 2003/4 ?? fehlt so ziemlich.

Ich denke mal, da hast Du den von Dir empfohlenen Thread nicht aufmerksam durchgelesen.
ZEOS und Firebird 1.5 und 2.x funktionieren sehr wohl gut miteinander.
Evtl. muss man die neueste Entwickler-Version benutzen, aber es geht.

Nene, da braucht man eigentlich nur den Anfang zu lesen. Meine Bedenken gehen allerdings in der Tat noch etwas weiter als hier, insbesondere bezügl. MultiDB usw. IMHO ist es unmöglich mehrere Datenbanken gleich gut zu unterstützen, weil die eben nicht gleich sind. Sogar bei (Interbase) Delphi-IBX fehlen mittlerweile etliche Firebird Dinge. Es ging zwar auch mehr allgemein um Zeos, aber es wurde festgestellt, dass dort nur eine Transaction pro Connection möglich ist.

Jetzt lese ich das :

Zitat von haentschman:

da beide Transaktionen zwangsläufig in einander verschachtelt sind,...

Er hat sogar die Effekte genau so geschildert, wie bei Zeos zu erwarten war.