Hallo Joachim ! Hab vielen Dank f�r deine ausf�hrliche Ausf�hrung. Ich glaub, ich hab das Wesen verstanden - nun hilft mir auch die Doku etwas weiter. Ich werde jetzt dann mal ein paar Beispiele ausprobieren.
Vielen vielen Dank ! Christian -----Urspr�ngliche Nachricht----- Von: Joachim van de Bruck [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 30. Mai 2002 14:56 An: ASP Datenbankprogrammierung Betreff: [aspdedatabase] AW: Stored Procedures Hallo! > Ich m��te mich innerhalb von ein paar Stunden etwas in Stored Procedures > einarbeiten, habe aber derzeit absolut keine Ahnung davon. Ich wei� nur, > da� das etwas ist, wof�r man den SQL-Server braucht. Hat irgendjemand > von Euch irgendwie dokumentierte Beispiele oder �hnliches, womit ich > mich besch�ftigen kann? Der Zusammenhang, in dem ich es brauche ist ein > ASP-Projekt. Ich m��te morgen fr�h eine gewisse Grundahnung von der > Materie haben. SQL-Server 2000 hab ich am laufen. Fang mit Access an: Eine VIEW besteht aus einer SELECT-Abfrage ohne Parameter. Eine PROCEDURE besteht aus einem einzelnen SELECT-, INSERT-, UPDATE-, DELETE-Statement und hat in der Regel auch Parameter. VIEWs und PROCEDUREs kannst Du unter ASP am besten wie folgt aufrufen: dim ra, cm: set cm = Server.CreateObject("ADODB.Command") cm.ActiveConnection = "...Connection-String..." cm.CommandText = "...Name der View/Proc..." cm.CommandType = adCommandUnknown ' may be you'll know it ?! call cm.Execute(ra, array(...P1..., ...P2..., ...), adExecuteNoRecords) ... oder Du willst ein Recordset zur�ckhaben ... dim rs: set rs = Server.CreateObject("ADODB.Recordset") set rs = cm.Execute(ra, array(...P1..., ...P2..., ...)) In beiden F�llen werden die Parameter einfach in einem Array �bergeben. Die Reihenfolge entspricht dabei der im SQL-Statement. Jetzt zu SQL-Server: Hier kommst Du um die wirklich sehr gute Online-Dokumentation nicht herum. Eine Stored Procedure in SQL Server kann im Gegensatz zu denen in Access aus mehreren Statements bestehen. Zus�tzlich kannst Du Variablen deklarieren und verwenden und Statements f�r die "Programmsteuerung" (IF ... THEN ... ELSE ..., WHILE ..., ...) einsetzen. Und es stehen Dir zahlreiche vordefinierte Stored Procedures (z. B. E-Mails verschicken, Protokolldatens�tze schreiben) zur Verf�gung. Wenn die Beispiele in der Online-Dokumentation nicht ausreichen, findest Du ganze Script-Sammlungen im Internet (Stichwort: Transact-SQL, T-SQL, Stored Procedure, SP, ...). Die SPs kannst Du ganz einfach im Enterprise Manager erstellen und im Query-Analizer erstellen und testen. Tipps: Nenne Deine SPs nie "sp_....", da das f�r die internen Scripts reserviert ist und Dein Script dann immer zun�chst in der Master-DB gesucht wird. Wenn Du ein Recordset nicht mit Firehose-Cursor zur�ckgeben m�chtest, musst Du den Cursor in der SP selber definieren. Seit SQL Server 2000 hat man auch Benutzerdefinierte Funktionen. Die sind etwas einfacher zu handhaben und viele F�lle, die fr�her mit SPs realisiert wurden, k�nnen heute einfacher mit FUNCTIONs gel�st werden, z.B. Berechnungen f�r virtuelle Spalten, komplexe Sub-Selects. Wenn ich eine "alte" SQL-Server-Anwendung betrachte, f�llt mir immer auf, dass man ca. 50% der Stored Procedures durch SUB-Selects, JOINs, TRIGGER oder FUNCTIONs ersetzen kann. 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 | [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
