HELP ! Stored Procedures angelegt, Aufruf mißlingt !

[lemmond1976]

Hallo,

ich bin es nochmal und habe einen neuen Thread aufgemacht.
Ich habe ein echtes Problem an der Backe.
Als Server benutze ich MS SQL 7.0.
Der Zugriff erfolgt über ADO.
TADOStoredProc ist ja wohl dazu da, gespeicherte Prozeduren ohne Ergebnismengen (also Insert, Create, Update..) aufzurufen.

Die Prozedur habe ich im Objekt-Inspektor ausgewählt.
Folgender Code funktioniert auch:

Code:

AdoStoredProc1.Parameters.parambyname('@Feld').Value := 'Wert1';
.......

Das EXECPROC danach macht aber Schwierigkeiten, sodaß es zu folgender Fehlermeldung kommt:

Zitat:

ODBC MSQL Server Das optionale Feature ist nicht implementiert.

Das wäre der erste Punkt, der geklärt werden müßte.
Bei ergebnismengenorientierten Abfragen (Select etc.) kann man die Prozedur wie eine normale Tabelle behandeln.
Also zum Beispiel so:

Select * from test_procedure

Ich brauche dazu ja wohl ein ADODataSet und eine Query.
Und wie muß ich diese beiden im Objekt-Inspektor miteinander verbinden, daß
die Query das Ergebnis der Prozedur zurückliefert ?
Sind also nur zwei Fragen..
Wäre also wirklich klasse, wenn einer ne Antwort parat hätte.
Komme nämlich echt nicht weiter.

Danke !

Gruss

Ich habe schon überall nachgeschaut, dieses Forum ist hier eigentlich die einzige Möglichkeit, dieses Scheiß-Problem zu beseitigen, da ich selbst an die Grenzen meiner Möglichkeiten gestoßen und etwas frustriert bin. :-(
Gunnar

[frankg]

Hallo Gunnar!

Ich habe mal ein paar Anmerkungen zu Deinem Posting geschrieben

Zitat:

Zitat von lemmond1976

TADOStoredProc ist ja wohl dazu da, gespeicherte Prozeduren ohne Ergebnismengen (also Insert, Create, Update..) aufzurufen.

Eigentlich nicht! :wink: Die Komponente TADOQuery, TADOTable und TADOStoredProcedure sind eigentlich nur als Rückwärtskompatibilitätskomponenten zu den BDE-Äquivalenten gedacht, d.h. sie sollen Dir helfen, ein BDE-Programm (relativ einfach) nach ADO zu portieren, indem Du einfach nur die BDE-Komponenten durch die ADO-Komponenten ersetzt. Wenn Du ein natives ADO-Programm verwendest, solltest Du (nach Meinung von Borland) die Komponente TADODataset verwenden, was im Prinzip die Funktionalitäten der drei Komponenten beinhalten. Leider hat man dieses wohl bei Borland nicht so optimal implementiert, so dass TADODataset wohl ein paar Probleme macht und ausserdem auch noch langsamer ist als ein direkter ADO-Zugriff (im Buch "ADO und Delphi" von Andreas Kosch ist ein sehr interessanter Benchmark zu diesem Thema drin). Ich bevorzuge beim Aufrufen von Stored Procedures über ADO folgende Vorgehensweise:

Delphi-Quellcode:

procedure CallSP; 
var 
  myCommand : ADOInt.Command; 
  myParam : ADOInt.Parameter; 
  RowsAffected : OleVariant; 
begin 
  // Command-Objekt erzeugen 
  myCommand := CoCommand.Create; 
  with myCommand do 
    begin 
      // Command-Objekt initialisieren 
      CommandType := adCmdStoredProc; 
      CommandText := 'spDoSomething'; 
      // Parameter erzeugen und an das Command-Objekt hängen 
      myParam := CreateParameter('Param1',adChar,adParamInput,30); 
      Parameters.Append(myParam); 
      // Parameterwert setzen 
      Parameters[0].Value := 'Hallo'; 
      // Connection setzen, über die der Befehl abgesetzt wird, 
      // irgendwo im Programm muss es die Connection myADOConnection 
      // geben, diese muss auch (soweit ich weiss) offen sein 
      Set_ActiveConnection (myADOConnection); 
      // In RowsAffected steht drin, auf wie viele Zeilen sich die 
      // Prozedur ausgewirkt hat. Wenn es Records zurück gibt, dann 
      // muss natürlich der letzte Parameter anders sein. 
      Execute (RowsAffected,EmptyParam,adExceuteNoRecords); 
    end; 
  // Command-Objekt wieder freigeben 
  myCommand.Free; 
end;

Zitat:

Zitat von lemmond1976

ODBC MSQL Server Das optionale Feature ist nicht implementiert.

Ist das nur die Fehlermeldung oder verwendest Du tatsächlich einen ODBC-Treiber zum Zugriff auf den SQL-Server. Sollte das der Fall sein, so solltest Du schnell den OLE DB-Provider für MSSQL verwenden. Generell gilt, gibt es einen OLE DB-Provider dann sollte dieser verwendet werden, weil er viel schneller arbeitet als ODBC. ODBC-Treiber sollte man unter ADO nur dann verwenden, wenn es keinen OLE-DB Provider gibt.

[quote="lemmond1976"]
Bei ergebnismengenorientierten Abfragen (Select etc.) kann man die Prozedur wie eine normale Tabelle behandeln.
Also zum Beispiel so:

Select * from test_procedure

Ich brauche dazu ja wohl ein ADODataSet und eine Query.
Und wie muß ich diese beiden im Objekt-Inspektor miteinander verbinden, daß die Query das Ergebnis der Prozedur zurückliefert ?
[/qoute]

Wenn ich mich nicht ganz irre, dann kann man den obigen Code folgendermassen erweitern, um die Rückgabemenge der Stored Procedure in einem Recordset zu speichern:

Delphi-Quellcode:

procedure CallSPmitRS; 
var 
  myCommand : ADOInt.Command; 
  myParam : ADOInt.Parameter;
  myRS : ADOInt.RecordSet; 
  RowsAffected : OleVariant; 
begin 
  // Command-Objekt erzeugen 
  myCommand := CoCommand.Create; 
  with myCommand do 
    begin 
      // Command-Objekt initialisieren 
      CommandType := adCmdStoredProc; 
      CommandText := 'spDoSomething'; 
      // Parameter erzeugen und an das Command-Objekt hängen 
      myParam := CreateParameter('Param1',adChar,adParamInput,30); 
      Parameters.Append(myParam); 
      // Parameterwert setzen 
      Parameters[0].Value := 'Hallo'; 
      // Connection setzen, über die der Befehl abgesetzt wird, 
      // irgendwo im Programm muss es die Connection myADOConnection 
      // geben, diese muss auch (soweit ich weiss) offen sein 
      Set_ActiveConnection (myADOConnection); 
      // In RowsAffected steht drin, auf wie viele Zeilen sich die 
      // Prozedur ausgewirkt hat. 
      myRS := Execute (RowsAffected,EmptyParam,adOptionUnspecified); 
    end; 
  // Command-Objekt wieder freigeben 
  myCommand.Free; 
end;

In myRS steht dann die Ergebnismenge der Stored Procedure drin. Müsste klappen, aber ich weiss das gerade nicht zu 100%.

Viele Grüsse

Frank