FireDac ODBC Query bringt alte Daten

[fisipjm]

Hi,

ich habe ein Problem bei dem ich nicht wirklich dahintersteige, irgend eine Einstellung ist wahrscheinlich falsch, aber ich finde sie nicht

Folgender Aufbau. Ich habe eine FDConnection, die geht auf eine bestehende ODBC Verbindung (DBMS Firebird, sollte ja aber eigentlich egal sein, wegen ODBC)
Hab ein Datenmodul in dem ich die Connection und 2 Querys liegen habe.
Alles wunderbar soweit.

Die erste Query frägt die Tabelle nach einer Spalte ab. Nenn wir die Tabelle Nummernkreise und die Spalte Zähler.

Erster Query Ablauf sieht also so aus:

Delphi-Quellcode:

procedure HolDieNummer;
begin
Query1.sql := 'Select zaehler from Nummernkreise where Spalte1 = :Kriterium1 and Spalte2 = :Kriterium2';
Query1.parambyname('Spalte1').AsString:='Hotehü';
Query1.parambyname('Spalte2').AsString:='Bliblablubb';
Query1.open;
if Query1.isEmpty then
  raise Exception.create('Mach nicht so, dass kann gar nicht passieren!!');

GlobaleNummer := Query1.fieldbyname('zaehler').asInteger;
Query1.close;
end;

Die Kriterien begrenzen die Abfrage immer auf genau einen Datensatz.
Erster durchlauf alles Toll, ich bekomme z.B. Die Zahl 1234 zurück.
Die Zahl nehme ich addiere 1 und speichere sie mit der 2. Query in die gleiche Tabelle zurück. Das geht so:

Delphi-Quellcode:

Query2.sql := 'Select zaehler from Nummernkreise where Spalte1 = :Kriterium1 and Spalte2 = :Kriterium2';
Query2.parambyname('Spalte1').AsString:='Hotehü';
Query2.parambyname('Spalte2').AsString:='Bliblablubb';
Query2.open;
Query2.Edit;
Query2.Fieldbyname('zaehler').asinteger := GlobaleNummer+1;
Query2.Post;

Wenn ich jetzt in die Datenbank schaue dann steht in der Datenbank die 1235 drin. Alles fein. Lass ich jetzt aber die Funktion in einer SChleife lauf dann wirft mir "HoldieNummer" immer 1234 als Ergebnis raus und ich versteh nicht warum. Wenn ich das Programm beende und wieder neu aufrufe, bringt mir die Procedure 1235 als Ergebnis und beim nächsten Neustart 1236 usw. aber innerhalb des gleichen Programmaufrufs nicht.
Es muss was mit der 1. Query zu tun haben, aber ich komm nicht drauf....

Grüße
PJM

[TurboMagic]

Hallo,

es gibt verschiedene ReadModi für den Umgang mit SQL Datenbanken.
Welche genau von welcher untersützt wird ist dabei unterschiedlich.
Aber manche (z. B. RepeatableRead) können zu genau sowas führen.

Ich bin mir nicht sicher ob das die Lösung ist, aber versuche doch
mal beim Schreiben ein Commit nachzuschieben. Dadurch sollte die
Transaktion beendet werden und evtl. führt dann das Lesen zum
wirklichen neu Einlesen des Wertes.

Grüße
TurboMagic

[fisipjm]

Zitat von TurboMagic:

Hallo,

es gibt verschiedene ReadModi für den Umgang mit SQL Datenbanken.
Welche genau von welcher untersützt wird ist dabei unterschiedlich.
Aber manche (z. B. RepeatableRead) können zu genau sowas führen.

Ich bin mir nicht sicher ob das die Lösung ist, aber versuche doch
mal beim Schreiben ein Commit nachzuschieben. Dadurch sollte die
Transaktion beendet werden und evtl. führt dann das Lesen zum
wirklichen neu Einlesen des Wertes.

Grüße
TurboMagic

Moin Turbo

das hatte ich tatsächlich schon versucht. Dann bekomme ich die Meldung das die Transactionskonfiguration auf Cached Updates stehen muss damit ein Commit gemacht werden kann. Außerdem steht der Wert ja bereits richtig in der Datenbank, wird also tatsächlich geschrieben. Wenn ich von "Außen" die gleiche Query auf die DB werfe, dann wird mir der neue Wert angezeit, nur meine Query zur Abfrage des alten wertes liefert mir noch den alten Wert.

[TurboMagic]

Hast du schon mal probiert statt mit ODBC direkt mit dem FireDAC Firebird Treiber auf die DB zuzugreifen?

[fisipjm]

Zitat von TurboMagic:

Hast du schon mal probiert statt mit ODBC direkt mit dem FireDAC Firebird Treiber auf die DB zuzugreifen?

Das möchte ich vermeiden. Aufgrund anderer Schnittstellen besteht der ODBC Dienst schon und ich muss mir keine Gedanken über die Verbindung machen.
Ich habe das Problem jetzt "gelöst". Beim erklären ist bei mir die Frage aufgekommen warum ich überhaupt 2 unterschiedliche Querys fürs lesen und schreiben nehme. Also hab ich sie unter einer Query zusammen gefasst. Die weis jetzt natürlich auch was sie schon geschrieben hat. Interessant wäre es trotzdem gewesen zu wissen woran es gelegen hat.

[hoika]

Hasllo,
es wurde doch bereits alles gesagt.

Query1 benutzt Transaktion1
Query2 benutzt Transaktion2
Query3 ist deine externe Abfrage

Die beiden kommen sich nicht ins Gehege dank des Transaktionsmanagements von Firebird.
Wenn nichts weiter eingestellt ist, gilt "Read Committed"

Wenn Query1 z.B. 10.000 Selects macht (Lagerinspektion) und Query2 "zwischendurch" einen Änderung am Lager vernimmt, interessiert das Query1 nicht.
Jeder arbeitet praktisch mit einer Kopie der DB zum Zeitpunkt des Starts der jeweiligen Transaktion.

Bei Query3 startest du (ohne es zu Wollen/Wissen) immer eine neue Transaktion, die Änderungen der vorherigen Queries sind also sichtbar, sofern sie committed sind.

Lösung.
Du muss bei den Queries explizit ein StartTransaction/Commit machen.