Announcement

**Tom Peiffer** · 24.09.2003, 09:05

Hallo Dietmar,

die Fehlermeldung spricht doch f�r sich. Der Cursor wird beim ersten Durchlauf der SP initialisiert. Beim rekursiven Durchlauf wird das erneut versucht, deshalb die Meldung.

Ich hab das Problem mit 2 SP gel�st. Die 1. rufts du auf, in der alles initialisiert wird. Anschliessend aus der 1 raus die rekursive SP. Zum Schluss wieder den CURSOR freigeben und fertig. Geht sicherlich noch geschickter, hat bei mir aber geklappt.

Gruss,
Tom Peiffe

**Dietmar Wintzheimer** · 24.09.2003, 13:39

Hallo Tom, 
 
Danke fuer die schnelle Antwort. 
Mir war schon klar dass der Cursor noch irgendwo (Arbeitsspeicher oder tempdb) existiert, wusste aber nicht wo und wie umgehen ... 
Als ich Deinen 2ten Absatz gelesen hatte ging mir ein Licht auf. Jedoch hatte ich noch das Problem, dass in meiner "rekursive SP" ein neuer Cursor selelktiert werden muss. 
D.h., dass ich beim Aufruf von "procBestimmeMenge (@Artikel, @NeuDatum)" mit dem neuen Datum auch einen neuen "SELECT" benoetige. 
Mit einer Cursor-Ubergabe "procBestimmeMenge (@Artikel, @NeuDatum, @cCursor)" und der Funktion CURSOR_STATUS('variable', '@cCursor') hatte ich auch wenig Erfolg. 
Erst nachdem ich statt einem  
   DECLARE cArtikelInfoCursor CURSOR FOR SELECT * FROM ArtikelInfo
WHERE ArtikelInfo.Datum = @NeuDatum 
   OPEN cArtikelInfoCursor  
eine Cursor-Variable verwendet habe 

   DECLARE @cArtikelInfoCursor CURSOR 
   SET @cArtikelInfoCursor = CURSOR LOCAL FOR SELECT * FROM
ArtikelInfo WHERE ArtikelInfo.Datum = @NeuDatum 
   SET @nCursorStatus = CURSOR_STATUS ('variable', '@cArtikelInfoCursor
') 
   IF @nCursorStatus <= 0 
   BEGIN 
      OPEN @cArtikelInfoCursor  
   END 
funktionierte es so, wie es auch sein sollte. Wichtig ist eine Cursor-Variable
zu verwenden und den Cursor mit LOCAL �ffnen .. 
Der Fetch und der andere Rest ist wie gehabt. 
 
Gruesse 
   Dietmar
&#10

Announcement

StoredProcedure, Rekursiv, Cursor

StoredProcedure, Rekursiv, Cursor

Comment

Comment