Auf einen Datensatz in einem Resultset positionieren (Locate)

[MPirnstill]

Hallo,

ich nutze Delphi, der Datenzugriff geht über SQLDircet auf eine MS SQLServer.

Ich nutze schon eine Weile TSDQuery.Locate, aber es ist mir jetzt klar geworden, dass die Suchkriterien im VarArray-Parameter nicht um den Typ scheren.

Ich suche in einer Adress-Tabelle z.B. über Name, dazu nutze ich eine Select-Anweisung. Aus der Treffermenge kann der Anwender einen Datensatz anklicken auf den ich dann mit Locate in meine Haupt-Resultset (eigentliche alle der Tabelle) um auf den gesuchten DS zu positionieren.
Hier verwende ich natürlich den PI eine ID vom Typ Integer.
Aber da die Datenmenge für die Anwender sinnvollerweise nach Name sortiert ist, steht z.B. die ID 749 vor der ID 74 und Locate scheint das Integer-Feld wie ein Char-Feld zu behandeln und gibt mir schon bei entspr. 749 als Treffer zurück.

Kann ich Locate irgendwie sagen, das ich da in einem Integer-Feld suche und 749 nicht gleich 74 ist?
Oder gibt es eine andere Methode innerhalb eines Resultset auf einen Datensatz zu positionieren?

Früher bei TTable habe ich FindKey benutzt, aber inzwischen ist alles TQuery bzw. TSDQuery.

Vielen Dank für eure Hilfe im Voraus.

Micha

[mkinzler]

das hört sich eher nach der Option loPartialKey an.

[peterbelow]

Zitat:

Zitat von MPirnstill (Beitrag 1438844)

Hallo,

ich nutze Delphi, der Datenzugriff geht über SQLDircet auf eine MS SQLServer.

Ich nutze schon eine Weile TSDQuery.Locate, aber es ist mir jetzt klar geworden, dass die Suchkriterien im VarArray-Parameter nicht um den Typ scheren.

Ich suche in einer Adress-Tabelle z.B. über Name, dazu nutze ich eine Select-Anweisung. Aus der Treffermenge kann der Anwender einen Datensatz anklicken auf den ich dann mit Locate in meine Haupt-Resultset (eigentliche alle der Tabelle) um auf den gesuchten DS zu positionieren.
Hier verwende ich natürlich den PI eine ID vom Typ Integer.
Aber da die Datenmenge für die Anwender sinnvollerweise nach Name sortiert ist, steht z.B. die ID 749 vor der ID 74 und Locate scheint das Integer-Feld wie ein Char-Feld zu behandeln und gibt mir schon bei entspr. 749 als Treffer zurück.

Kann ich Locate irgendwie sagen, das ich da in einem Integer-Feld suche und 749 nicht gleich 74 ist?
Oder gibt es eine andere Methode innerhalb eines Resultset auf einen Datensatz zu positionieren?

Früher bei TTable habe ich FindKey benutzt, aber inzwischen ist alles TQuery bzw. TSDQuery.

Vielen Dank für eure Hilfe im Voraus.

Micha

Was Du da treibst ist nicht die Art, wie man mit einer SQL-Datenbank arbeiten sollte. Anstatt den vom Benutzer markierten Datensatz in einen clientseitigen Dataset zu suchen solltest Du eine neue Query absetzen, die anhand der PI nur den gewählten Datensatz zurückgibt, und dieser Dataset kann dann eventuell editiert werden, oder was Du auch immer damit anstellen willst. Locate ist ein Fossil aus den Tagen von Paradox und dBase und TTable, das sollte man meiner Meinung nach nicht mehr verwenden.

Allerdings: wenn dein "voller" Dataset über eine Query mit einer order by Klausel über die PI erzeugt wurde könnte das Locate sogar funktionieren.

[hoika]

Hallo,
also ich habe das mehrfach durchgelesen und trotzdem nicht verstanden ...

Zitat:

steht z.B. die ID 749 vor der ID 74 und Locate scheint das Integer-Feld wie ein Char-Feld zu behandeln und gibt mir schon bei entspr. 749 als Treffer zurück.

Auch bei einem Char-Feld wäre das Locate doch auch falsch!.

Char2="749"
Char1="74"

Where Char="74" darf doch auch hier nicht "749" zurückliefern ...

Ich würde mir mal ein paar Optionen des Locate ansehen und
1. "Filter" benutzen
2. direkte Queries nehmen, also wieder Abfragen zum SQL-Server schicken
3. Umsteigen auf TClientDataSet

Punkt 1 und 3 ergaben sich nach Goggle-Suche "TQuery Locate Error"

[haentschman]

Moin...8-)

Zitat:

direkte Queries nehmen, also wieder Abfragen zum SQL-Server schicken

...ich persönlich bin vom Locate (auch MSSQL) weg. Ich hatte auch so Fälle wo z.B. der Datensatz nachweislich existiert hat, aber Locate False ausgewiesen hat. Seit der Umstellung auf Queries (SQL) habe ich die Probleme nicht mehr. :thumb:

[hoika]

Hallo,

Zitat:

Ich hatte auch so Fälle wo z.B. der Datensatz nachweislich existiert hat, aber Locate False ausgewiesen

Hört sich wie ein Transaktionsproblem an.
IdR wird bei jeder neuen Query auch eine Transaktion gestartet und dein Ärger war weg ;)

[haentschman]

Moin...8-)

Zitat:

Hört sich wie ein Transaktionsproblem an

...bei einem Select der Datenmenge? :zwinker: Ich habe dann aufgegeben... Der Locate "sucht" ja lokal in der geladenen Datenmenge. Wenn der Datensatz nachweislich geladen wurde, aber Locate False ausgibt, ist irgendwas falsch.:?

[DasWolf]

Zitat:

Zitat von MPirnstill (Beitrag 1438844)

Ich nutze schon eine Weile TSDQuery.Locate, aber es ist mir jetzt klar geworden, dass die Suchkriterien im VarArray-Parameter nicht um den Typ scheren.

Wie sieht denn Dein Locate in voller Länge aus?

Zitat:

Zitat von peterbelow (Beitrag 1438846)

Was Du da treibst ist nicht die Art, wie man mit einer SQL-Datenbank arbeiten sollte. Anstatt den vom Benutzer markierten Datensatz in einen clientseitigen Dataset zu suchen solltest Du eine neue Query absetzen, die anhand der PI nur den gewählten Datensatz zurückgibt, und dieser Dataset kann dann eventuell editiert werden, oder was Du auch immer damit anstellen willst. Locate ist ein Fossil aus den Tagen von Paradox und dBase und TTable, das sollte man meiner Meinung nach nicht mehr verwenden.

Zitat:

Zitat von haentschman (Beitrag 1438878)

Moin...8-)

Zitat:

direkte Queries nehmen, also wieder Abfragen zum SQL-Server schicken

...ich persönlich bin vom Locate (auch MSSQL) weg. Ich hatte auch so Fälle wo z.B. der Datensatz nachweislich existiert hat, aber Locate False ausgewiesen hat. Seit der Umstellung auf Queries (SQL) habe ich die Probleme nicht mehr. :thumb:

Naja, um nicht ständig den Datenbankserver zu "nerven", sollte man folgende Instrumente niemals aus den Augen verlieren:

• Delphi-Quellcode:

  Locate

• Delphi-Quellcode:

  Filter

• Delphi-Quellcode:

  CachedUpdates=True

[haentschman]

Moin...8-)

Zitat:

Naja, um nicht ständig den Datenbankserver zu "nerven", sollte man folgende Instrumente niemals aus den Augen verlieren:

...dem widerspreche ich. :wink: Warum soll ich mir die komplette "Tabelle" laden um mir den passenden DS rauszusuchen? :roll: Mit einer einfachen Abfrage holt man sich das was man möchte zu dem Zeitpunkt wann man es braucht. 8-)

Zitat:

Locate ist ein Fossil aus den Tagen von Paradox und dBase und TTable, das sollte man meiner Meinung nach nicht mehr verwenden.

+ :thumb:

[exilant]

Zitat:

Zitat von peterbelow (Beitrag 1438846)

Was Du da treibst ist nicht die Art, wie man mit einer SQL-Datenbank arbeiten sollte. Anstatt den vom Benutzer markierten Datensatz in einen clientseitigen Dataset zu suchen solltest Du eine neue Query absetzen, die anhand der PI nur den gewählten Datensatz zurückgibt, und dieser Dataset kann dann eventuell editiert werden, oder was Du auch immer damit anstellen willst. Locate ist ein Fossil aus den Tagen von Paradox und dBase und TTable, das sollte man meiner Meinung nach nicht mehr verwenden.

Auch das editieren von Datasets mit edit/append/insert/post halte ich für übel.
Ich verstehe auch nach wie vor nicht, warum es Firedac u.ä.aufwendige Data Access Frameworks gibt. Das, was man wirklich brauchen könnte (ORM) leistet es nicht. Und der Rest wie das editieren von Datasets, "Live"-Querys, cached updates u. ä. sind übel. Eine leichtgewichtige direkte Verbindung zur Datenbank ist alles was man braucht: insert, update, delete. Und ein unidirektionaler Cursor auf eine Datenmenge, geliefert von einem Query.
Aber das ist nur meine Meinung.