Hallo!
> > hast du schon mal versucht eine stored proc als datenquelle
> > anzugeben, die mehrere statements abarbeitet?
> > da bleibt die anzeige weiss, selbst wenn zum schluss ein
> > recordset daherkommt.
> > generell habe ich ohne ADO noch keine storedproc
> > zum funktionieren gebracht, die keine records zur�ckgibt
> >
> > aber vielleich denke ich da nur zu *eingefahren*
> >
> > christian
>
> Interessant, dass das so bekannt ist...
> Ich habe vor ein paar tagen dieses Problem angefragt, aber ohne
> Antwort...
>
> Kennst Du auch den Grund und vielleicht workarounds?
> Eigentlich sollte das doch Standard-Anwendung von SPs sein...
>
> �ber den Query-Analyzer geht alles prima, aber von ADO aus... No
> chance...
> Wahrscheinlich w�rde es funktionieren die eigentliche SP von einer
> anderen SP aus aufzurufen, welche von ADO aufgerufen wird, aber das
> kann's ja wohl nicht gewesen sein...
>
> Hat noch jemand Wissen in diesem Bereich?
> Joachim?
Das Thema ist ja wirklich sehr interessant.
Christian sagt, dass man komplexe SPs nur mit ADO ausf�hren kann, und
Claudius behauptet glatt das Gegenteil.
Leider (?) fehlen mir Erfahrungen mit Access/MSDE. Ich mach halt nur
Access oder SQL Server. In Access besteht die SP nur aus einem einzelnen
Statement, in SQL Server k�nnen beliebig viele Statements (128 MB!)
hintereinander gesetzt werden. Man trennt diese mit "GO", um logische
Einheiten an die Datenbank Engine zu �bergeben; man kann auch in einer
SP andere SPs in beliebiger Anzahl aufrufen und diese sogar
verschachteln (32 Ebenen).
Ich hatte noch keine Probleme, eine komplexe SP mit ADO aufzurufen.
Allerdings mache ich das auch immer �ber das Command-Objekt, wobei auch
adStoredProc als Commandtype angegeben wird.
M�gliche "Fallen" oder Hindernisse sind:
1.
manche T-SQL-Statements m�ssen in SPs den Besitzer angegeben haben (gilt
f�r fast alle Statements der DDL = Data Definition Language)
2.
Der R�ckgabewert (Return-Code oder Recordset) m�ssen sauber definiert
werden. Alle Recordset-R�ckgaben sollten �ber Parameter erfolgen. Eine
einfache Stored Procedure (1 Statement der DML) kann auch ein Recordset
als R�ckgabewert �bergeben ("set rs = cmd.Execute(...)"; dieses
Recordset hat dann immer den Firehose-Cursor. Bei R�ckgabe �ber
Parameter sind beliebige Cursortypen m�glich.
3.
Man sollte nie adCmdUnknown als Commandtype angeben, also den Parameter
auch nicht auslassen. ADO und ggf. die Datenbank-Engine k�nnen dann beim
"Rumprobieren" auch mal irren. Bei "cmd.Execute('myTable')" schickt ADO
folgende Statements an die Datenbank: "Exec myTable - call myTable -
Select * from myTable". Alle CommandTypes haben keinen Einfluss auf die
Datenbank, sondern bestimmen nur, was ADO an die Datenbank schickt. Wenn
man "cmd.CommendText = '{? = call (?,?,?)}'" kann man auch adCmdText als
CommandType verwenden, muss dann aber auch mit ".Parameters.Append(...)"
arbeiten, um R�ckgabewert, Eingabe- und Ausgabeparameter ui
unterscheiden.
Durch "cmd.CommandType = ad StoredProc" leitet ADO den Prozeduraufruf
direkt an die Datenbank-Engine. Wo soll es dabei Probleme geben?
Freundliche Gr��e
Joachim van de Bruck
| [aspdedatabase] als [email protected] subscribed
| http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv
| Sie k�nnen sich unter folgender URL an- und abmelden:
| http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
