AnyDAC - FetchBlobs committed Transaktion nicht

[Cashew]

Hallo zusammen,

wir sind gerade dabei unsere Delphi 7 Anwendung von der BDE Komponente auf die AnyDAC 8.0.5 Komponente umzustellen...

Folgende Umstände sind gegeben:

• Auf dem Formular befindet sich eine TADConnection
• Die Standard Einstellungen der TADConnection wurden nicht geändert, somit ist in den TxOptions die Option "AutoCommit" aktiv
• Des Weiteren befindet sich auf dem Formular eine TADQuery und eine TADTable. Der MasterSource für die TADTable ist die TADQuery.
• Zwei TDBEdits dienen zur Anzeige von KundenNr und KundenName aus der TADTable
• In einem TDBMemo wird aus der TADTable ein Blob Text Feld angezeigt (FireBird FieldType = Blob / Size = 240 / Subtype = Text)

Beim Laden des Bolb Text Feld Inhaltes wird von den FirDAC Komponenten automatisch eine Transaktion gestart die nicht mehr committed wird!

Ist dieses Verhalten normal?
Kann man die TADTable Komponente so Einstellen, dass die göffnete Transaktion wieder committed wird ohne das der AutoCommit Modus deaktiviert werden muss?

[hoika]

Hallo,

Zitat:

Beim Laden des Bolb Text Feld Inhaltes wird von den FirDAC Komponenten automatisch eine Transaktion gestart die nicht mehr committed wird!

Ich denke, dass folgendes passiert.
Du öffnest die TTable (Open), damit wird eine Transaktion gestartet.
Solange die Tabelle geöffnet ist, bleibt auch die Transaktion geöffnet.

Lösung wäre ein ClientDataSet zum Puffern oder das Weggehen von den datensensitiven Komponenten.

Das Verhalten war aber meines Wissens auch bei der BDE schon so (?).


Mal noch schnell nachgesehen:
AutoCommit
Finish the transaction started after the SQL command execution. If the command is successful, then FireDAC will issue COMMIT, otherwise--ROLLBACK.

Zusätzlich steht noch was von "Emulation" unter IB oder FB.


Von welcher DB reden wir denn eigentlich?

[Delphi.Narium]

Kenne die Komponenten nicht, aber das beschrieben Verhalten erscheint mir unschlüssig.

Bitte überprüfe mal, ob nach dem Laden des Blobs der Datensatz eventuell automatisch (also ungewollt) in den Editiermodus geht und daher dafür bereits eine neue Transaktion geöffnet wird, deren Commit daher erst auf ein Post des Datensatzes folgt.

Schau bitte mal, was zu dem Zeitpunkt, in dem die unerwünschte und offenen Transakion vorhanden ist, in TADQuery.State steht.

Die Statuswerte lassen sich auch gut an 'nem TDBNavigator ablesen, wenn ihr den zufällig auch im Einsatz habt, dann schau mal, welche Buttons dort aktiv sind. Der Haken und das X sollten nicht aktiv sein, wenn doch, befindet sich der Datensatz im Editiermodus und die offnen Transaktion ist berechtigt vorhanden.

Desweiteren prüf' bitte mal, was zu diesem Zeitpunkt in TDBMemo.Modified steht, sollte false sein, wenn nicht, ist da die Ursache zu suchen.

Eine eher schräge Idee: Setze beim TDBMemo mal AutoDisplay auf false: Ändert sich dadurch das Transaktionsverhalten?

Auch dann wäre die Ursache für das unerwünschte Verhalten beim TDBMemo zu suchen.

(Das sind allerdings alles nur nicht verifizierte Vermutungen.)


hoika hat allerdings auch recht, beim Öffnen einer Tabelle oder eine Query wird für gewöhnlich keine Transaktion geöffnet.

AutoCommit hat nur dann eine Wirkung, wenn kein StartTransaction aufgerufen wird.

[Quitzlinga]

Hallo,

das Verhalten seitens Unidac ist normal und so voreingestellt. Um ein "Dirty Read" Verhalten seitens der DB hinzubekommen mache bitte folgende Einstellungen in den Unidac Tabellen/Querys :
1. TUniable/Query->Transaction->IsolationLevel->ilReadUncommited
2. TUniable/Query->Lockmode->lmNone
3. TUniable/Query->checkMode->cmNone;

Bei ilReadCommited ( voreingestellt ) wird tatsächlich für jedes Lesen eine Transaktion gestartet, die anschliessend selbst committed werde muss.

So würde das unter MSSQL funktionieren. Bei Firebird kenne ich mich leider nicht so gut aus. Eventuell muss noch was in den Optionen des Unidac DB Objektes eingestellt werden.

MfG

Quitzlinga

