Ist es möglich eine Select-Anweisung auf einer StoredProc auszuführen?

[Jörg Seither]

Hallo

Ist es eigentlich mit dem MS SQL Server 2000 möglich eine Select-Anweisung auf einer StoredProc auszuführen. Also "Select * from StoredProc @Param1 = Value, etc. WHERE ....." Beim Interbase Server ist dies ja möglich, wenn bei der StoredProc SUSPEND eingesetzt wird. Damit sind die StoredProc meines Erachtens extrem flexibel. Ich hoffe es gibt eine ähnliche Möglichkeit beim MS SQL Server.

Vielen Dank im voraus

[Patrick Sack]

Hi,
<br>
<br>CREATE PROCEDURE proc
<br> @xx varchar(40)
<br>AS
<br>SELECT x
<br> FROM y where x = @xx
<br>GO
<br>
<br>Select * from Proc 'ldjlfjd' where ....
<br>
<br>Mehr Infos dazu in der OnlineHilfe des MS SQL Servers. Suchen nach "create procedure"
<br>
<br>mfg
<br>p

[Olaf Steffan]

Hallo Patrick,<BR><BR>dein Beispiel lässt sich bei mir leider nicht nachvollziehen. Auch in der Hilfe habe ich nichts gefunden. Muss man irgendwo bestimmte Optionen einstellen? Ich erhalte die Fehlermeldung:<BR>"Server: Nachr.-Nr. 208, Schweregrad 16, Status 3, Zeile 1<BR>Ungültiger Objektname 'test'.<BR>Mit Angabe eines Parameters (wie in deinem Beispiel) meckert er gar einen Syntaxfehler an. Ich könnte diese Geschichte in meiner derzeitigen Arbeit gut gebrauchen. Vielleicht hast du ja noch einen Tip für mich?!<BR><BR>Vielen Dank<BR><BR>Ola

[Patrick Sack]

Sorry,
<br>
<br>habe den Code nicht auf dem SQL Server getestet. Jetzt stelle ich auch fest das das nicht geht (war wohl noch in Gedanken beinm IB).
"Anscheinend" kann man eine Stored Procedure nur mit Execute öffnen.
Wenn man das in einem Select machen will, dann benötigt man eine Function (create Function) das geht aber, so glaube ich nur mit dem SQL Server 2000. "Anscheinend" werden in einem solchen Fall aber auch nur "einfach" Werte zurück geben und nicht wie bei dem IB eine liste mit suspend. (Ein Select From Function geht also nicht)
<br>
<br>Leider habe ich derzeit keinen SQL Server 2000 zur Hand, an dem ich ein Beispiel erstellen / testen könnte drum:
<br>Detalierte Infos zu Functionen in der folgenden Diskussion (damit sollte man Functionen erstellen können):
<br><a href="/webx?50@@.ee8917b/4">http://www.entwickler-forum.de\webx?50@@.ee8917b/4</a>
<br>
<br>Noch mals 'tschuldigung für die falsche Antwort.
<br>
<br>mfg
<br>P

[Ilia Riano]

Ansonsten ist http://www.schwider.de eine gute Anlaufstelle für Fragen bzgl. Mikrosoft Technologien

[Andreas Kosch]

Hallo,

der "Umweg" über SELECT ist nicht notwendig, da die ADO-Objekte (Connection, Command und Recordset) direkt eine Stored Procedure aufrufen können (CommandType := <b>adCmdStoredProc</b>), die eine Ergebnismenge zurückliefert:
<pre>

aCommand := CoCommand.Create;
try
with aCommand do
begin
CommandType := adCmdStoredProc;
Set_CommandText('stprSoundexName1Diff');
Set_ActiveConnection(aConnection);
Parameters.Refresh;
Parameters[1].Value := vName;
// aRS -> _Recordset Interface-Zeiger für die Ergebnismenge
aRS := Execute(vRowsAffected, EmptyParam, adOptionUnspecified);
iReturnValue := Parameters[0].Value;
end;
finally
aCommand := nil;
end;
....
</pre>
Mit den ADO Express-Komponenten von Delphi geht das einfacher, da hier der CommandType-Wert direkt im Objektinspektor gesetzt wird

[Patrick Sack]

Hallo Andreas,
<br>
<br>wenn ich Jörg richtig verstanden habe, dann liegt ihm sehr viel an der "Where" Bedingung. D.h. hat man eine Procedure, die einem das Ergebnis A liefert, so möchte man ja ggf. mal in einem anderen Grid nicht das gesamte Ergebnis von A sondern nur einen Teil der Menge haben. Und hier ist es auf dem IB wirklich einfach noch eine Where Klausel anzuhängen. Mir fällt kein Weg ein wie man soetwas auf dem SQL Server regeln könnte.
<br>Oder angenommen ich möchte in einer zweiten Procedure auf die Ergebnismenge der ersten Procedure zugreifen und dieses noch manipulieren (um dann die manipulierten Werte zurück zu liefern). Das geht anscheinend auch nicht mit dem SQL Server.
Sicher man könnte jetzt einen Filter auf das Recordset-Objekt setzen, aber das wäre ja nicht das selbe bei CursorTyp=clUseClient.
<br>
<br>Wenn das wirklich so ist, dann ist das schon eine starke Einschränkung (klarer Punktsieg für den IB).
Was ich hier bei den Tests (Version 7) auch feststellen mußte ist, das man anscheinend beim MS SQL Server nicht folgenden Code verwenden kann:
<pre>
FOR Select ...
From ...
Where ...
INTO :Test
Do
Begin
...
</pre>
Eigentlich schade das man statt dessen mit Cursorn herum fuhrwerkeln muß.
<br>
<br>mfg
<br>P

[Andreas Kosch]

Hallo,

das Einschränken der Ergebnismenge ist auch für ADO und den MS SQL Server kein Problem - wobei es da gleich 3 Alternativen gibt:

1. Stored Procedure verwendet einen Parameter für die WHERE-Bedingungen (Idealfall, da die SQL-Datenbank filtert).

2. Der Client nutzt die Recordset-Eigenschaft <i>Filter</i>, um die Ergebnismenge mit Hilfe der <i>OLE DB Client Cursor Engine</i> lokal zu filtern (d.h. die SQL-Datenbank ist aussen vor).

3. Die Stored Procedure liefert direkt eine Ergebnismenge (Cursor) zurück, die von einer zweiten Prozedur ausgewertet werden kann