nicht angemeldet
MS SQL zeilenweise SP rufen
Hallo zusammen,
ich stehe gerade irgendwie auf dem Schlauch, vielleicht kann mir jemand einen Tipp geben.
Ich möchte ausgehend von einer Tabelle für jeden einzelnen darin enthaltenen Datensatz eine Stored Procedure mit Parametern rufen nur mit SQL Bordmitteln. Also sowas ähnliches wie ein FOR EACH...
Tabelle:
pid INT PK
sid INT FK
scale1 SMALLINT
scale2 SMALLINT
ddate DATETIME
Stored Procedure mit Parametern:
sp_datatransformation
@sid
@scale1
@scale2
@ddate
Schonmal Danke im Vorraus!
LeKuchen
-
Hello,
Ich möchte ausgehend von einer Tabelle für jeden einzelnen darin enthaltenen Datensatz eine Stored Procedure mit Parametern rufen nur mit SQL Bordmitteln. Also sowas ähnliches wie ein FOR EACH...
spontaner, emotionaler Vorschlag? Mach eine Stored Procedure, die dir zuerst alle Datensätze selektiert und anschließend in einer Schleife die andere aufruft...
MfG
Rouven--
-------------------
He is entertaining both out of the car and in the car because if you tell him that a corner is almost flat then he is the guy who is going to try to take it flat even if it means shunting it the other side of it, he will come with the data and say 'hey, I may have crashed and destroyed the car, but I was flat-out'. That is an interesting quality that he has! -- Team Member on Jacques Villeneuve-
Hallo Rouven,
danke, gerade gemerkt, dass ich wohl nicht intensiv genug nach einer Lösung mit Google gesucht habe...
http://weblogs.asp.net/jgalloway/archive/2006/04/12/442618.aspx
Würdest Du das so machen?
Gruss
LeKuchen-
Hello,
Würdest Du das so machen?
jupp, sowas habe ich gemeint.
MfG
Rouven--
-------------------
He is entertaining both out of the car and in the car because if you tell him that a corner is almost flat then he is the guy who is going to try to take it flat even if it means shunting it the other side of it, he will come with the data and say 'hey, I may have crashed and destroyed the car, but I was flat-out'. That is an interesting quality that he has! -- Team Member on Jacques Villeneuve
-
-
-
Servus,
was du brauchst, nennt sich "CURSOR".
DECLARE @varFeld1 int, @varFeld2 varchar(100) -- deklariere die Variablen in die du für jeden Schleifendurchlauf die Werte schreiben willst, die Datentypen sind nur beispielhaft gewählt DECLARE myCursor CURSOR /* LOCAL FAST_FORWARD */ FOR SELECT feld1, feld2 FROM Tabelle -- dein Select Statement OPEN myCursor FETCH NEXT FROM myCursor INTO @varFeld1, @varFeld2 WHILE @@FETCH_STATUS = 0 BEGIN EXEC SP_deineProcedure @varFeld1, @varFeld2 FETCH NEXT FROM myCursor INTO @varFeld1, @varFeld2 -- holt den nächsten Datensatz ab und füllt die variablen END CLOSE myCursor DEALLOCATE myCursorCursors sind für diese Art von Verarbeitung aktuell die einzige Möglichkeit und leider gottes nicht gerade sehr schonend. Es gibt verschiedene Optimierungsmöglichkeiten (auskommentierte Optionen am Anfang), die du dir im Handbuch von MS SQL durchlesen solltest. Und als Hinweis, es gibt in 80% der Fälle wo nur die Verwendung eines Cursors möglich scheint immer eine besser Alternative mit etwas mehr Umschreibeaufwand (Denk noch mal genau nach, was du erreichen willst - was ist der Endsieg, äh das Endziel). Bspw. könntest du eine Funktion schreiben und diese in dein eigentliches SELECT mit einbauen, so könnte sie auch von den selektierten Werten gefüttert werden.
Ciao, Frank
-
Moin Frank,
was du brauchst, nennt sich "CURSOR".
Jo, da bin ich auch schon drauf gestoßen...
Cursors sind für diese Art von Verarbeitung aktuell die einzige Möglichkeit und leider gottes nicht gerade sehr schonend. Es gibt verschiedene Optimierungsmöglichkeiten (auskommentierte Optionen am Anfang), die du dir im Handbuch von MS SQL durchlesen solltest. Und als Hinweis, es gibt in 80% der Fälle wo nur die Verwendung eines Cursors möglich scheint immer eine besser Alternative mit etwas mehr Umschreibeaufwand (Denk noch mal genau nach, was du erreichen willst - was ist der Endsieg, äh das Endziel). Bspw. könntest du eine Funktion schreiben und diese in dein eigentliches SELECT mit einbauen, so könnte sie auch von den selektierten Werten gefüttert werden.
Ja, nach dieser zweiten Möglichkeit hatte ich gesucht - wirds wahrscheinlich auch eine Lösung geben. Performance ist nicht so ausschlaggebend, da diese Aufrufe/Procedures nur einmal für ein Datenbankupdate ausgeführt werden sollen.
Vielen Dank für Deine guten Tipps!
LeKuchen
-
Cursors sind für diese Art von Verarbeitung aktuell die einzige Möglichkeit und leider gottes nicht gerade sehr schonend.
Cursor sind bestmöglich zu vermeiden. Ich weiss jetzt nicht genau wie die implementiert sind, aber bestimmte Cursortypen sperren Daten.
Es gibt verschiedene Optimierungsmöglichkeiten (auskommentierte Optionen am Anfang), die du dir im Handbuch von MS SQL durchlesen solltest.
Immer den read only-Cursortyp benutzen, wenn irgendwie möglich. Oft empfehlen sich zwecks Cursorvermeidung dann auch Datenkopien (temporäre Tabellen bspw.).
Und als Hinweis, es gibt in 80% der Fälle wo nur die Verwendung eines Cursors möglich scheint immer eine besser Alternative mit etwas mehr Umschreibeaufwand.
LOL - der Prozentsatz verhält sich reziprok zur Erfahrung und Verständigkeit des Entwickler. "80%" ist da die Aussage des Zynikers, also des Mannes, der weiss was er schreibt.
Bspw. könntest du eine Funktion schreiben und diese in dein eigentliches SELECT mit einbauen, so könnte sie auch von den selektierten Werten gefüttert werden.
Zum Bleistift. Der Vollständigkeit ist noch anzumerken, dass ein Cursor einen Lauf (Fachwort - LOL) darstellt, wie man ihn bspw. aus Zeiten der ISAM-Tabellen (COBOL, Basic etc.) kennt. Läufe sind immer problematisch.
-
Na, da hab ich ja schon den ganzen Tag drauf gewartet, dass du auch was sagen willst.
Aber recht hast du ja zum Glück mit deinen anmerkungen :) Es drehte sich ja auch nicht um Patterns ;) *harhar*
LOCAL FAST_FORWARD ist im MS SQL Server der schnellste und "schonendste" Cursor.
Als denn, schöne Weihnachten, ich verdünnisier mich in die Sonne :)
Ciao, Frank
-
Als denn, schöne Weihnachten, ich verdünnisier mich in die Sonne :)
Ich fahr in den Osten. Dir auch schöne Weihnachtstage!
-
-
yo,
Der Vollständigkeit ist noch anzumerken, dass ein Cursor einen Lauf (Fachwort - LOL) darstellt
in Bezug auf Datenbanken wohl eher ein Speicherbereich und nicht Lauf, welches das "blinkende" Symbol bei einer Eingabemöglichkeit darstellt.
Ilja
-
-