TQuery (BDE) / TDataSet - Verständnisproblem "Modified"

[Uwe Raabe]

Zitat:

Zitat von Bodenseematze (Beitrag 1540251)

Das widerspricht jetzt völlig meinem Verständnis.

Dann empfehle ich die Studie der einschlägigen Lektüre. Obwohl nicht mehr ganz so einfach zu finden, steht in der Hilfe doch so einiges zum Thema Cached Updates drin: https://docwiki.embarcadero.com/Libr....CachedUpdates

Zitat:

Zitat von Bodenseematze (Beitrag 1540251)

Wohin wird das denn durch "Post" gespeichert?

Wie in der Doku erwähnt, in einen lokalen Speicherbereich, der im Format einer Paradox-Table entspricht.

Zitat:

Zitat von Bodenseematze (Beitrag 1540251)

Bei der ersten Änderung des Master- oder eines der Detail-Datensätze starte ich auf der Datenbank eine Transaktion - dann können soviel Änderungen durchgeführt werden wie gewünscht.
Und erst wenn alle Änderungen entweder gespeichert (Commit) oder verworfen (Rollback) werden, sind die Änderungen weg.

Bei CachedUpdates ist die Transaktions-Steuerung gar nicht involviert. Das findet ausschließlich im DataSet (TQuery) statt. Erst beim Aufruf von ApplyUpdates wird die Datenbank involviert und die Transaktion bekommt die Daten. Wenn du bereits vorher eine Transaktion gestartet hast, dann hat das lediglich Einfluss darauf, welche Änderungen von anderen Clients du sehen kannst. Deine eigenen Änderungen sind vor dem ApplyUpdates gar nicht in der Datenbank vorhanden.

Zitat:

Zitat von Bodenseematze (Beitrag 1540251)

Und bis dahin muss ich doch programmtechnisch feststellen können, ob sich im Master-Datensatz oder einem der Detail-Datensätze Änderungen (d.h. es sind Daten im Query ggü. dem Datenbankinhalt verändert) befinden.

Und da möchte ich eben verstehen, mit welchen Properties / Aufrufen etc. auf den TQuery / TDataSet (oder auch sonst irgendwie) ich das einfachst möglich - aber korrekt - feststellen kann... :wink:

Wenn der aktuelle Datensatz im Insert/Edit Mode ist, dann gibt Modified an ob dieser geändert wurde (gegebenenfalls erst nach Aufruf von UpdateRecord). Ergänzend dazu gibt UpdatesPending an, ob es bereits andere Änderungen an den Daten der Query seit dem letzten ApplyUpdates gegeben hat, die aber noch nicht an die Datenbank übertragen wurden.

[Bodenseematze]

Zitat:

Zitat von Jasocul (Beitrag 1540257)

Du verwendest Queries, wenn ich es richtig gesehen habe. Diese können eigene DML-Anweisungen (Edit, Delete, Insert) haben, die unter Umständen automatisch ausgelöst werden.

Bei mir sind es "normale" Selects - meistens auf DB-Views und manchmal auch mit speziellen 'generierten' Spalten (z.B. CONVERT( MONEY, [Spalte] ) AS [Spalte])

Zitat:

Zitat von Jasocul (Beitrag 1540257)

Selbst wenn keine echten Änderungen vorliegen kann es solche Situationen geben, die manchmal kaum nachvollziehbar sind.

Das scheint bei mir der Fall zu sein... :?

Zitat:

Zitat von Jasocul (Beitrag 1540257)

Da du sowieso mit Transaktionen arbeitest, würde ich CachedUpdates deaktivieren. Wenn du nicht gerade Massenänderungen machst, ist der Netzwerkverkehr zu vernachlässigen und in dem Fall könntest du CachedUpdates auch gezielt aktivieren.

