Auf einen Datensatz in einem Resultset positionieren (Locate)

[DasWolf]

Zitat von MPirnstill:

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 von peterbelow:

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 von haentschman:

Moin...

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.

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

• Locate
• Filter
• CachedUpdates=True

[haentschman]

Moin...

Zitat:

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

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

Zitat:

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

+

[exilant]

Zitat von peterbelow:

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.

[jobo]

Ich denke der Hinweis von mkinzler ist genau richtig, wenn auch knapp.

Und ich verstehe nicht, warum ein Locate verboten sein soll. Der Anwendungsfall, bei dem in einem Dateset auf einen bestimmten Datensatz gesprungen wird (werden soll) ist doch hier niemand bekannt.

Wieso wird sowas immer gleich so niedergemacht. Filter ist etwas anderes als Locate, Query mit Where Clause sowieso.

Wieso kann man nicht fragen, was gewollt und bekannt ist, statt zu behaupten, das sei alles falsch.

Und wenn ein Locate nicht funktionieren sollte, der Anwendungsfall aber diese Funktion benötigt, würde man wohl darüber schreiben müssen, wie man es nachbaut.

[MPirnstill]

Also ursprünglich war das mal eine TTable und man konnte mit dem DBNavigator in der Datenmenge vor- und zurückblättern, editieren, usw.
Dafür brauche ich doch die kompletten Datensätze, oder nicht?

Aber da es natürlich durch einfach blättern von Datensatz zu Datensatz zu mühselig/langwierig für die Anwender ist zu einem bestimmten Datensatz zu gelangen, mache ich auf Knopfdruck ein Suchfenster auf, wo der Anwender seine Suchparameter eingeben kann, wobei ich schon bei der Eingabe eine Ergebnismenge im Suchfenster anzeige. Klickt der Anwender dann auf eine Datensatz in der Ergebnismenge nehme ich mir den PI und will damit auf den DS im Adressdialog zu positionieren. Früher als noch TTable war per FindKey, später als es auf TQuery umgestellt war mit Locate.

Und das ging auch recht gut bis jetzt aufgefallen ist, das ...

- bei der Datenmenge, die für die Anwender nach Namenfeld sortiert ist, der PI 749 in der Datenmenge vor 74 liegt.
z.B.
PI Name
749 Hugo
..
..
74 Klaus

der Locate sieht so aus ...

Code:

      Locate('Adress_ID', StrToInt(aID), [loPartialKey]);

Da das Eingabefeld für den Suchbegriff ein alphanumerisches Feld ist, wandele ich es hier mit StrToInt um, aber das scheint locate nicht zu interessieren und positioniert deshalb auf "749 Hugo".

Ich hoffe, ich konnte hiermit verständlicher machen, in welcher Weise ich hier vorgehe. Mir wurde immer gesagt, viele Wege führen nach Rom.
Wenn der Ansatz falsch ist, wäre dankbar für eine kurze Beschreibung der richtigen Herangehensweise.

[p80286]

"Verboten" hab ich nirgendwo gesehen. Aber es ist schon die Frage was eigentlich erreicht werden soll.
Wenn z.B. alle Kunden in Mannheim zur Auswahl stehen sollen, würde ich es so lösen, daß ich zuerst die Kundennamen+ID hole und dann, nach der Auswahl, an hand der ID die vollständigen DatenSätze für das Edit.
Wenn es sich aber um eine Hand voll Datensätze handelt die man vollständig mit sich schleppen kann, dürfte der Weg über Locate oder ähnliches wohl effizienter sein.

Gruß
K-H