vergleichbaren SQL-Befehl für "Locate"

[mkinzler]

Locate funktioniert auch mit SQL-Datenquellen. Es wird ja nur in der Ergebnismenge gescrollt was u.U. überhaupt keinen Zugriff auf den Server bedarf.

[jensw_2000]

Zitat von mkinzler:

Locate funktioniert auch mit SQL-Datenquellen. Es wird ja nur in der Ergebnismenge gescrollt was u.U. überhaupt keinen Zugriff auf den Server bedarf.

Das trifft bei einer clientseitigen Cursor Location zu.
Falls er einen serverseitigen Cursor verwendet erfolgt auch bei jedem Datensatzwechsel ein Serverzugriff, was durchaus alles andere als performant sein kann.
Jetzt wären durchaus Zusatzinformationen angebracht. Welche Datenbank / Version/ Zugriff über ?

[mkinzler]

Ich schrieb u.U. Und auch bei einem serverseitigen Cursor, wird nur gefetcht, wenn noch nicht auf dem Client vorhanden.

[jensw_2000]

War doch nicht persönlich gemeint, und nur als kleine Ergänzung.
Ich habe gerade gesehen, dass er Dbase Files verwendet. Da ist das Cursorlocation Thema vermutlich ohnehin vom Tisch.
clUseServer bewegt den Datensatzzeiger bei jeder Prior/Next/Locate Operation durch die serverseitige Datemnenge.
Mit dem Fetch hängt das eigentlich nicht direkt zusammen.
Serverseitige Cursur verwendet man z.B. um in Client Server Applicationen an jedem Client mitzubekommen, ob Datensätze durch andere User hinzugefügt oder gelöscht wurden.

Aber, wie gesagt.... DBF. Das Thema ist kalter Kaffee.

[Uwe Raabe]

Zitat von jensw_2000:

Jetzt wären durchaus Zusatzinformationen angebracht. Welche Datenbank / Version/ Zugriff über ?

Das steht interessanterweise im 1. Post:

Zitat:

Datenbank: dbf • Version: x • Zugriff über: TTable, TDatasource

[jensw_2000]

Ja, Uwe. Habe es entdeckt. War nur nicht so schnell mit dem Tippen ...

[Crowbar]

Danke für die ganzen Antworten ... wieder etwas gelernt.

Derzeitig habe ich

Delphi-Quellcode:

...
DBKundenTable.Locate('KUNDE','Musterfirma',[loCaseInsensitive,loPartialKey]);
...

verwendet. Hier traten manchmal die Performanceprobleme auf, wenn gleichzeitig ein weiterer Benutzer auf die Datenbank zugriff.

Derzeitig teste ich es mit der "TQuery" - Komponente.

Delphi-Quellcode:

...
KundenQuery.Locate('KUNDE','Musterfirma',[loCaseInsensitive,loPartialKey]);
...

Kann man sagen, dass die Ausführung des "Locate"-Befehls mittels "TQuery" schneller ist, als über "TTable"?

[mkinzler]

Nein, das dürfte theoretisch keinen Unterschied machen.

[jensw_2000]

Die Query und die Table arbeiten grundsätzlich gleich. Sie holen sich standardmäßig alle Datensätze aus einer Tabelle/Abfragedatenmenge in den RAM. Daher sind sie auch grundsätzlich gleich schnell. Bei der Query hast Du jedoch den Vorteil, dass Du die Anzahl der gefetchten Datensätze per WHERE Klausel auf das Notwendige beschränken kannst. Zudem kannst Du die abzurufenden Felder (Spalten) einschränken. (Statt SELECT * FROM die tatsächlich benötigten Feldnamen angeben). Das kann unter dem Strich viel ausmachen.

TTable und TQuery hatten glaube ich eine "UniDirectional" Property.
Hast Du die auf True gesetzt?
Damit kann Deine Suche z.B. vom aktuellen Datensatz direkt zum Anfang springen und eine neue Suche beginnen.
Oder rückwärts navigieren oder .... Vieles mehr.
Das bringt u.U. schon viel.
Falls UniDirectional auf False steht, wird die geftechte Datenmenge immer vom aktuellen Datensatz bis zum Ende durchlaufen. Erst dann beginnt die neue Suche, beginnend vom ersten Datensatz.
Gerade bei großen Tabellen macht sich das unidirektionale Verhalten positiv bemerkbar.