Fehler mit Outputparameter beim verwenden von nativem Command Objekt

[Walter Sobchak]

Hallo,

ich komme mit dem nativen Command Objekt nicht weiter.

"...EOle Execption.
Fehler bei einem aus mehreren Schritten bestehenden OLE DB Vorgang. Prüfen Sie die einzelnen OLE DB Statuswerte..."

<PRE>

var SQLTxT : string;
aCon : _Connection;
// aRS : _RecordSet;
aCom : _Command;
vRows : OLEVariant;
vKennzeichen : Variant;
aParam : _Parameter;

[...]

SQLTxT := 'SELECT Fahrzeuge.ID, Fahrzeuge.Kennzeichen FROM Fahrzeuge'+
'WHERE FAhrzeuge.ID = : AbfrageParameter';

CS := Datamodule1.ADOConnection1.ConnectionString;
aCon := CoConnection.create;
aCon.CursorLocation := adUseClient;
aCon.Open(CS, '', '', adConnectUnspecified);

aCom := CoCommand.create;

with aCom do
begin
Set_ActiveConnection(aCon);
CommandType := adCmdText;
Set_CommandText(SQLTxT);

//InputParameter
aParam := CreateParameter('', adInteger, adParamInput, 10,
EmptyParam);
Parameters.Append(aParam);
Parameters[0].value := AbfrageParam;//ist eine ID aus dem Programm

//OutputParameter
aParam := CreateParameter('Kennzeichen', adVarChar,
adParamOutput,50, vKennzeichen);
Parameters.Append(aParam);

Execute(vRows, EmptyParam, dExecuteNoRecords);
end;
Edit1.text := aCom.Parameters.Item[1].Value;
</PRE>

Wenn ich nur den InputParameter verwende funktioniert alles prima aber wenn ich den Outputparameter noch dazuhaben will bekomme ich die obige Fehlermeldung.
Geht das vielleicht gar nnicht mit simplem "adCmdText"? Muß das eventuell eine Stored Procedure sein? Ich habe zwar gelesen das die Parameter Direction (adParamInput, adParamOutput) mit normalen SQL Abfragen UND Stored Procedures funktionieren aber ein Beispiel mit einer normalen Abfrage und einem Ein- und einem Ausgabeparameter nicht gefunden.

Sinn des ganzen soll es sein mal zu probieren wie schnell die Ausgabe mit Outputparametern anstatt mit einem Command(Recordset) sind. Die Beispiele aus dem Buch von Herrn Kosch sind mir bekannt aber auch dort werden immer nur Stored Procedure verwendet.

Viele Grüße<BR>
Walter

[Andreas Kosch]

Hallo,

eine direkt ausgeführte SELECT-Anweisung liefert <b>immer</b> eine Ergebnismenge zurück. Nur bei einer Stored Procedure stehen die OUTPUT-Parameter zur Verfügung. Wie das folgende Beispiel einer SP zeigt, verwendet die SELECT-Abfrage innerhalb der SP eine spezielle Syntax und auch der SP-Parameter wird über <b>OUTPUT</b> speziell gekennzeichnet:
<pre>
CREATE PROCEDURE stprOrtsname
@sPLZ char(5),
@sORT varchar(40) output
AS
SELECT @sORT = Ortsname
FROM plzDat
WHERE Postleitzahl = @sPLZ
-- Trefferanzahl zurueckliefern
RETURN @@rowcount
</pre&gt

[Walter Sobchak]

Hallo Herr Kosch,

vielen Dank für die Info, Das war es was mir nicht klar war (Outputparameter nur bei SP). Dann fällt dieser Lösungsansatz für mich zunächst flach da ich für diesen Fall MS Access DB verwenden muß.

Dann werde ich wohl beim Recordset bleiben. Leider war nur ein geringer Geschwindigkeitsunterschied zwischen TADODataSet und dem nativen Recordset zu erkennen(SELECT Abfrage eines Datensatzes dessen Ergebnisse in Editfeldern angzeigt wird).

Lustig finde ich das ADODataset (bei cmdText) im Hintergrund ein Command Objekt erzeugt und daß das Command Objekt "immer" ein Recordset liefert (wenn man es nicht mit NIL abschaltet). Ich habe es jetzt mit beiden Komponenten (auch mit den nativen Objekt) versucht jedoch der Geschwindigkeitunterschied zwischen ADOExpress Command und Dataset war nur gering. Bei den nativen Objekten war es nicht viel anders. Ein Grundsätzlicher Geschwindigkeitunterschied zwischen ADOEXpress und nativen Objekt war schon zu erkennen aber ob der den Mehraufwand lohnt weiß ich nicht.

Mit dem FirehoseCursor habe ich bisher keine Vergleiche angestellt, kommt aber noch.

Viele Grüße
Walte

[Andreas Kosch]

Hallo,

&gt;..nur ein geringer Geschwindigkeitsunterschied ..

im Fall einer ACCESS-Datenbank merkt man hier, dass es sich nicht um eine echte SQL-Datenbank handelt, sondern dass die Jet Engine die SQL-Fähigkeit nur simuliert. Beim "großen" MS SQL Server 7/2000 sieht das anders aus - hier sind die Unterschiede spürbarer (je schneller die Datenbank den Job intern erledigt, um so mehr wirken sich externe Verzögerungen aus)