ADO - CommitTrans

[Gerhard Duerr]

hallo,

ich habe zwei fragen, bei denen ich noch zu keiner lösung gekommen bin.
wer kann mir dazu was sagen ?

1. frage:
worin liegt der unterschied zw. aCommand.CommandText := strSql;
und aCommand.Set_CommandText(strSql);
falls es einen gibt: wann wird was eingesetzt ?

2. ausgangssituation:

aConnection.BeginTrans;
aCommand.Execute(vRowsAffected,EmptyParam,adOption Unspecified);
aConnection.CommitTrans;

frage:
wie kann ich abfragen, ob aCommand.Execute erfolgreich war (z.B. bei
Insert, Update, Delete), so dass
ein aConnection.CommitTrans folgen kann bzw. ein
Connection.RollbackTrans.

[Gesine Kuhlmann]

Hi,

1. Da gibts keinen Unterschied.

2. Es existiert eine Ereignisbehandlung <i>OnExecuteCommand</i>

Gruß
Gesin

[Gerhard Duerr]

ich benutze die nativen ado-objekte von microsoft.
hierbei kann ich leider kein OnExecuteCommand benutzen.

bei aConnection benutze ich bereits den
IsolationLevel := adXactReadCommitted;

wie kann ich feststellen, ob ein exectue erfolgreich war

[Gesine Kuhlmann]

Hi,

Wie wär's denn mit folgendem Fragment:

<pre>
Try
aConnection.CommitTrans;
except
aConnection.RollbackTrans;
end;

</pre>
Gruß
Gesin

[Gerhard Duerr]

manchmal sieht man den wald vor lauter bäume nichtmehr.

vielen dank für deine prompte antwort

[Andreas Kosch]

Hallo,

auch wenn das Beispiel von Gesine sehr elegant aussieht - bei ADO steckt der Teufel im Detail. Die try..except-Prüfung ist <b>nur dann</b> aussagefähig, wenn garantiert nur ein einziger T-SQL-Aufruf ausgeführt wird. Ruft man eine Stored Procedure auf oder führt einen Stapel von T-SQL-Anweisungen aus, so fängt der EXCEPT-Teil die Fehler nur dann ab, wenn der Fehler in der <b>letzten</b> Anweisung aufgetreten ist. Daher sollte man in ADO zur Sicherzeit immer die <b>Errors</b>-Kollektion auswerten, wenn kein ODBC-Treiber, sondern statt dessen der OLE DB-Provider verwendet wird. Nur beim ODBC-Treiber werden die ADO-Fehler automatisch ausgelöst, aber dafür haben viele ODBC-Treiber andere Macken, so dass man immer auf einen vorhandenen OLE DB-Provider zurückgreifen sollte und die Errors-Auswertung in eigener Regie nachholen.
<pre>
procedure TForm1.ButtonRaiseError2aClick(Sender: TObject);
var
iError : Integer;
sError : String;
begin
case RadioGroup1.ItemIndex of
0 : ShowMessage('Es ist keine Connection aktiv.');
1 : ADOStoredProcMSDASQL2.ExecProc;
2 : begin
ADOStoredProcSQLOLEDB2.ExecProc;
with ADOConnectionSQLOLEDB do
for iError := 0 to Errors.Count - 1 do
sError := sError + Errors[iError].Description + #10#13;
ShowMessage(sError);
end;
end;
end;
</pre>
Der Zugriff auf die Errors-Kollektion steht auch beim Einsatz der nativen ADO-Objekte zur Verfügung

[Gerhard Duerr]

hallo
leider komme ich mit dem beispiel nicht ganz klar. vielleicht klebe ich
gedanklich zu sehr an dem aCommand.Execute; so nach der art und weise
..if aCommand.Execute then...
//
ich bin bei meinen recherchen auf den ado event handler gestoßen. hier wiederum auf ExecuteComplete und hier auf adStatus.
mir ist aber unklar, wie ich das in verbindung mit aConnection.Execute verwurschteln kann, bzw. ob hier die lösung zu
suchen ist. falls hier eine lösung liegen kann, wäre ich für ein beispiel dankbar

[Andreas Kosch]

Hallo,

hinter den <i>ADO Express</i>-Komponenten der VCL verbergen sich nur Wrapper-Komponenten für die nativen ADO-Objekte (COM-Objekte) von Microsoft. Man hat also die Qual der Wahl, von welcher Quelle man seine Informationen erhalten will: <br>
1. Infos aus erster Hand: <b>Errors</b>-Kollektion des Connection-Objekts von ADO <br>
2. Infos aus zweiter Hand: <b>Errors</b>-Kollektion der TADOConnection-Instanz (greift intern auf den 1. Weg zurück)<br>
3. Infos aus dritter Hand: Ereignisse der ADO Express-Komponenten.<br>
Wer definitiv in jedem Fall topaktuell informiert sein will, sollte sich die Infos aus erster Hand besorgen. Wenn die Bequemlichkeit im Vordergrund steht und einige Infos unter den Tisch fallen dürfen, reicht der 3. Weg aus