CursorLocation + CursorLocationEnum auslesen

[Walter Sobchak]

Hallo,

ich glaube ich habe da ein Verständnisproblem.
Es gelingt mir nicht den "CursorLocationEnum" Wert eines TAdoDataset's auszulesen. In diesem Fall meine ich nicht die Werte clUseClient, clUseServer sondern die Enum Werte (1,2,3,). Allerdings bekomme ich auch kein Ergebnis wenn ich versuche Cursorlocation auszulesen (clUseClient, clUseServer). Ich wollte dabei auf die Version if TAdoDataset1.Cursorlocation = ..... eigentlich verzichten und den Wert direkt erhalten.

So hab ich mir das bisher vorgestellt.
<PRE><CODE>
var
cl1 : TCursoLocation;
cl2 : integer;
......
cl1 := TAdoDataset1.properties['Cursorlocation'].value;
cl2 := TAdoDataset1.properties['Cursorlocation.CursorlocationEnum].value;

</PRE></CODE>
Benötige ich eventuell die ADOX Typbibliothek dazu ?
Wäre nett wenn mir jemand die beiden Möglichkeiten zeigt.

Eine Frage zum Buch "ADO Programmierung" von David Sceppa hätte ich noch.
Auf Seite 154 deuted Mr. Sceppa das verwenden der Cursorlocation "clUseClient" bei den meisten seiner eigenen Anwendungen(mit Access DB) an. Wie ist das nun zu verstehn ? Macht sich der Performanceunterschied (bzw. die doppelte Datenhaltung bei clUseClient) der CursorLocationEinstellung doch erst bei großen Datenmengen bemerkbar ?

Viele Grüße<BR>
Walter

[Andreas Kosch]

Hallo,

über die Typumwandlung in einen Integer erhält man die Werte 0 oder 1 zurück (clUseServer = 0; clUseClient = 1).
<pre>
procedure TForm1.Button1Click(Sender: TObject);
var
i : Integer;
begin
i := Integer(ADODataSet1.CursorLocation);
ShowMessage(IntToStr(i));
end;
</pre>

&gt;Wie ist das nun zu verstehn ?

Pragmatisch. Wenn das eigene Programm auf die erweiterten Fähigkeiten der OLE DB Client Cursor Engine zurückgreifen will, muss <b>clUseClient</b> verwendet werden. In diesem Fall überwiegt der Funktionsumfang gegenüber den Performance-Nachteilen. Wenn man im eigenen Programm diese Fähigkeiten nicht nutzt, würde man mit clUseClient Performance verschenken, ohne einen Vorteil davon zu haben (wobei zusätzlich in diesem Fall spezielle ACCESS-Sachen teilweise nicht zur Verfügung stehen)

[Walter Sobchak]

Hallo Herr Kosch,

vielen Dank für Ihre Infos. Mit der Typumwandlung klappts prima, Danke. Der Sinn des ganzen war zu Verfolgen was passiert wenn man die Cursorlocation Eigenschaft zur Laufzeit verändert.

Ich verwende eine SQL Abfrage (Access 97 DB) in der die Aggregatfunktion COUNT verwendet wird und muß das Ergebnis nach den Werten in der Countspalte sortieren.
Da diese Spalte nicht existiert verwende ich "AS Anzahl_Fahrzeuge".
Da man in diesem Fall die Spalte nicht mit "Order by" sortieren kann greife ich auf die Funktion "ADODataset1.Sort" zurück.
Die funktioniert leider nur lokal, also setzte ich zur Laufzeit die CursorLocation Eigenschaft dieses ADODatasets auf clUseClient wenn das Abfrageergebnis sortiert werden soll. Wird das Ergebnisfenster wieder geschlossen setzte ich wieder clUseServer. Das scheint mir nicht sonderlich elegant, aber sonst brauche ich für keine weiteren Prozesse clUseClient.

Da alle anderen AdoDatasets die CL Eigenschaft clUseServer haben würde mich noch interessieren wie das nun tatsächlich abläuft wenn EIN ADODataset die Einstellung clUseClient hat. Wird in diesem Fall trotzdem der gesamte Datenbestand auf den Client transportiert um die Abfrage dort durchzuführen oder werden nur die an der Abfrage beteiligten Tabellen auf den Client transportiert ? Oder liege ich vollkommen falsch und mache mir zuviele Gedanke darüber ?

Die Abfrage schaut so aus :
<PRE><CODE>
SELECT f.Firmenname, f.Zusatz, f.FirmenID,
(SELECT COUNT(z.firmenID)
FROM Fahrzeuge z
WHERE f.FirmenID = z.firmenID
AND z.FahrzeugStatus = 1) AS Anzahl_Fahrzeuge
FROM Firmen f
WHERE f.FirmenStatus = 1
</PRE></CODE>

Viele Grüße<BR>
Walte

[Andreas Kosch]

Hallo,

&gt;... mache mir zuviele Gedanken darüber ?

da ist was dran :-)

Wenn man die Konfiguration clUseClient wählt, fordert die <i>OLE DB Client Cursor Engine</i> alle Datensätze der Ergebnismenge sofort beim Öffnen von der Datenbank ab und puffert diese im Arbeitsspeicher des Clients. Da die Microsoft Jet Engine für eine ACCESS-Datenbank (MDB) die SQL-Fähigkeit simulieren muss und die Daten selbst puffert, sorgt clUseClient nur für eine doppelte Pufferung der Ergebnismenge und die Entkopplung vom Datensatzzeiger der Jet Engine. Im Fall von ACCESS (ist keine SQL-Datenbank) hat das keine Auswirkungen auf die Art und Weise, wie die Microsoft Jet Engine die Daten der SELECT-Abfrage zusammenstellt. Es spricht also nichts dagegen, für die Sortierfunktion der Anzeige auf eine TADODataSet-Instanz zurückzugreifen, die clUseClient verwendet. Immer dann, wenn inkompatible Konfigurationen entstehen, baut ADO im Hintergrund automatisch eine zweite Verbindung zur Datenbank auf (d.h. die TADODataSet-Instanz nutzt dann eine andere Connection-Objektinstanz als die restlichen, zur gleichen Zeit aktiven ADO-Objekte)