Query.Delete Zeiger auf nächsten Datensatz [erledigt]

[Michl]

Hallo,

da ich eine definitive Aussage nicht ergoogeln konnte, frage ich mal hier.

Ist es definitiv immer gewährleistet, daß bei einem Query.Delete der Zeiger auf den nächsten Datensatz gesetzt wird? Bei Zeos und SQLDB funktioniert das hier, aber ist dies dauerhaft gewährleistet bzw. definiert?

Hintergrund ist, daß ich alle Datensätze einer Tabelle auslese, in den Zwischenspeicher lade, auswerte und nicht mehr benötigte lösche. Ungefähr so:

Code: Alles auswählen

  Query.First;
  while not Query.EOF do
  begin
    if not NeededAnymore(Query.Fields[1].AsInteger) then
      Query.Delete
    else
      Query.Next;
  end;  

Testbeispiel wo alle Zahlen außer Primzahlen gelöscht werden anbei (ohne DLL)

[Sieben]

Ich denke, dass diese Verhaltensweise recht stabil ist, uq weil eine Änderung auch gravierende Folgen für das User-Interface hätten. Dürfte, wenn überhaupt, nicht 'über Nacht' eingeführt werden.

Aber mal anders gefragt - die Kriterien für NeededAnymore lassen sich nicht in SQL formulieren?

[Michl]

Aber mal anders gefragt - die Kriterien für NeededAnymore lassen sich nicht in SQL formulieren?

Nein, ich muss die Tabelle einzeln durchgehen und jeden Eintrag mit recht komplexen Berechnungen prüfen. Ich könnte da natürlich die IDs rausschreiben und hinterher die Einträge mit den jeweiligen IDs löschen, aber das kann ich ja auch gleich machen.

Ich denke, dass diese Verhaltensweise recht stabil ist, uq weil eine Änderung auch gravierende Folgen für das User-Interface hätten. Dürfte, wenn überhaupt, nicht 'über Nacht' eingeführt werden.

Ich habe leider in der Vergangenheit schon manchmal Federn lassen müssen, weil ich an eine bestimmte Verhaltensweise geglaubt habe - daher die Frage.

Ganz konsequent ist o.g. Verhaltensweise nicht, da wenn der letzte Datensatz gelöscht wird, Query nicht auf EOF springt, sondern den vorherigen Datensatz auswählt (in den Beispielen wird z.B. 97 zweimal getestet). D.h. ich habe die Schleife aktuell in etwa so gebaut (vielleicht gibt es da eine bessere Möglichkeit, als RecNo?!):

Code: Alles auswählen

procedure TForm1.ButtonRemoveClick(Sender: TObject);
var
  LNo: LongInt;
begin
  Query.First;
  while not Query.EOF do
  begin
    if not IsPrime(Query.Fields[1].AsInteger) then
    begin
      LNo := Query.RecNo;
      Query.Delete;
      if Query.RecNo < LNo then
        Query.Next;
    end
    else
      Query.Next;
  end;
end;  

[Sieben]

Du könntest es ohne RecNo zB so machen:

Code: Alles auswählen

procedure TForm1.ButtonRemoveClick(Sender: TObject);
begin
  Query.First;
  while not Query.EOF do
  begin
    if not IsPrime(Query.Fields[1].AsInteger) then
    begin
      LNo := Query.RecNo;
      Query.Delete;
      Query.Next;
      if Query.EOF then
        Break
      else
        Query.Prior;
    end
    else
      Query.Next;
  end;
end;  

Aber einmal zweimal testen ist jetzt auch nicht sooo schlimm, oder?

[gladio]

Die Datensätze werden nach deinem ersten Codefragment zuverlässig nacheinander abgearbeitet.
ich habe das selbst schon mehrmals so genutzt, ohne daß Datensätze übrig geblieben sind oder übersprungen wurden (Zeos, SQLite oder Firebird).
Bei großen Datenmengen könnte es etwas zeitkritisch werden.

[Michl]

Du könntest es ohne RecNo zB so machen:

Das stimmt, das geht auch. Habe es jetzt so umgesetzt. Danke.

Aber einmal zweimal testen ist jetzt auch nicht sooo schlimm, oder?

Bei dem Beispiel nicht, doch bei meiner echten Anwendung hat das die Folge, daß sich nach der Auswertung Grundlagendaten geändert haben und dies dann zu fehlerhaften Daten führt.

[Michl]

Die Datensätze werden nach deinem ersten Codefragment zuverlässig nacheinander abgearbeitet.
ich habe das selbst schon mehrmals so genutzt, ohne daß Datensätze übrig geblieben sind oder übersprungen wurden (Zeos, SQLite oder Firebird).
Bei großen Datenmengen könnte es etwas zeitkritisch werden.

Danke für die Info. Dann nehme ich das mal so als gesetzt hin und betrachte das erstmal als erledigt.

[af0815]

Vom SQLdb oder ZEOS wird im Hintergrund ein Puffer geführt, in dem die Änderungen mitprotokolliert werden. Deswegen ist das relativ stabil. Probleme bekommt man, wenn in einer Multiuserumgebung arbeitet, dann kann sich ein Problem ergeben, wenn beim Einpflegen in die DB festgestellt wird, das im Hintergrund sich was geändert hat. Meist fällt es auf, wenn was gelöscht wird.

Da muss man im Design darauf Rücksicht nehmen und wenn nötig das mit Transaktionen absichern.

[wp_xyz]

Ist es definitiv immer gewährleistet, daß bei einem Query.Delete der Zeiger auf den nächsten Datensatz gesetzt wird? Bei Zeos und SQLDB funktioniert das hier, aber ist dies dauerhaft gewährleistet bzw. definiert?

Zunächst hätte ich gesagt, dass das so ist, also dass nach einem Dataset.Delete der nächste Record aktiv wird. Und Michael Van Canneyt schreibt im "Lazarus Handbook" auch: "The current record will then be deleted, and the cursor will be positioned on the next record in the Dataset (if there is one)"

Aber wenn man sich den Quellcode von TDataset ansieht, ist das keinesfalls garantiert. Zunächst mal soll ein Abkömmling von TDataset die Methode InternalDelete überschreiben, und dort den Datensatz löschen. Das wird von Delete mit allem Drum-Herum aufgerufen. Das wäre OK.

Aber Delete ist als virtual deklariert - das heißt, ich könnte in meinem eigenen TDataset-Abkömmling ein komplett anderes Verhalten implementieren und den Cursor nach dem Löschen an den Anfang setzen (das wäre gemein...), oder den Dataset auf Active=false setzen, damit z.B. zur Sicherheit keine weiteren Datensätze gelöscht werden können, oder warum und was auch immer. Logisches Verhalten bei Fremdkomponenten darf man nicht immer voraussetzen.

[Michl]

Danke af0815 und wp!

Und Michael Van Canneyt schreibt im "Lazarus Handbook" auch: "The current record will then be deleted, and the cursor will be positioned on the next record in the Dataset (if there is one)"

Danke, daß du das rausgesucht hast! Dann ist das gesetzt, zumindest, wenn man es nicht selber verbockt, wie du es ausgeführt hast.