TFDTable.FindKey - Performance

[Edelfix]

Hallo,

ich bin dabei von ADS Komponenten auf FireDac zu wechseln.

Etwas scheint aber nicht richtig zu sein. Es ist sehr langsam mit FireDac.

In einer Start Unit werden etwa 150-mal hinter einander per FindKey Werte gelesen und in einen Rekord gespeichert.

Mit ADS Komponenten geht das in 172 m/sec. (mit GetTickCount gemessen).

Das gleiche mit FireDac braucht 2218 m/sec.

Mit dem FireDac Monitor sehe ich das während dieser Zeit kein Datenbank Zugriff erfolgt. Das bedeutet das die Komponente diese Aufgabe mit internen Daten erledigt.
Leider weiß ich nicht ob die ADS Komponente für jeden FindKey Aufruf auf die Datenbank zugreift.

Jemand eine Idee?

[Sinspin]

Zitat von Edelfix:

ich bin dabei von ADS Komponenten auf FireDac zu wechseln.

Genau das gleiche habe ich vor ein paar Monaten auch gemacht.
FD ist schneller, obwohl ja intern auf den gleichen Treiber zugegriffen wird.
Nur auf ein paar Sachen solltest Du verzichten.
Zum Beispiel auf Locate und FindKey. Die werden nun beide Clientseitig ausgeführt und nicht mehr auf dem Server. Es wird also alles geladen und dabei sortiert.

Zitat von Edelfix:

In einer Start Unit werden etwa 150-mal hinter einander per FindKey Werte gelesen und in einen Rekord gespeichert.

Das ist auch kein wirklich toller Programmierstiel. Das Sollte eine SP auf dem Server machen und dir danach alle Werte liefern.

[Edelfix]

Das ist ja ein heftiger Unterschied zu ADS Komponenten. In unserem Projekt werden massive TAdsTable eingesetzt. Habe eben 1800 Stellen mit FindKey gefunden.

Wie kann man einer TFDTable beibringen das sie den Server nutzen soll?

[Sinspin]

Ich habe große Mengen von TADSTable durch queries ersetzt und ziehe nur noch die Daten die wirklich gebraucht werden.

Table kommt bei mir nur noch zum Einsatz bei kleinen Tabellen, wo es egal ist ob alles gezogen wird, oder es eh Sinn macht.
Ich hatte früher das gleiche Problem. Und TADSQuery hatte einen Master/Detail Bug. Den habe ich schon vor Jahren behoben um die Komponente besser nutzen zu können.
FindKey hatte bei Queries unter ADS auch seine Probleme. Habe ich dort nie verwendet.

Master / Detail funktioniert bei FireDac wirklich gut.
Ich arbeite mit Parametern in den Scripten die FD dann selber für Master / Detail auswertet.

Beim Umstieg habe ich tausende Locate ersetzen müssen. Meißt durch direkte query Zugriffe um nur ein paar Werte zu hohlen oder zu ändern.
Viel arbeit war das schon (gut 2 Monate für 500K LOC), aber es lohnt sich. Es läuft nun alles Flotter.
Allerdings habe ich schon vorher über Jahre hinweg, halt immer wenn zeit war, so gut wie alle Änderungen die via Table gemacht wurden durch Update Scripte ersetzt.

Zitat von Edelfix:

Habe eben 1800 Stellen mit FindKey gefunden.

Aus meiner Sicht schlechter Programmierstiel. Datenbankzugriffe sind immer Teuer. Also sparsam damit sein.

[Pfaffe]

>> TADSQuery hatte einen Master/Detail Bug
In welcher Version.
Bitte um mehr Info. Was ist das für eine Bug?

[Sinspin]

Eigentlich beide, also TADSTable und TADSQuery. Ich denke nicht das sich daran was geändert hat. Aber in 10 und 11 war es jedenfalls so.

Ich hatte da lange Debatten drüber. ADS stellte das Verhalten als Feature dar.
Ich sehe allerdings kein Feature in der Tatsache dass ein offenes Detail alle Records zur Verfügung stellt wenn die Mastersource zu ist. Erwarten würde ich dann dass auch das Detail keine Records enthält, weil ja nicht bekannt ist wie gefiltert werden soll.

Bei FD geht das korrekt. Detail srcipt like : "SELECT * FROM DetailTable WHERE Field = :MasterField". Ist die Mastertabelle zu, ist MasterField unbestimmt und das Detail is leer.