Reinrassige ADO-Objekte

[Gerhard Duerr]

Hallo,

ich habe D5 prof. und MDAC 2.6 installiert. Meine Absicht ist es, mit den reinrassigen ADO-Objekten zu arbeiten (TRecordSet, TConnection, - event. TCommand -). Die Frage ist nun: macht es Sinn ausschließlich mit den o.g. Objekten zu arbeiten ? und ist es von Nachteil wenn ich statt mit TADODataSet mit TRecordSet arbeite ?

[Andreas Kosch]

Hallo,

der Vorteil von ADO Express liegt im Komfort, denn an diese TDataSet-Nachfolger kann man über TDataSource die bequemen datensensitiven Komponenten hinzufügen. Mit den ADO-Komponenten von ADO Express wird also eine sehr schnelle Entwicklung unterstützt. Allerdings gibt es immer zwei Seiten, neben Vorteilen handelt man sich auch Nachteile ein:

1. ADO Express ist ca. 25..50 % langsamer als der direkte Zugriff auf die nativen COM-Objekte von ADO <br>
2. ADO Express fliegt einem auf einem Dual-Processor-Rechner um die Ohren, wenn man keine speziellen Vorkehrungen dagegen trifft.

Ich verwendet für Objekte, bei denen die Leistung und Zuverlässigkeit im Vordergrund steht, die ADO Express-Komponenten nur noch für das schnelle Prototyping. Aber dann wird alles gegen den Aufruf der nativen COM-Objekte (Connection, Command, RecordSet, Stream) ausgetauscht.

Für durchschnittliche Anforderungen überwiegen jedoch die Vorteile von ADO Express (Bequemlichkeit, schnelle Entwicklung, weniger notwendiges Know-How), daher macht ein Verzicht hier keinen Sinn

[Thomas Frank]

Hallo,

für mich als Benutzer von ADO Express stellt sich hier die Frage, wie funktioniert die Benutzung der reinrassigen ADO-Objekten. Wo sind sie? Wo gibt's Beispiele hierzu bzw. Literatur?

Gruß

Thoma

[Andreas Kosch]

Hallo,

die beiden folgenden Beispiele stellen den Einsatz von ADO Express und den direkten Zugriff auf die COM-Objekte von ADO gegenüber. Beide Implementierungen ändern 100 Datensätze in einer SQL Server 2000-Datenbank:

a) <b>ADO Express</b>:
<pre>
procedure TFormMain.DoUpdSQL;
var
iLoop : Integer;
sNew : String;
begin
with DM, ADOCommandSQL do
begin
Prepared := True;
ADOConnection1.BeginTrans;
for iLoop := 1 to 100 do
begin
Inc(FCount);
sNew := 'UPDATE SQL ' + IntToStr(FCount);
Parameters[0].Value := sNew;
Parameters[1].Value := 99900 + FCount;
Execute;
ProgressBar1.StepIt;
end;
ADOConnection1.CommitTrans;
Prepared := False;
end;
end;
</pre>
b) Direkter Zugriff auf die <b>COM-Objekte von ADO</b>:
<pre>
procedure TFormMain.DoNativeADOSQL;
var
swConnStr : WideString;
aConnection : _Connection;
aCommand : _Command;
swCommandText : WideString;
aParam : _Parameter;
vEMail : OleVariant;
vID : OleVariant;
iLoop : Integer;
vRowsAffected : OleVariant;
begin
swConnStr := DM.ADOConnection1.ConnectionString;
aConnection := CoConnection.Create;
aConnection.Open(swConnStr, '', '', adOpenUnspecified);
try
aCommand := CoCommand.Create;
try
aCommand.Set_ActiveConnection(aConnection);
aCommand.CommandType := adCmdText;
swCommandText := 'UPDATE LONGFETCH SET eMail = ? WHERE ID = ?';
aCommand.Set_CommandText(swCommandText);
aParam := aCommand.CreateParameter('', adVarChar, adParamInput,
25, vEMail);
aCommand.Parameters.Append(aParam);
aParam := aCommand.CreateParameter('', adInteger, adParamInput,
4, vID);
aCommand.Parameters.Append(aParam);
aConnection.BeginTrans;
for iLoop := 1 to 100 do
begin
Inc(FCount);
vEMail := 'UPDATE Command ' + IntToStr(FCount);
vID := 99900 + FCount;
aCommand.Parameters.Item[0].Value := vEMail;
aCommand.Parameters.Item[1].Value := vID;
aCommand.Execute(vRowsAffected, EmptyParam, adExecuteNoRecords);
ProgressBar1.StepIt;
end;
aConnection.CommitTrans;
except
aConnection.RollbackTrans;
aCommand := nil;
end;
finally
aConnection.Close;
aConnection := nil;
end;
end;
</pre>
In Microsoft-Press ist ein sehr gutes ADO-Buch (<i>ADO-Programmierung</i>; 309 Seiten; ISBN 3-86063-618-9) erschienen. Dort geht es zwar nur um Visual Basic, aber das macht keinen Unterschied. Da hinter ADO nur COM-Objekte stehen, ist der Zugriff völlig sprachunabhängig. Außerdem gibt es von Microsoft das <i>MDAC SDK</i> mit einer sehr umfangreichen Hilfe (umfangreicher als das ADO-Buch von Microsoft), dieses SDK ist über die URL <i>http://www.microsoft.com/data/download.htm</i> abrufbar

