Werden immer alle Lookup-Daten zum Client übertragen?

[Swen Cramer]

Hi,

habe in einer Kundentabelle eine Referenz-ID auf die Postleitzahlen angelegt.

Nun hatte ich vor die Postleitzahlen am Client via TDBLookupComboBox anzuzeigen. Dabei mußte ich aber feststellen, daß beim öffnen der Kundentabelle alle 100.000-Test-PLZ-Datensätze zum Client übertragen wurden.

Ist das normal, oder mache ich da einen Fehler?

[Andreas Kosch]

Hallo,

welcher Wert wurde im Objektinspektor für die Eigenschaft <b>LookupCache</b> zugewiesen? Was protokolliert der SQL-Monitor/Profiler mit (falls es sich um eine SQL-Datenbank handelt=

[Swen Cramer]

Hi,

Mit dem SQL-Monitor habe ich die Sache noch nicht geprüft, weil man Unterschied zwischen 100 und 100.000 am Client deutlich wahrnimmt :-)

LookupCache ist False. Wie ich es verstanden habe werden die Daten wohl immer zu Client übertragen. Durch setzten von LookupCache auf True erreiche ich wohl, daß die Daten dann am Client gehalten werden und ab dem 2. Nachschlagen in dieser CacheDatenmenge gesucht wird.

Nun, daß würde aber immer noch bedeuten, daß alle meine PLZ beim 1. Nachschlagen zum Client übertragen werden müssen! Ich dachte eher, daß die Daten via Lookup etwas geziehlter geholt werden.

Bei der Datenbank handelt es sich um Interbase 6.x. Bei der Anwendung handelt es sich um eine MIDAS-Anwendung.

Und da ist auch mein Problem. Man stelle sich einen International arbeitenden Konzen vor. Alle Daten sollen in einer Zentrale verfügbar sein (Replikation)(Die Daten sind über einen Konzernschlüssel eindeutig). In der Zentrale setzt sich nun jemand mit allen Rechten hin, und öffnet den Kundenstamm. Nun würden die PLZ von Deutschland, USA, Japan,... als Lookup zu diesem Client übertragen - das dauert aber!

Und die Daten am Client halten, das geht wohl mit den Postleitzahlen, aber die Kunden selber als Lookup in einem anderen Stamm - diese Daten ändern sich doch ständig

[Andreas Kosch]

Hallo,

in diesem Fall darf man die PLZ nicht über eine TDBLookupComboBox anzeigen. Ich geht immer so vor: PLZ wird ganz normal von Hand eingetragen, beim Verlassen des Eingabefeldes wird die PLZ ausgelesen, einer parametisierten SELECT-Abfrage zugewiesen und die passenden Ortsnamen in eine Combobox-Instanz für die Orte eingelesen. Somit kann der Anwender den Ort auswählen, wobei hier die Treffermenge in jedem Fall gering bleibt

[Swen Cramer]

Danke für die Hilfe!

Ich werde wohl eine eigene DBLookupComboBox entwickeln, die geziehlt einen geforderten (PLZ-)Datensatz abfragt und zur Auswahl ein Grid hat, über die selektiv Daten anfordert werden

[Andreas Kosch]

Hallo,

welchen Sinn soll so etwas haben? Der Aufwand, eine Postleitzahl aus dem DBGrid auszuwählen ist doch wohl höher als der Aufwand, fünf Zahlen einzutippen ;-

[Swen Cramer]

Hi,

ja wenn man die Postleitzal kennt. Und für den Fall könnte man in meiner DBGrid incrementell suchen - irrer Aufwand :-).

Wir haben in unserem Projekt etwa 80 Stammdaten-Formulare. Etwa die Hälfte davon plegen Daten, die in andern Stämmen als Lookup vorkommen.

Vorgaben:
Netzwerktraffic gering halten.
Alle Lookups sollen selbstverständlich einheitlich in Optik und Bedienung sein.
Auch die Implementierung soll einheitlich sein und die Lookuplogik zentral, wegen dem Pflegeaufwandes des Produkts.
Und, die Lookupdaten sollen nicht am Client gehalten werden, d. h. nicht am Client speichern und am nächsten morgen von hier wieder laden.

Die letzte vorgabe ist eigendlich die Schwierigkeit an der Sache. Sonst hätte ich die LookupDaten mit den ClientDataSets einfach in Dateien auf dem Client abgelegt.
Und irgend was (procedure, thread,...) könnte die Daten im Hintergrund aktualisieren.
Aber da bin ich noch am verhandeln

[Andreas Kosch]

Hallo,

in diesem Fall könnte man den Kompromiss eingehen, dass der Anwender die ersten drei Zahlen der Postleitzahl eintippen muss. Danach startet das Programm automatisch eine SELECT-Abfrage für alle "passenden" PLZ-Datensätze und füllt damit die Lookupdaten. Da die ersten 3 Zahlen feststehen, kann eine WHERE-Einschränkung die Datenmenge klein halten, so dass das Problem des Zeitbedarfs für die Übertragung aller PLZ-Daten entfällt

[Swen Cramer]

Hi,<p>sag ich doch, die Grid-Methode. Der Anwender beginnt in der MyDBComboBox eine PLZ einzutippen. Hört er mit dem Tippen auf, sende ich ein Select-Statement und klappe die Grid unter der MyDBComboBox aus. Und für den Fall, daß er DropDown der MyDBComboBox auslöst ohne vorher Daten einzugeben habe ich bei unserer Anwendung auch kein problem, weil ich PacketRecords einfach auf 50 stelle und somit nur die ersten 50 DS erhalte.<p>Aber, ich habe mir das Aktenkofferprinzip der TClientDataSets mal genauer angesehen. Da ist richtig Genial für solche fälle.<br>Beispiel: Wie gehabt 100.000 PLZ.<br>Nach dem Start des Clients fordert dieser die PLZ bei der DB an - Testzeit ca. 18 sek.<br>Dann speichere ich die Daten via ClientDataSet1.SaveToFile in eine Datei.<br> Neustart des Clients. Dann öffne ich das ClientDataSet1 wieder. Alle Einstellungen wie gehabt - RemoteServer, ProviederName, CommandText UND FileName sind gesetzt. Nun lädt das ClientDataSet1 die Daten aus der gespeicherten Datei - Testzeit ca. 2 sek.<br>Nur, für das aktualisieren der Daten (.Refresh) werden ca. 14 sek. benötigt. Aber da muß ich mir noch was cleveres ausdenken. :