ADO (automatische DB Syncronisierung verhindern)

[opfer.der.genauigkeit]

Hi,

es ist fast peinlich zu fragen, aber ich hab da 'n Problem. :oops:
Das ganze passiert mir mit den lustien dbGo-Komponenten (ADO).

Delphi-Quellcode:

  query.edit;
  query.fieldbyname( 'example' ).asstring := 'bla';
  query.close;

Meiner Meinung nach dürfte der neue Text nicht in die Datenbank geschrieben worden sein (erst nach Update bzw. ExecSQL bei Insert etc.).
Tatsächlich verhält sich das leider bei mir grad etwas anders. :gruebel:
Sobald ich einen Wert übergebe, werden die lokalen Daten mit der Datenbank syncronisiert.

Soooo .. es gibt bestimmt ne Einstellung, die ich jedes mal Hilfe lesen übersehen habe.

Danke, ich hasse es an so Kleinigkeiten hängen zu bleiben. :evil:

MfG und thx

//Edit: Crossposting im DF

[shmia]

Zitat:

Zitat von opfer.der.genauigkeit

Meiner Meinung nach dürfte der neue Text nicht in die Datenbank geschrieben worden sein (erst nach Update bzw. ExecSQL bei Insert etc.).
Tatsächlich verhält sich das leider bei mir grad etwas anders.

Wenn du recht hast, dann müsste auf jeden Fall das Event "BeforePost" gefeuert werden.
Ich würde da ein ShowMessage in den betreffenden Eventhandler setzen, um das herauszufinden.
Wenn an der Query ein DBGrid dranhängt, könnte das die Ursache für den unbeabsichtigten Post des Datensatzes sein.
Abhilfe:

Delphi-Quellcode:

DBGrid.Options := DBGrid.Options + [dgCancelOnExit]

[opfer.der.genauigkeit]

Danke für die Antwort.
Für den Benutzer werden die Daten nur in einer Baumstruktur angezeigt, die nicht
Datenbank gebunden ist.
Irgendwas übersehe ich :wall:

[shmia]

Zitat:

Zitat von opfer.der.genauigkeit

Irgendwas übersehe ich :wall:

Genau! du hast nicht überprüft, ob BeforePost und AfterPost abgefeuert wird.

[opfer.der.genauigkeit]

Doch, hab ich, aber ich habe vergessen zu sagen, dass ich das getan habe. :stupid:
Beide werden ausgeführt.

[shmia]

Zitat:

Zitat von opfer.der.genauigkeit

Doch, hab ich, aber ich habe vergessen zu sagen, dass ich das getan habe. Beide werden ausgeführt.

Also doch. Dann setze mal einen Breakpoint im Eventhandler und lass dir den Aufrufstack anzeigen.
Vorher Compiler-Option "Mit Debug-DCUs" setzen.
So kannst du raus bekommen, ob [ADOQuery].Post aus [ADOQuery].Close heraus aufgerufen wird, oder ob ein Control (DBGrid oder sonstiges) seine Finger im Spiel hat.

[opfer.der.genauigkeit]

Ich denke mittlerweile herrausgefunden zu haben woran es liegt.
Ich navigiere in der Datenmenge mit GotoBookmark.
Bei dieser Methode wird intern Resync aufgerufen.

Delphi-Hilfe:

Zitat:

Resync wird intern von den anderen Datenmengenmethoden verwendet, um die Datenmenge bei Änderungen der internen Cursorposition mit den zugrunde liegenden physischen Daten abzugleichen. In Anwendungen sollte die Methode Refresh anstelle von Resync aufgerufen werden.

Mist?
:wiejetzt:

//Edit: die Daten werden immer dann syncronisert wenn ich (abgesehen von first und next) navigiere.

[opfer.der.genauigkeit]

Da ich nur ungerne Threads von mir liegen lasse, hier die Lösung:

Das Konzept von ADO hat per Default die Einstellung für implizite Transaktionen.
D.h. werden Daten geändert, werden diese direkt in die DB eingefügt bzw. wie in meinem
Fall durch das Resync abgeglichen.

Um dies zu verhindern muss mit expliziten Transaktionen über das ConnectionObjekt verarbeitet werden.
Dies kann durch den Aufruf von ADOConnection.BeginTrans eingeleitet und bei Bedarf mit CommitTrans oder RollbackTrans beendet werden.

Ich finde diese Regelung etwas seltsam, aber ok... man kann damit leben.

Evtl. kennt jemand noch eine andere Art für eine Lösung. Vielleicht eine noch bequemere? :)

Siehe: http://www.entwickler-forum.de/webx?....0@.4a872c60/0

[alzaimar]

Hi,
Das ADO jede Änderung nach Ändern das aktuellen Records speichert, hat Nichts mit Impliziten Transaktionen zu tun. Das macht die BDE genauso, und im Übrigen jeder TDataset-Abkömmling. Das ist doch der Sinn eines TDatasets.

Versuchs mal mit:

Delphi-Quellcode:

Connection.Locktype := ltBatchOptimistic

Damit werden die Änderungen im ADO-Recordset gesammelt. Du kannst die Daten mit ApplyUpdates dann 'im Stapel', also innerhalb einer einzigen Transaktion zum Server blasen oder aber über CancelUpdates (?) wieder verwerfen.

[opfer.der.genauigkeit]

Zitat:

Zitat von alzaimar

Hi,
Das ADO jede Änderung nach Ändern das aktuellen Records speichert, hat Nichts mit Impliziten Transaktionen zu tun. Das macht die BDE genauso, und im Übrigen jeder TDataset-Abkömmling. Das ist doch der Sinn eines TDatasets.

Dass die Datensätze automatisch mit der Datenbank abgeglichen werden hat laut MS schon etwas mit impliziten Transaktionen zu tun. Zumindest behaupten das einige Artikel die ich gefunden habe.
Es geht ja eigentlich um die "Default-Einstellung".

Die Änderung auf ltBatchOptimistic hat geholfen. Hättest dich ja auch wirklich mal früher melden können. :mrgreen:
Danke