vergleichbaren SQL-Befehl für "Locate"

[Crowbar]

Hallo,

auf dem Gebiet "SQL" bin ich noch ein Newbie ... derzeitig arbeitet meine Kundendatenbank ohne SQL.


Ich habe ein DBStringGrid mit der Möglichkeit eine Adresse zu finden. "Locate" finde ich dafür bestens geeignet. Hier wird im DBStringGrid zum jeweiligen passenden Datensatz gesprungen (ohne zu filtern).

Delphi-Quellcode:

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

Mir dem folgenden SQL-Befehl klappt es zwar auch, aber hier wird gefiltert und das entsprechende DBStringGrid "leer" sich entsprechend.

Delphi-Quellcode:

...
SQLText:='SELECT * FROM Kunden WHERE LOWER(KUNDE) LIKE "Musterfirma%" ORDER BY KundenIDXName ASC';
KundenQuery.SQL.Text:=SQLBefehl;    
...

Bei einem Netzwerkzugriff habe ich bemerkt, dass mit "Locate" Performanceprobleme auftreten können, deswegen wollte ich den Weg über SQL, ähnlich dem "Locate", gehen (aber ohne diese "Filterfunktion) ... jedoch finde ich nicht wirkliches passendes dazu. :-(

Gibt es überhaupt einen 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.

[fkerber]

Hi,

soweit ich es hier sehe, solltest du zwischen den Daten und ihrer Repräsentation unterscheiden.
Mit Hilfe der SQL-Anfragen werden dir Daten zur Verfügung gestellt - die kannst du z. B. in einem Grid anzeigen. Wenn du innerhalb dieser Daten dann hin- und herspringen möchtest, ist das im Prinzip "nur" eine Visualisierungssache und hat mit den SQL-Anfragen nichts mehr zu tun.


Viele Grüße,
Frederic

[himitsu]

Zitat:

Zitat von Crowbar (Beitrag 1264680)

Gibt es überhaupt einen vergleichbaren SQL-Befehl für "Locate"?

Nein.

Locate scrollt in vorhandenen eventuell gefilterten Daten zu dem gesuchten Datensatz, wobei dieser Positions-Zeiger (aktiver Datensatz) praktisch nur auf Clientseite existiert. :stupid:
WHERE ist nunmal eher wie das TDataSet.Filter.

[jensw_2000]

Zitat:

Zitat von mkinzler (Beitrag 1264682)

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.

[Uwe Raabe]

Zitat:

Zitat von jensw_2000 (Beitrag 1264688)

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]

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.

[jensw_2000]

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

[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.

[p80286]

Den wesentlichen Unterschied hast Du unterschlagen, die TQuery enthält die Daten, so wie sie durch den SQL.Text vorgegeben sind, die TTable kann nur mit einer Tabelle umgehen.

Gruß
K-H

[himitsu]

Hat er doch gesagt, wenn man nicht filtert, oder sonstewas, dann ist das praktisch gleich.

SQL-Code:

SELECT * FROM table

Nur daß man beim Query eben auch noch Spalten und Zeilen filtern kann um nur das Nötige übertragen zu müssen. (filtern, sortieren, gruppieren, joinen uvm.)

[p80286]

Dieses

Code:

select * from table

ist aber eher der Spezialfall

Gruß
K-H

[himitsu]

Kommt drauf an. :angel:

SQL-Code:

select * from myview

(oder eine Funktion, welche ein RecordSet liefert)

[mkinzler]

In dBase?

[jensw_2000]

Zitat:

Zitat von p80286 (Beitrag 1264710)

Den wesentlichen Unterschied hast Du unterschlagen, die TQuery enthält die Daten, so wie sie durch den SQL.Text vorgegeben sind, die TTable kann nur mit einer Tabelle umgehen.

Hier ging es nur um eine allgemeine Performance Betrachtung (s. Post #10).
Das man bei der Query die zu fetchende Datenmenge durch Feld-/Datenselektion reduzieren kann hatte ich erwähnt. (s. Post #12)

Zitat:

Zitat von p80286 (Beitrag 1264724)

Dieses

Code:

select * from table

ist aber eher der Spezialfall

Ein Spezialfall, den der Fragesteller offenbar benutzt (s. Post #1).

Boh, was habe ich Dir nur angetan. :? Ich entschuldige mich pauschal für Alles.
Peace! :cheers:

[p80286]

Zitat:

Zitat von jensw_2000 (Beitrag 1264732)

Boh, was habe ich Dir nur angetan. :? Ich entschuldige mich pauschal für Alles.
Peace! :cheers:

Ähh? nichts?!
hab ich so bissig geklungen??
:shock:
vorsichtshalber nehm ich alles zurück was ich geschrieben habe.

Gruß
K-H

[jensw_2000]

Vielleicht bin ich heute auch nur ein bisschen zu sensibel. *schluchz*
Alles wieder gut! :)