TQuery/TTable filtern ohne Daten neu abzurufen

[Perlsau]

Du hast recht: auch bei mir mit IbDac und Firebird läuft das so, ebenso mit Ado und MsSQL. Ich hatte beim ersten Testen nicht daran gedacht, Filtered zuvor auf True zu setzen und daher ein falsches Testergebnis erhalten. Und die Datenmenge muß aus gutem Grund jedesmal neu eingelesen werden, wenn der Filter sich ändert, denn der Filter legt fest, was sich in der Datenmenge befindet: Ausgefilterte Datensätze sind nicht Teil der Datenmenge.

[Dejan Vu]

Wenns bei IbDac so läuft, dann postuliere ich, das das mit FireDac auch geht. Ergo liegt ein Refresh-Problem im FMX-Framework vor. Wenn der Fragesteller mit einer TListView arbeitet, wird er das Refresh wohl selber vornehmen... Das könnte die Ursache sein.

Nils: Mehr Code! ;-)

[Nils S.]

Also ich habe das natürlich auch gerade mal ausprobiert mit Filtered := False/True.
Auch da wird der aktuelle Datensatz aus der Datenbank gelesen und angezeigt.
Aber wenn ich den letzten Teil der Disskusion jetzt richtig verstanden habe, ist das so ja der Normalfall.

Zitat:

Zitat von Perlsau (Beitrag 1260106)

Du hast recht: auch bei mir mit IbDac und Firebird läuft das so, ebenso mit Ado und MsSQL. Ich hatte beim ersten Testen nicht daran gedacht, Filtered zuvor auf True zu setzen und daher ein falsches Testergebnis erhalten. Und die Datenmenge muß aus gutem Grund jedesmal neu eingelesen werden, wenn der Filter sich ändert, denn der Filter legt fest, was sich in der Datenmenge befindet: Ausgefilterte Datensätze sind nicht Teil der Datenmenge.

Also erstmal kein Refresh Problem mit FMX. (Oder bringe ich jetzt etwas durcheinander?)

Meine ursprüngliche Frage ist ja, wie man dieses Refreshen umgehen kann um den Programmablauf bei großen Datenmengen zu beschläunigen.
Mittlerweile bin ich mir gar nicht mehr sicher ob ich das überhaupt machen will, weil sich ja, wie zuvor auch schon erwähnt wurde, die Daten geändert haben könnten.

[Dejan Vu]

NEIN! Es ist *nicht* normal, das bei verändern der Filter-Eigenschaft die Daten neu gelesen werden.
Du hast doch immer noch 'Close/Open' im Code, oder?

[Perlsau]

Kann ich zumindest für Ado-Dataset auf MsSQL zugreifend bestätigen: Habe eben im Server Manager einen Wert geändert und danach den Filter im bereits verbundenen (Active = True) Ado-Dataset gesetzt mit dem Resultat, daß weiterhin der alte Wert in der betreffenen Spalte angezeigt wurde. Demnach filtert Ado wohl nur die eigene Datenmenge und nicht die in der DB vorhandene. Erst ein Open/Close des Datasets bringt den geänderten Wert zur Ansicht z.B. im DBGrid.

Seltsamerweise erhalte ich beim Versuch, statt Open/Close ein Refresh auszuführen, diese Fehlermeldung:

' Nicht genügend Basistabelleninformationen zum Aktualisieren '

Wie sich das bei anderen DB-Komponenten, noch dazu unter FMX verhält, läßt sich mit Sicherheit ermitteln. Aber ich gehe mal davon aus, daß es sich hier um ein Standard-Verhalten handelt, von dem seriöse Anbieter von DB-Komponenten nicht abweichen.

Delphi-Quellcode:

procedure TFormMain.FilterTest;
Var
 Id : Integer;
begin
  Id := DatMod.Tab_VDateien.FieldByName('Id_Video').AsInteger;
  IF DatMod.Tab_VDateien.Filter = '' THEN
     DatMod.Tab_VDateien.Filter := 'Jahr = 1960' ELSE
     DatMod.Tab_VDateien.Filter := '';

// Dieser Befehl führt zu besagter Fehlermeldung:
//  DatMod.Tab_VDateien.Refresh;

// Damit werden auch zwischenzeitlich geänderte Daten korrekt angezeigt:
  DatMod.Tab_VDateien.Close;
  DatMod.Tab_VDateien.Open;
  DatMod.Tab_VDateien.Locate('Id_Video',Id,[]);
end;

[Dejan Vu]

Für ein Refresh musst Du dem Dataset einen eindeutigen Schlüssel spendieren. Glaube ich.

[Nils S.]

Nein, auch ohne ein Close und Open wird die Datenmenge neu abgerufen.

[Perlsau]

Zitat:

Zitat von Dejan Vu (Beitrag 1260152)

Für ein Refresh musst Du dem Dataset einen eindeutigen Schlüssel spendieren. Glaube ich.

Schlüssel? Dataset? Was für ein Schlüssel? Meinst du, man benötigt in der Tabelle einen PK, um ein Refresh ausführen zu können? Der ist natürlich vorhanden: ID_Video.

Auch ein Ändern des Cursotypes im Dataset von ctStatic auf ctDynamic hat nicht die in der Online-Hilfe angekündigte Wirkung, denn der zuvor via DB-Manager geänderte Wert wird auch hier ohne nachstehendes Open/Close nicht angezeigt:

ctDynamic: Dynamischer Cursor. Die von anderen Benutzern hinzugefügten, geänderten und gelöschten Daten werden angezeigt. Die Datensätze können in beiden Richtungen durchlaufen werden.
ctStatic: Statischer Cursor. Eine statische Kopie der Datensätze. Die von anderen Benutzern geänderten Daten werden nicht angezeigt. Diese Cursor-Art wird hauptsächlich für Berichte verwendet.

Hat wohl mit der darunterstehenden Anmerkung zu tun: Wenn die Eigenschaft CursorLocation der ADO-Datenmenge den Wert clUseClientOnly hat, wird nur die Konstante ctStatic unterstützt. Und tatsächlich, clUseServer wird von diesem Provider nicht unterstützt, wie Delphi beim Start der Anwendung meldet, wenn ich die CursorLocation zuvor auf clUseClient (clUseClientOnly gibt's bei mir nicht) umgestellt habe:

' Das aktuelle Recordset unterstützt keine Lesezeichen. Hierbei handelt es sich möglicherweise um eine Einschränkung seitens des Providers oder des gewählten Cursortyps '

Zitat:

Zitat von Nils S. (Beitrag 1260158)

Nein, auch ohne ein Close und Open wird die Datenmenge neu abgerufen.

In meinem dargestellten Fall definitiv nicht. Wie hast du das überprüft? Wenn du richtig getestet hast, dann verhalten sich diverse DB-Komponenten diesbezüglich unterschiedlich.