Nicht sichtbare Datensätze

[TurboMagic]

Hallo,

ich habe eine Firebird 5.0 Datenbank die mittels Delphi 12.1 FireDAC angesprochen
wird. Ich habe nur eine Connection dort hin und noch eine weitere von einem DB
Verwaltungstool "SQL Manager Lite".

In einem Ablauf soll ein gewisser Select (left join) die Summe aller Beträge
aller Zeilen die eine bestimmte numerische Transaktionsnummer haben, die eben
erst den betreffenden Einträgen zugewiesen wurde (vorhger war diese Null).

Im aktuellen Beispielfall gibt es genau 2 Datensätze die da zu summieren sind.
Nur liefert der Select im Programm nur den einen Fall (der select hat in der
Where Bedingung eine Prüfung auf diese spezifische transaktionsnummer), also
eine zu niedrige Summe.

Führe ich den selben select paralell im DB Tool aus liefert er kein Ergebnis bzw.
wenn ich in der Where Bedingung die Prüfung auf die Transaktionsnummer durch
"is Null" ersetze liefert er das gewünschte Ergebnis.

1. Bevor ich diese Transaktionsnummer in alle Tabellen schreibe Starte ich eine Transaktion.

2. Ich habe auch schon versucht vor dem Starten der Transaktion
FSQLConnection.TxOptions.Isolation := xiDirtyRead; zu setzen.

3. Ich habe auch schon versucht vor der SQL Abfrage CommitRetaining; aufzurufen.

Leider alles bisher ohne Erfolg.
Hat noch jemand eine Idee?

[Delphi.Narium]

Zitat von TurboMagic:

die eben erst den betreffenden Einträgen zugewiesen wurde (vorhger war diese Null).

Erfolgt danach ein Commit (bevor die Transaktion für das SQL gestartet wird)?

[TurboMagic]

Hallo,

1. Transaktion starten

2. Den Datensätzen die Transaktionsnummer per Update zuweisen.

3. Die Abfrage starten die nicht so richtig will...

Was noch vorkommen könnte wäre zwischen 1. und 2. eine Buchung von Datenstätzen die selbst
StartTransaction und Commit macht, aber im Beispiel ist das nicht der Fall, da der aktuelle
Testfall einfacherer Natur ist.

Grüße
TurboMagic

[Delphi.Narium]

Ist sichergestellt, dass das Update und das Select in einer Transaktion stattfinden? Laut Beschreibung von Dir müsste dem so sein. Könnte es sein dass das Update eine eigene Transaktion startet, die aber nicht mit Commit beendet wird?

1. Start Transaktion

2a. Start einer weiteren Transaktion
2b. Den Datensätzen die Transaktionsnummer per Update zuweisen.

3. Die Abfrage starten die nicht so richtig will...

Sprich: Gibt es da irgendwo einen (nicht offensichtlichen) Seiteneffekt?

Bitte mal ausprobieren:

1. Start Transaktion
2. Den Datensätzen die Transaktionsnummer per Update zuweisen.
3. Commit der Transaktion

4. Start Transaktion
5. Die Abfrage starten die nicht so richtig will...

Klappt es dann?

[Uwe Raabe]

Ich verstehe das so: Deine Anwendung startet eine Transaction und macht das UPDATE. Das externe Tool macht danach ein SELECT und sieht die Änderung nicht. Was mir hier noch fehlt, ist das Transaction-Verhalten des Tools. Wird bei jedem SELECT eine neue Transaction aufgemacht (mit welchem Isolation-Level?) oder muss man das manuell regeln?

Zitat von TurboMagic:

2. Ich habe auch schon versucht vor dem Starten der Transaktion
FSQLConnection.TxOptions.Isolation := xiDirtyRead; zu setzen.

Da wirkt sich aber nur auf das aus, was diese Connection zu sehen bekommt, nicht was andere zu sehen bekommen. Wenn das Tool die Änderungen sehen soll, muss es selbst die entsprechende Isolation einstellen. Vielleicht kann man den Isolationslevel ja bei dem Tool einstellen.

Zitat von TurboMagic:

3. Ich habe auch schon versucht vor der SQL Abfrage CommitRetaining; aufzurufen.

Auch das erfordert zumindest den Start einer neuen Transaction in dem Tool. Andernfalls bleibt das Ergebnis dasselbe - zumindest wenn kein Read-Dirty erfolgt.

[Delphi.Narium]

In Bezug auf das externe Tool ist das richtig.

Das Problem ist nur, dass das Select in dem Programm, welches das Update durchführt, ein falsches Ergebnis liefert.

Das Programm sieht quasi die von sich selbst gemachten Änderungen nicht und liefert daher nicht das erwartete Ergebnis, obwohl Update und Select (vermutlich, höchstwahrscheinlich, eigentlich so erwartet) in einer Transaktion ausgeführt werden.

[TurboMagic]

Ja, Delphinarium hat recht.

Das externe Tool ist da nicht wirklich relevant, aber eben der Versuch da einen unabhängigen Blick drauf zu werfen.
Bei dem Tool gibt es für die Verbindung eine zentrale Einstellung der Transaktionssichtbarkeit und die steht auf
ReadCommitted. Siehe Screenshot.

Den vorgeschlagenen Test werde ich noch machen. Ich kann auch in meine Kapselung der StartTransaction Methode
einen breakpoint setzen, nur würde das halt keine impliziten StartTransaction Aufrufe oder solche welche die
Methode umgehen zeigen.

[TurboMagic]

Hm, nochmal ein ganz anderer "Twist":
momentan breche ich beim Testen die Sitzung ab, wenn ich in der Routine die das nicht richtig
funktionierende Select ausführt merke, dass das falsche Ergebnis raus kommt.

Somit bleiben die Datensätze welche diese Transaktionsnummer erhalten sollten auf dem
alten Stand. d.h. schaue ich mir diese mit dem externen Tool an steht deren Transaktionsnummer
immer noch auf Null.

Führe ich mein Programm erneut aus, versucht es diese Transaktionsnummer erneut zu vergeben.
Muss mal Daten bereinigen und den Test mit dem COmmit durchführen, erfolgt aber erst später.

[TurboMagic]

Hallo,

es wird noch verworrener!
Ich habe den Test jetzt ausgeführt, hat aber wieder nur das falsche Ergebnis gebracht.

Dann habe ich jetzt mal eine Routine geschrieben, der alle Datensätze der Tabelle, die
später zur Summe beiträgt, welche die zu setzende TransaktionsID haben, in ein Log schreibt.
Die eigentliche ID des Datensatzes (also nicht die TransaktionsID) und den Betrag.

Und siehe da, das liefert einen Datensatz mit einer höheren Datensatz ID als die höchste
mir im externen DB Tool angezeigte und einen Betrag von -10 €, der genau die +10 € um die
das Ergebnis später falsch ist mindert.

Ich versuche gleich mal dne Satz zu löschen und erneut zu testen.
Interessant wäre es jedoch herauszubekommen warum dieser Datensatz im externen DB Tool nicht
angezeigt wird! Trotz Commits dort und ANzeige aktualisieren usw.

[TurboMagic]

Hallo,

ok, Rolle rückwärts! Ich weiß jetzt wo mein Denkfehler ist.
Ist nicht in der Datenbank etc. sondern in der Logik der Abwicklung.
Bin jetzt wieder auf dem richtigen Gleis, wenn auch noch nicht ganz am
Ziel aber das sollte nun werden.

Danke!