neuere Datzensätze fehlen beim Abfragen

[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.

[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?

[p80286]

Zitat von 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?

Jetzt hole ich die Chips, es geht los!
K-H

[hoika]

Hallo,

Zitat:

bedeutungslos

Nein, aber nicht wirklich sinnvoll.

Ein jederzeit konsistenter Zustand der Sicht auf die Daten ist aber nur beim ReadCommitted gegeben.

Mein Lieblings-Bsp. ist einer Lagerverwaltung:
Ich mache 14:00 eine Stunde Inventur, habe eine Inventursumme, gehe die einzelnen Positionen durch usw..
14:30 trägt jemand etwas ins Lager ein.

Ich erwarte, dass ich 14:31 immer noch meinen Lagerstand von 14:00 habe.
Sonst stimmt ja meine Summe nicht und ich kann von vorn anfangen.

(Deswegen machen ja viele Papier-Inventur ausserhalb der Arbeitszeit)

[jobo]

@Chips, bedeutungslos usw.
Ich schrieb ja "am Ende des Tages bedeutungslos". Für wen der Tag wann endet, mag jeder selber entscheiden.
Mir schien es sinnvoll, oder besser ich halte es immer noch für sinnvoll, die möglichen Optionen, die man im Transaktionshandling hat, nach bester Wahl priorisiert darzustellen.

[haentschman]

Hallo Helmi...
Ich gebe noch nicht auf, daß du siehst das WITH schlecht ist.

Vergleich:

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;

gegen...

Delphi-Quellcode:

//Filter setzen
 DataModule_DB.ZQuery.SQL.Text := 'SELECT DATUM, UHRZEIT, TEMPSENSOR_1, FEUCHTESENSOR_1 FROM Wetterdaten ';
 if not alle_Datensaetze then
 begin 
   SQL.Add('WHERE DATUM = :DATE');
   DataModule_DB.ZQuery.ParamByName('DATE').AsDate := Datum;
 end;
 DataModule_DB.ZQuery.SQL.Add('ORDER BY UHRZEIT');
 DataModule_DB.ZQuery.Open;

..merkst du was? Du machst es dir schwerer als notwendig ist. Mit dem WITH kannst außerdem du nicht mehr debuggen! ParamByName('DATE').AsDate bringt kein Ergebnis am Breakpoint. Und außerdem brauchst du mehr Quelltextzeilen.

Wenn du dir nicht helfen lassen willst bin ich hier raus. Ansonsten frage nach...