neuere Datzensätze fehlen beim Abfragen

[Helmi]

Hallo,

mit folgendem Code frag ich Datensätze ab:

Delphi-Quellcode:

  //Filter setzen
  with DataModule_DB.ZQuery do
    begin
      Close;

      SQL.Clear;
      SQL.Add('SELECT DATUM, UHRZEIT, TEMPSENSOR_1, FEUCHTESENSOR_1 FROM Wetterdaten ');

      If not alle_Datensaetze then
        SQL.Add('WHERE DATUM = :DATE');

      SQL.Add('ORDER BY UHRZEIT');

      //Parameter
      If not alle_Datensaetze then
        ParamByName('DATE').AsDate := Datum;

      Open;
    end;

Dies funktioniert genau 1x.
Alle paar Minuten kommt ein neuer Datensatz in die Datenbank.
Frag ich danach mit dem o. g. Code wieder ab, so fehlt der neue Datensatz.

Erkennen tu ich es in einem DBGrid, dass der Eintrag fehlt.

Das DBGrid wird vom ZQuery versorgt.

Was mach ich falsch, bzw. wie bekomm ich die anderen, neueren Datensätze?

[nahpets]

Hast Du irgendwo Transaktionen?
Schreibst Du die neuen Datensätze mit Commit fest?
Welchen Wert hat die Eigenschaft TransactIsolationLevel der TZConnection?

Sind schreibendes und lesendes Programm das gleiche?
Oder schreibt ein Programm in die Datenbank und ein anderes holt die Daten ab?

[Helmi]

Zitat von nahpets:

Hast Du irgendwo Transaktionen?

Nein - jedenfalls sind mir keine bekannt (mit meinem Minimalwissen an Datenbank)

Zitat von nahpets:

Schreibst Du die neuen Datensätze mit Commit fest?

leider hast du mich jetzt erwischt - wie kann ich das feststellen oder nicht?

Zitat von nahpets:

Welchen Wert hat die Eigenschaft TransactIsolationLevel der TZConnection?

Auf dem Server "tiRepeatableRead".
Beim Client war das bisher auch, jetzt hab ich es auf "tiReadCommitted" geändert und jetzt bekomm ich auch die Datensätze angezeigt

Zitat von nahpets:

Sind schreibendes und lesendes Programm das gleiche?
Oder schreibt ein Programm in die Datenbank und ein anderes holt die Daten ab?

Ein Programm auf dem Server schreibt in die Datenbank, ein zweites Programm (Client) liest nur aus

[bnreimer42]

Hallo,

schau Dir die Sache mit den Transaktionen an und schalte alle Automatik der Client-Komponenten aus.

Ist eigentlich ganz einfach, ähnlich wie der Umgang mit einer Datei.

Am Anfang Begin Transaction (ähnlich Datei öffnen)
Alle Statements ändern innerhalb der laufenden Transaktion Daten. Andere Transaktionen sehen die Änderungen erst mal nicht. (ähnlich schreiben in gesperrte Datei)
Wenn Du fertig bist: Commit (ähnlich Datei schließen)
Wenn etwas schief gelaufen ist: Rollback, d.h. alles, was seit Begin Transaction geschehen ist, wird ungeschehen gemacht (Außer Spezialitäten, wie z.B. Erhöhen einer Sequenz)

Beim Lesen beginnst Du auch mit Begin Transaction
Bis zum Commit (oder Rollback) bleibt bei Repeatable Read der Datenbestand gleich
Wenn Du neue Daten erwartest, vor dem Lesen der Daten Commit einschieben.

Alternativ setzt Du die Lesetransaktion auf ReadCommited, dann siehst Du da immer alle Änderungen, die irgendjemand Commited hat.


Die meisten Komponenten machen das Begin Transaction alleine, d.h. wenn keine Transaction offen ist, öffnen sie eine.


Das Funktioniert - ich denke bei ZEOS auch - indem Du zusätzlich explizit ein Transaktionsobjekt anlegst und mit der Query oder Table verbindest.
Das Objekt hat auch die Methoden BeginTransaction, Commit und Rollback. (oder so ähnlich)

[Jasocul]

Transaktionen im schreibenden Programm können natürlich die Ursache sein, aber ich habe hier das Feld "Datum" im Verdacht.
Hast du schon direkt in der Datenbank nachgesehen, was in dem Feld steht?
Wenn das Feld auch die Uhrzeit enthält, schlägt der Vergleich in der SQL-Abfrage fehl.

Hast du auch schon geprüft, ab die Abfrage ohne Datums-Vergleich funktioniert?
Stehen die "fehlenden" Datensätze denn tatsächlich in der Datenbank drin?