Edit : Sehe grade, das es um AnyDac statt Unidac geht. Das Prinzip sollte aber dasselbe sein d.h irgentwo in der Connection oder TAnyTable Komponenten lassen sich die Trasaaktionseinstellungen manipulieren.

[Cashew]

Hallo zusammen,

vielen Dank für die Antworten!

@hoika
Meines Wissens nach bleibt eine Transaktion solang geöffnet, bis der zugrundeliegende SQL Command abgearbeitet ist... Zumindest kann man es so bei einer TADQuery nachvollziehen. Werden über einen SQL Befehl (TADQuery wird verwendet) z.B. 500 Datensätze abgefragt und sind die FetchOptions wie folgt eingestellt: RowSetSize = 50 / Mode = fmOnDemand, dann wird beim Open der TADQuery eine Transaktion gestartet, diese wird dann erst geschlossen, wenn alle 500 Datensätze eingelesen sind. Würde ich über meinen SQL Befehl aber nur 10 Datensäte abrufen, dann würde die Transaktion unmittelbar nach dem Open wieder geschlossen, da die Ergebnissmenge (10 Datensätze) kleiner ist wie die RowSetSize (50 "Datensätze").

AutoCommit bei einer FireBird Datenbank bedeutet, dass die AnyDAC (FireDAC) Komponente automatisch Transaktionen startet und wieder beendet (TxOptions = AutoStart und AutoStop sind aktiv).

Als DB verwenden wir eine FireBird Version 2.5

@Delphi.Narium
Das DataSet ist nach dem Laden der Blobs nicht im EditModus (haben eine art Navigator auf der Form der das sofort anzeigen würde)... Auch das TDBMemo trifft keine Schuld, da beim Laden von Blob Daten über ein Grid (TXDBGrid) das gleiche Verhalten auftritt.

Wie bereits erwähnt, AutoCommit bewirkt, dass die AnyDAC (FireDAC) Transaktionen selbständig startet und beendet, also StartTransaction und Commit / Rollback.

@Quitzlinga
Wir sprechen hier von einer AnyDAC Komponente... Mittlerweile von Embarcadero in FireDAC umbenannt... Ich glaube hier hat mein Thread Titel für Verwirrung gesorgt


Das Problem liegt bei uns an den geänderten FetchOptions.Items Einstellungen... Hier haben wir fiBlobs ausgeschlossen, was dafür sorgt, dass die Blobs nachgelesen werden müssen... Hier ist es dann wohl völlig normal das im AutoCommit Modus eine Transaktion gestartet wird und erst mal offen bleibt...

Wäre für uns soweit nicht tragisch... Nur wenn wir jetzt explizit eine Transaktion starten wollen haben wir das Problem das eine Transaktion bereits geöffnet ist...
FireBird würde verschachtelte Transaktionen unterstüten, aber eine übergeordnete Transaktion kann die Änderungen einer Transaktion die innerhalb der übergeordneten Transaktion gestartet und committed wurde, durch ein Rollback wieder aufheben... Unser Beispiel würde z.B. wie folgt aussehen:

1. AnyDAC (FireDAC) startet aufgrund des AutoCommit Modus die Transaktion Nr. 1
2. Innerhalb dieser Transaktion wird eigenständig eine Transaktion Nr. 2 gestartet
3. Commit der Transaktion Nr. 2
4. AnyDAC (FireDAC) macht, warum auch immer, einen Rollback
5. Führt dazu das die Änderungen der Transaktion Nr. 2 auch mit rückgängig gemacht werden

Im Endeffekt bleibt uns wahrscheinlich nichts anderes übrig, wie die Transaktionen die von der AnyDAC (FireDAC) automatisch gestartet wurden zu beenden, bevor eine eigene Transaktion gestartet werden muss...

Weiß jemand ob es bei der AnyDAC (FireDAC) eine Möglichkeit gibt den "Inhalt" einer Transaktion auszulesen, also mitzubekommen welche Änderungen durch einen Commit an die Datenbank "gepostet" werden?

[Quitzlinga]

Hi,

mit FireDac kann ich schon etwas mehr anfangen, das zugrundeliegende Problem bleibt jedoch gleich. Die Komponente hat als Vorgabe xiReadCommitted ( ist bei UniDac in der Anfangseinstellung genauso ). Das führt dazu, das für jedes SELECT eine Transaktion gestartet wird, die vom Benutzer später committed werden muss.

Unter Firedac kann aber der Isolationsmodus eingestellt werden. Diesen einmal auf Dirty-Read stellen, dann dürfte auch keine Transaktion dazu mehr gestartet werden.

FIREDAC Isolationsmodus

MfG

Quitzlinga

[Cashew]

Vielen Dank für die Antwort...
DirtyRead würde aber auch dazu führen, dass ich z.B. Änderungen lesen kann die andere Transaktionen noch nicht committed haben... Oder sehe ich das falsch?