Der Netzwerkverkehr ist nicht das Problem.
Aber: wenn ich ChachedUpdates deaktiviere, kann ich gar nicht mehr (einfach) sehen, wenn es (noch nicht per "Commit" bestätigte) Änderungen in den Queries ggü. der Datenbank gibt - und schon gar nicht, was genau geändert ist (das versuche ich nämlich auch noch optisch darzustellen - über TField-Vergleiche).
Um das ohne CachedUpdates hinzubekommen, müsste ich mir dann den ursprünglichen Dateninhalt merken (eigene ReadOnly-DataSet?) und mit den aktuellen Daten vergleichen...
Das ist irgendwie auch keine Lösung :(

Ich versuche jetzt mal, das durch Eure Kommentare gelernte (oder herausgefundene) umzusetzen und schaue mal, ob ich eine vernünftige Erkennung von Änderungen hinbekomme...
...weitere Anmerkungen / "Stupser" :wink: sind gern gesehen!

[Jasocul]

Zitat:

Zitat von Bodenseematze (Beitrag 1540279)

Der Netzwerkverkehr ist nicht das Problem.
Aber: wenn ich ChachedUpdates deaktiviere, kann ich gar nicht mehr (einfach) sehen, wenn es (noch nicht per "Commit" bestätigte) Änderungen in den Queries ggü. der Datenbank gibt - und schon gar nicht, was genau geändert ist (das versuche ich nämlich auch noch optisch darzustellen - über TField-Vergleiche).
Um das ohne CachedUpdates hinzubekommen, müsste ich mir dann den ursprünglichen Dateninhalt merken (eigene ReadOnly-DataSet?) und mit den aktuellen Daten vergleichen...
Das ist irgendwie auch keine Lösung :(

Ich versuche jetzt mal, das durch Eure Kommentare gelernte (oder herausgefundene) umzusetzen und schaue mal, ob ich eine vernünftige Erkennung von Änderungen hinbekomme...
...weitere Anmerkungen / "Stupser" :wink: sind gern gesehen!

Wenn du Transaktionen verwendest, sieht man mit InTransaction, ob das noch aktiv ist.
Um auf Feldebene zu sehen, was sich geändert hat, musst du meines Wissens immer mit der DB vergleichen. Eine Liste der betroffenen Datensätze muss in jedem Fall selbst mitführen. Ich wüsste zumindest nicht, wie man an eine Liste auf Basis von UpdatesPending kommen soll. Allerdings hatte ich auch noch nie den Bedarf. Vielleicht wäre es sinnvoll, die Daten in einem ClientDataSet zu verwalten, statt direkt mit der DB zu kommunizieren. Du willst die Daten ja sowieso erst nach Bestätigung durch den Anwender an die DB schicken. Da bietet sich so eine Zwischenschicht schon an.

[Bodenseematze]

Zitat:

Zitat von Jasocul (Beitrag 1540283)

Um auf Feldebene zu sehen, was sich geändert hat, musst du meines Wissens immer mit der DB vergleichen.

Ich gehe dazu ganz grob folgendermaßen vor:
- bei der Erzeugung der Maske suche ich alle Controls auf der Maske heraus, die einen Datenbank-Bezug haben
(bei denen es entweder ein Property "DataSource" oder "DataSet" gibt oder ein Property "DataField" oder "Field", die ihrerseits ein Property "DataSource" oder "DataSet" haben);
die merke ich mir samt den dazugehörigen "TFields" in einer speziellen Liste
- wenn ein "DataSource" auf der Maske den Status auf "dsEdit" setzt, durchsuche ich die Liste nach geänderten "TFields"
(bei denen prüfe/vergleiche ich Value, NewValue und ggf. OldValue)
- ist ein Feld geändert, suche ich in der o.a. Liste nach Controls, die sich auf die "DataSource" und das Feld beziehen und setze deren Fontfarbe auf "rot"

Das funktioniert relativ gut - hat noch ein paar Spezialfälle, die ich gesondert handhabe, aber im großen und ganzen funktioniert das :-D

Zitat:

Zitat von Jasocul (Beitrag 1540283)

Vielleicht wäre es sinnvoll, die Daten in einem ClientDataSet zu verwalten, statt direkt mit der DB zu kommunizieren. Du willst die Daten ja sowieso erst nach Bestätigung durch den Anwender an die DB schicken. Da bietet sich so eine Zwischenschicht schon an.

Prinzipiell gebe ich Dir da Recht - wäre wahrscheinlich auch zunftsträchtiger (da ja dann endlich ggf. die BDE-Bezüge eliminierbar wären).
Ich habe in der Richtung auch bereits Experimente in meinem Code gemacht - bin dann dort aber auf andere Probleme gestoßen, die nicht so einfach behebbar waren --> also leider auch keine "einfache" Lösung :stupid:


Aktuell habe ich in dem Zusammenhang schon wieder ein komisches Problem:
Ich will ja den korrekten Status sowohl eines einzelnen Records als auch des gesamten Queries (bzw. DataSet) bestimmen - dazu gehört auch herauszufinden, ob ein Record gelöscht wurde.
Um solche Records überhaupt im DataSet zu haben, verwende ich folgenden Code (Auschnitt):

Delphi-Quellcode:

function DSRecGetState( const ds_ : TDataSet ) : TUpdateStatus;
var
   dsBDE             : TBDEDataSet;
   updRecTypes       : TUpdateRecordTypes;
begin
...

  Log( ds_ );  // 1. Aufruf

  dsBDE := nil;
  if ( ds_ is TBDEDataSet ) then begin
    dsBDE := TBDEDataSet( ds_ );
  end;

  updRectTypes := [];
  if ( Assigned(dsBDE) and dsBDE.CachedUpdates ) then begin
    updRecTypes  := dsBDE.UpdateRecordTypes;
    if ( NOT (rtDeleted in updRecTypes) ) then begin
      dsBDE.UpdateRecordTypes := dsBDE.UpdateRecordTypes + [ rtDeleted ];
    end;

    Log( ds_ ); // 2. Aufruf
  end;

...
end;

beim ersten Log-Aufruf kommt folgendes:

Code:

Active=true, RecordCount=1, CanModify=true, Modified=true, UpdateStatus()=Unmodified, State=dsEdit, CachedUpdates=true, UpdatesPending=false

beim zweiten Log-Aufruf kommt folgendes:

Code:

Active=true, RecordCount=1, CanModify=true, Modified=false, UpdateStatus()=Modified, State=dsBrowse, CachedUpdates=true, UpdatesPending=true

:shock:
Was soll das? Wieso wird durch das Verändern des "UpdateRecordTypes"-Set der Status des einen (!) vorhandenen Records geändert?
Er veliert das Modified-Flag und auch der State des gesamten Queries geht von "dsEdit" auf "dsBrowse"!???

Lt. Doku heißt es doch:
An application might also use UpdateRecordTypes like a filter to temporarily limit visible records to those added or inserted by the user during the current session.
Das habe ich so interpretiert, dass man das problemlos während der Laufzeit ändern kann (am Ende o.a. Funktion stelle ich das auch wieder auf den ursprünglichen Wert zurück)...

[Uwe Raabe]

Zitat:

Zitat von Bodenseematze (Beitrag 1540349)

Wieso wird durch das Verändern des "UpdateRecordTypes"-Set der Status des einen (!) vorhandenen Records geändert?
Er veliert das Modified-Flag und auch der State des gesamten Queries geht von "dsEdit" auf "dsBrowse"!???

Ein Blick in die Sourcen macht das klar:

Delphi-Quellcode:

procedure TBDEDataSet.SetUpdateRecordSet(RecordTypes: TUpdateRecordTypes);
begin
  CheckCachedUpdateMode;
  CheckBrowseMode;
  UpdateCursorPos;
  Check(DbiSetProp(hDbiObj(Handle), curDELAYUPDDISPLAYOPT, Longint(Byte(RecordTypes))));
  Resync([]);
end;

Delphi-Quellcode:

procedure TDataSet.CheckBrowseMode;
begin
  CheckActive;
  DataEvent(deCheckBrowseMode, 0);
  case State of
    dsEdit, dsInsert:
      begin
        UpdateRecord;
        if Modified then Post else Cancel;
      end;
    dsSetKey:
      Post;
  end;
end;

Zitat:

Zitat von Bodenseematze (Beitrag 1540349)

Lt. Doku heißt es doch:
An application might also use UpdateRecordTypes like a filter to temporarily limit visible records to those added or inserted by the user during the current session.
Das habe ich so interpretiert, dass man das problemlos während der Laufzeit ändern kann (am Ende o.a. Funktion stelle ich das auch wieder auf den ursprünglichen Wert zurück)...

Kann man ja auch. Es hat halt bestimmte Auswirkungen, die in der Hilfe nicht umfassend beschrieben sind. Dass diese Aktion den dsBrowse State erfordert, war vermutlich für den damaligen Author der Hilfe irgendwie selbstverständlich. Wenn man überlegt, ist das auch nachvollziehbar, da die Hilfe ja erwähnt, dass es eine Art Filter ist, und beim Ändern eines Filters könnte ja der aktuelle Datensatz aus der Anzeige rausfallen. Insofern ist ein Wechsel in den dsBrowse State schon angebracht.

[Bodenseematze]

Zitat:

Zitat von Uwe Raabe (Beitrag 1540354)

Ein Blick in die Sourcen macht das klar:

Delphi-Quellcode:

procedure TBDEDataSet.SetUpdateRecordSet(RecordTypes: TUpdateRecordTypes);
begin
  CheckCachedUpdateMode;
  CheckBrowseMode;
  UpdateCursorPos;
  Check(DbiSetProp(hDbiObj(Handle), curDELAYUPDDISPLAYOPT, Longint(Byte(RecordTypes))));
  Resync([]);
end;

Delphi-Quellcode:

procedure TDataSet.CheckBrowseMode;
begin
  CheckActive;
  DataEvent(deCheckBrowseMode, 0);
  case State of
    dsEdit, dsInsert:
      begin
        UpdateRecord;
        if Modified then Post else Cancel;
      end;
    dsSetKey:
      Post;
  end;
end;

OK - das erklärt es, wobei das (vermutlich wg. CachedUpdates) ja immer noch nicht tatsächlich in der Datenbank angekommen ist, sondern wohl "nur" in der internen (Paradox basierten) Speichertablle, oder?
(OffTopic: eine Methode "CheckXXXX" zu nennen und dann in der Methode die Daten zu verändern, halte ich übrigens für seehr schlechten Programmierstil - und hatte ich ebenfalls beim groben durchsehen der Quellen nicht erwartet)

Zitat:

Zitat von Uwe Raabe (Beitrag 1540354)

Wenn man überlegt, ist das auch nachvollziehbar, da die Hilfe ja erwähnt, dass es eine Art Filter ist, und beim Ändern eines Filters könnte ja der aktuelle Datensatz aus der Anzeige rausfallen. Insofern ist ein Wechsel in den dsBrowse State schon angebracht

Stimmt, der umgekehrte Weg, dass jemand ein bestehendes Flag (z.B. rtModified) aus den UpdateRecordTypes entfernt, könnte ja auch sein - habe ich mir noch gar nicht klar gemacht... :oops:

Wäre denn (anhand der o.a. Ergebnisse) für die Status-Abfrage des aktuellen Records folgendes richtiger?

Delphi-Quellcode:

Result := usUnmodified;
if ( (ds_ is TBDEDataSet) and TBDEDataSet(ds_).UpdatesPending and (ds_.UpdateStatus() <> usUnmodified) ) then begin
  Result  := ds_.UpdateStatus();
else
if ( ds_.Modified ) then begin
  Result  := usModified;
end;

oder einfach ganz ohne TBDEDataSet-Prüfung (da UpdateStatus() in der Basis-Implementierung und ohne CachedUpdates usUnmodified zurückliefert):

Delphi-Quellcode:

Result := usUnmodified;
if ( ds_.UpdateStatus() <> usUnmodified ) then begin
  Result  := ds_.UpdateStatus();
else
if ( ds_.Modified ) then begin
  Result  := usModified;
end;

Aber für die Abfrage des Status des gesamten Queries müsste dann doch tatsächlich über alle Records gelaufen werden - auf das State-Property kann ich mich da ja nicht verlassen (wenn CachedUpdates gesetzt ist), oder?

[Uwe Raabe]

UpdatesPending ist doch für alle Datensätze außer dem aktuellen, falls er gerade editiert wird, ausreichend:

Delphi-Quellcode:

function HasSomethingChanged(ADataSet: TBDEDataSet): Boolean;
begin
  Result := ADataSet.UpdatesPending;
  if not Result and (ADataSet.State in [dsEdit, dsInsert]) then begin
    ADataSet.UpdateRecord;
    Result := ADataSet.Modified;
  end;
end;