[hoika]

Haqllo,
ob es an den Transaktionen liegt, ist einfach zu prüfen.
Dazu reicht es aus, das Anzeigeprogramm neu zu starten.
Sind die Werte iim Grid, liegt es an der fehlenden Transaktionssteuerung,
d.h. das Anzeigeprogramm startet zu Programmbeginn eine Transaktion und
zeigt dann auch nur die Datensätze an, die vor den Transaktionsstart comitted waren.

wie schon gesagt wurde.

Zitat:

Das Funktioniert - ich denke bei ZEOS auch - indem Du zusätzlich explizit ein Transaktionsobjekt anlegst und mit der Query oder Table verbindest.
Das Objekt hat auch die Methoden BeginTransaction, Commit und Rollback. (oder so ähnlich)

Also vor der Aktualisierung des Grids einfach eine Query.Connection.BeginTransaction
danach Query.Connection.Commit.
Query.Connection könnte auch Query.DataBase bei ZEOS heißen.

[Helmi]

Zitat von Jasocul:

Transaktionen im schreibenden Programm können natürlich die Ursache sein, aber ich habe hier das Feld "Datum" im Verdacht.
Hast du schon direkt in der Datenbank nachgesehen, was in dem Feld steht?
Wenn das Feld auch die Uhrzeit enthält, schlägt der Vergleich in der SQL-Abfrage fehl.

Hast du auch schon geprüft, ab die Abfrage ohne Datums-Vergleich funktioniert?
Stehen die "fehlenden" Datensätze denn tatsächlich in der Datenbank drin?

Im Feld Datum steht nur das Datum.
In der Datenbank hat nie ein Datensatz gefehlt. So hab ich es ja festgestellt, dass ich im Client nicht immer alle Datensätze erhalten habe.

Seitdem ich den Client auf tiReadCommitted gestellt habe, funktioniert es.

[jobo]

Zitat von hoika:

..

Also vor der Aktualisierung des Grids einfach eine Query.Connection.BeginTransaction
danach Query.Connection.Commit.
Query.Connection könnte auch Query.DataBase bei ZEOS heißen.

Also das scheint mir nicht richtig zu sein.
Transaktionshandling in einem Anzeigeprogramm ändert gar nichts.
Transaktionen sollten -falls sie nicht auf Automatic stehen- von dem Code gesteuert werden, der DML macht.

Die Sichtbarkeit der Daten ist dann so:
Der Client, der in-transaction ist sieht alles was andere commited haben plus seine eigenen "offenen" Transactionsdaten.
Andere Clients sehen davon nichts, egal wieviel Begin-/Endtransactions sie machen.

Spannender wird es natürlich, wenn Anzeige und Änderung in einem Programm erfolgen. Gemäß oben, sollte ein Client, der einfügt/ändert auch "sehen" können, was er da verzapft. Ist auch normalerweise so (bei "automatic"), außer man verwaltet die Transaktionen selbst. Wenn man das verbockt, und Transaktionen offen lässt (natürlich unbeabsichtigt), wird niemand diese Daten sehen. Ausnahme hier ist natürlich, wenn man nun noch zur Krönung des Chaos beginnt, mit den Isolation Leveln zu experimentieren um "seine Transaktionsdaten" irgendwo zu finden.

Mein Tipp für den Anfang:
Transaktion auf Automatisch. Wenn alles flutscht im Testbetrieb, Testbetrieb erweitern auf 2 oder mehr Clients, ggF. mit konkurrierenden Zugriffen, jenachdem was man überhaupt implementieren will.
Wenn das auch alles flutscht, kann man - wenn man es unbedingt ausprobieren will- manuelles Transaktionshandling einbauen. Und wenn man dann noch immer Spaß hat, kann man auch mit isolation levels spielen, wofür auch immer.
Aus gegebenem Anlaß dazu ein kleiner Vergleich:
Isolation Level != commited sind so ähnlich wie Wahlprognosen. Mglw. total spannend, aber am Ende des Tages bedeutungslos.

[Olli73]

Zitat von jobo:

Transaktionshandling in einem Anzeigeprogramm ändert gar nichts.

Da er TransactIsolationLevel auf tiRepeatableRead stehen hatte, lag es eben doch an einer Transaction.

Auch wenn hier ReadComitted natürlich besser ist.

[mjustin]

Zitat von jobo:

Isolation Level != commited sind (...) bedeutungslos.

Repeatable Read Transaktionen, um einen unveränderlichen Schnappschuss zu erhalten, in dem man die Datenbank völlig unabhängig von Insert/Update/Deletes anderer sehen kann, sind bedeutungslos?