Problem bei Lookup-Feldern mit ADO

[Stephan Schneider]

Hallo

Gegeben<br>
- Delphi 6<br>
- MSSQL-Server 2000<br>
- Zugriff auf den SQL-Server erfolgt mittels ADO<br>

Eine DB-Tabelle beinhaltet einen Self-Join. Eingerichtet als Nachschlagefeld in Delphi verwende ich hierzu zwei ADODataset-Komponenten, eine die alle Attribute führt (und z.B. mit deinem DBGrid verbunden ist) und die zweite, die lediglich als LookupDataset für den Self-Join dient. Verbinde ich eine DBLookupComboBox mit dem Nachschlagefeld, funktioniert alles sehr gut, bis auf eine Kleinigkeit. Nehme ich neue Datensätze auf, so erscheinen diese nicht(!) automatisch in der Nachschlagemenge. Erst ein nochmaliges Öffnen der Lookup-Datenmenge befördert sie ans Tageslicht. Ich habe es auch einmal mit ADOTable versucht, gleicher Effekt.

Bei BDE-basierten Anwendungen kenne ich diese Problematik nicht. Arbeitet man hier miz zwei TTable-Komponenten, so erscheint in der Nachschlagemenge auch sofort die neu-aufgenommenen Datensätze. Ein Art ReOpen (Close und Open) ist nicht nötig.

Stephan

[Andreas Kosch]

Hallo,

wenn die TADODataSet-Komponente einen client-seitigen Cursor (<b>clUseClient</b>) verwendet (was man beim SQL Server 7/2000 in der Regel auch machen sollte), so holt sich die OLE DB Cursor Engine beim Öffnen der Datenmenge über den sogenannten Firehouse-Cursor alle Datensätze vom SQL Server ab und puffert diese <b>lokal</b> im Arbeitsspeicher. Somit kann diese Datenmenge nur dann die Änderungen am originalen Datenbestand mitbekommen, wenn dieser Vorgang wiederholt wird (Requery).

Auch dann, wenn das Recordset-Objekt über <b>Clone</b> dupliziert wird, entstehen automatisch beim ersten Schreibzugriff zwei unabhängige Datenmengen.

Nur bei der Kombination von <b>clUseServer</b> und <b>ctDynamic</b> bekommt TADODataSet sofort alle Änderungen automatisch mit. Es stellt sich allerdings die Frage, in welchem Verhältnis der Nutzen zu den Nebenwirkungen von clUseServer steht.

P.S: Beim Vergleich mit der BDE entspricht ADO der Kombination von TQuery + TClientDataSet. Auch dort ist das erneute Einlesen der Daten notwendig, da auch TClientDataSet eine "Speichertabelle" im Arbeitsspeicher des Clients darstellt