[Thomas Frank]

Hallo Andreas,

danke für ihre schnelle Info.

Gruß

Thoma

[Gerhard Duerr]

hallo hr. kosch,
das beispiel "Direkter Zugriff auf die COM-Objekte von ADO:" ist
sehr aufschlußreich.

frage:
kann man grds. folgende aussage treffen ?:

_Command benutzt man bei Insert, Update, Delete und Create..
_RecordSet benutzt man bei Select..

[Patrick Sack]

Hallo,
<br>"Die Frage ist nun: macht es Sinn ausschließlich mit den o.g. Objekten zu arbeiten ?"
<br>Vieleicht noch eine Frage, die man nicht vergessen sollte (nach allen Nach/Vorteilen von ADO Express):
<br>Wird ADO Express eigentlich noch weiterentwickelt? Oder stirbt das jetzt mit neueren Delphi Versionen aus?
<br>
<br>mfg
<br>P

[Bernhard Geyer]

ADO Express heißt bei Delphi 6 dbGo und sollte nach der deutschen Feature Matrix die ADO-Version 2.5 abbilden. Mit ADO-Express und der neuen XML-Desktop-Datenbank kann Borland endlich die "Weiterentwicklung" (war ja nur noch anpassungen/fehlerbereinigungen für neue Windowsversionen) von Paradox und dBase beenden, ohne mit leeren Händen dazustehen

[Andreas Kosch]

Hallo,

ADO ist ungemein flexibel, daher ist der Satz "<i>_Command benutzt man bei Insert, Update, Delete und Create.. _RecordSet benutzt man bei Select..? </i>" nicht in jedem Fall richtig. Generell gilt: Jeder kann alles, es ist nur die Frage, welche Optionen man nutzen will. Das Command-Objekt ist nur ein Weg, um eine Aktion auszulösen, wobei diese Aktion auch ein RecordSet-Objekt zurückliefern kann. Das RecordSet-Objekt stellt eine "lebende" Datenmenge bereit.

Das Command-Objekt braucht man dann, wenn spezielle Parameter oder Rückgabewerte benötigt werden. Ansonsten ist das Connection-Objekt in der Lage, eine beliebige SQL-Anweisung an die Datenbank zu schicken. Um die Sache noch komplizierter zu machen, reicht als Minimal-Lösung jedoch das RecordSet-Objekt aus (ADO baut hinter den Kulissen alle fehlenden Teile automatisch zusammen).

Da es hunderte "Knöpfe" gibt, an denen man drehen kann, ist ADO am Anfang etwas kompliziert. Aber nach einigen Wochen will man auf die ungeheure Flexibilität nicht mehr freiwillig verzichten

[Thomas Frank]

Hallo Andreas,

zu ihrem obigen Beispiel habe ich noch eine Frage. Ich habe gelernt, dass nach "...Create" immer ein "...Free" stehen muss (sollte), um die Resourcen wieder frei zu geben. In ihrem Beispiel steht aber stattdessen "... := nil". Ich würde daraus jetzt schliessen, dass eine nil-Zuweisung ein Free impliziert. Oder was hat das auf sich?

Gruß

Thoma

[Andreas Kosch]

Hallo,

hinter ADO verbergen sich COM-Objekte (Component Object Model) - somit gelten die COM-Regeln. Da nur ein Interface-Zeiger über Create abgefordert wird und COM die Lebensdauer einer Objektinstanz selbst festlegt, reicht es aus, wenn der Client seinen Interface-Zeiger freigibt. War er zu diesem Zeitpunkt der letzte Client (Nutzer) dieser Objektinstanz, so macht COM "als Letzer das Licht aus" (d.h. die Objektinstanz wird abgeräumt). Diese Logik hat Borland fest in den Compiler (bzw. in die Sprache Object Pascal) eingebaut

[Thomas Frank]

Hallo,

alles klar jetzt. Danke für die Hilfe.

Gruß

Thoma