Auf einen Datensatz in einem Resultset positionieren (Locate)

[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

[MPirnstill]

Zitat von mkinzler:

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

Meinst du damit, das ich loPartialKey hier weglassen soll?

Ich werde das mal ausprobieren. Muss ich aber aufpassen, da ich den Suchdialog auch für andere Dialoge verwende.

[mkinzler]

Zitat:

Meinst du damit, das ich loPartialKey hier weglassen soll?

Ja. Bewirkt, dass teilweise Übereinstimmungen erkannt werden.

[MPirnstill]

Zitat von mkinzler:

Zitat:

Meinst du damit, das ich loPartialKey hier weglassen soll?

Ja. Bewirkt, dass teilweise Übereinstimmungen erkannt werden.

Hab's ausprobiert. Ohne den Parameter findet und positioniert "locate" auf den richtigen Datensatz.
Vielen Dank an alle.


P.S.:
Noch kurz zur Herangehensweise.
Als ich da Programm 1994 geschrieben hab, wo Delphi noch BDE hat und so, hat man doch mit TTable und DBNavigator gearbeitet.
Ist ja auch nur ein kleiner Dialog innerhalb einer größeren Anwendung.
Als ich dann auf TQuery umgestellt hab, hatte ich die im Prinzip nur ausgetauscht und anstelle FindKey dafür Locate verwendet.
Ich das, in dieser Weise wirklich so falsch?
Ich mein unter der Oberfläche könnte ich Anpassungen vornehmen, aber ich weiß nicht, ob ihr das kennt, der Anwender ist ein Gewohnheitstier
und wenn ich die Oberfläche verändere, kommen bestimmt wieder Proteste.

[haentschman]

Zitat:

Und ich verstehe nicht, warum ein Locate verboten sein soll...
Wieso wird sowas immer gleich so niedergemacht.

...weil es eben nicht immer funktioniert.

ca. 700.000 Einträge. Die ersten sagen schon alles. ADO hat damit sowieso seine Probleme.
https://www.google.de/search?source=...4dUDCAc&uact=5

[jobo]

Können mehr als 700T google Treffer irren?

meine Suchbegriffe zur Gegenprobe: c# dataset locate probleme

Gemäß der Ergebnisanzahl von 5,4 Mio empfehle ich dann konsequent am besten gleich gar kein C#
einzusetzen.
Es scheint ungefähr 8 Mal so problematisch zu sein.

[jobo]

Zitat von MPirnstill:

Noch kurz zur Herangehensweise.
Als ich da Programm 1994 geschrieben hab, wo Delphi noch BDE hat und so, hat man doch mit TTable und DBNavigator gearbeitet.
..
Als ich dann auf TQuery umgestellt hab, hatte ich die im Prinzip nur ausgetauscht und anstelle FindKey dafür Locate verwendet.
Ich das, in dieser Weise wirklich so falsch?
..

Falsch ist m.E. nicht der richtige Ansatz.
Es gibt Probleme, die idR priorisiert werden und es gibt Aufwände, diese Probleme zu beheben.
Wenn die Lösung von mkinzler für Dein Problem funktioniert, scheint es mir einfach sehr effizient zu sein.

Und ich möchte nicht wissen, wie viele alte BDE Programme so umgestellt wurden wie Du es grob beschrieben hast. Es ist nicht unbedingt ideal, aber wer würde sich beschweren, wenn es funktioniert.

Und klar, wenn man etwas nicht ganz besonders richtig macht, fällt es einem irgendwann auf die Füße und tut weh. Mit dem Risiko muss man eben leben.

Jenachdem wen Du fragst, wirst Du eine andere Antwort erhalten.