ADO im standalone Betrieb

[Peter Müller-Mannhardt]

ADO im standalone Betrieb?
Für einen skalierbare Architektur wird in der ersten Stufe eine, in der Funktionalität eingeschränkte, Desktop DB benötigt. Beim Einsatz von MIDAS bietet sich hier TClientDataset an. Gibt es Erfahrungen mit ADO im "Standalone Betrieb"? Wie ist der leistungsumfang verglichen mit TClientDataset?
Peter

[Andreas Kosch]

Hallo,

da in beiden Fällen alle Daten komplett im Arbeitsspeicher vorgehalten und ausgewertet werden und zudem die Implementierung in beiden Fällen in einer DLL (binärer Code) vorliegt, sollten die Zugriffszeiten vergleichbar sein

Die Zugriffszeit ist das Eine, die Funktionalität das Andere. Mein bisherigen Experimente zeigen, das die Anfragen:<br> <b> supports(adIndex) und supports(adSeek)</b> <br>jeweils false ergeben.<br>Damit wären Standalone wesentliche Dinge die TClientDataset bietet nicht verfügbar. Mach ich was falsch oder gibt es einen Ausweg

[Andreas Kosch]

Hallo,

welchen Sinn soll auch ein Index bei einer Datenmenge machen, die vollständig im RAM liegt? Angenommen, ein Testprogramm wird wie folgt zusammengebaut:

1. TADOConnection; <br>
2. MSDataShape als OLE DB-Provider auswählen<br>
3. Registerseite "Alle" : Data Provider=<b>NONE</b> <br>
4. TADODataSet mit TADOConnection verbinden <br>
5. CommandText: <b>SHAPE APPEND NEW adVarChar(20) AS Name, NEW adVarChar(20) AS eMail</b><br>
6. TADODataSet öffnen, zur Entwicklungszeit sind die Spalten im TDBGrid sichtbar, es können persistente TField-Instanzen für die Spalten angelegt werden.

Man kann nun über TDBNavigator etc. neue Datensätze in die In-Memory-Tabelle eintragen. Mit einem Mausklick auf die DBGrid-Spalte kann man dann die Anzeigereihenfolge ab/aufsteigend je Feld umschalten. Dabei erfüllt die RecordSet-Methode <b>Sort</b> exakt den Zweck, den normalerweise ein Index gehabt hätte:
<pre>
procedure TForm1.DBGrid1TitleClick(Column: TColumn);
begin
with TADODataSet(Column.Field.DataSet) do
begin
if Sort = Column.Field.FieldName then
Sort := Column.Field.FieldName + ' DESC'
else
Sort := Column.Field.FieldName;
end;
end;
</pre>
Da alle Datensätze im RAM liegen, würde ein Index den Zugriff nur komplizierter und langsamer machen, so dass so etwas erst gar nicht unterstützt wird ;-) <br>
Über <b>Filter</b> und <b>Filtered</b> lässt sich zudem auch die angezeigte Datenmenge einschränken. Und um bei o.g. Beispiel zu bleiben, kann man auch mit <b>Locate</b> jederzeit einen bestimmten Datensatz direkt anspringen:
<pre>
procedure TForm1.Button1Click(Sender: TObject);
begin
ADODataSet1.Locate('Name', 'Regel', [loCaseInsensitive]);
end;
</pre>
&#10

[Peter Müller-Mannhardt]

Na ja, um mir die Umstellung zu erleichtern ist als Grund wohl nicht ausreichend :-(<br>
Das Erzeugen der Datenmenge geht sogar ganz ohne TADOConnection. TADODataset auf das Formular ziehen (Connection bleibt leer) und mit dem Designer (r.Maus) die gewünschten Felder hinzufügen reicht aus. :-)<br>
Preformance-Probleme hab ich allerdings mit <b>LOCATE<\b>, welches ich im OnFilter-Ereignis für jeden Datensatz aufrufen muss um die gefilterte Menge zu realisieren. Dies ist dann wohl jedesmal ein COM-Aufruf? aber vieleicht fällt mir dazu noch was besseres ein..

[Andreas Kosch]

Hallo,

der Aufruf von <b>Locate</b> macht nur dann Sinn, wenn ein bestimmter (eindeutiger) Datensatz aufgerufen werden muss. Ansonsten ist das Zuweisen einer Filterkriteriums an die Eigenschaft <b>Filter</b> eleganter.

Was das Thema "COM-Aufruf" angeht, gibt es hier keinen Unterschied zu TClientDataSet. Auch beim Borland-Gegenstück liegt die Implementierung in einer mit C++ geschriebenen DLL. Und da die ADO-Objekte im gleichen Prozess und in der Regel wohl auch im gleichen Apartment liegen, liegt auch hier rein technisch gesehen ein direkter DLL-Aufruf (nur über 2 hintereinander geschaltete 32-Bit-Zeiger) vor.

Der SHAPE-Provider ist universeller, denn er erlaubt das "Dazumischen" von neuen Spalten zu realen Datenmengen. Somit erhält man ein Hybrid-RecordSet, dass aus echten Daten und eigenen editierbaren Daten aus einer In-Memory-Tabelle stammt. Allerdings gilt auch hier der Spruch "<i>Viele Wege führen nach Rom</i>" :-