Cursor in einem Cursor

[Daman]

Hallo Leute,

frohes neues. Also übermorgen erst. Aber ich denke mal, dass zur Zeit alle in Urlaub sind, bis auf mich vielleicht

Ich habe folgendes Problem. Mein System (SQL Server 2005) verträgt keinen Cursor in einem Cursor. Folgende Fehlermeldung taucht dann auf:

Die Abfrage hat die maximale Anzahl von Resultsets überschritten, die im Ergebnisraster angezeigt werden können. Nur die ersten 100 Resultsets werden im Raster angezeigt.

Mein Cursor schaut ungefähr so aus:
[highlight=sql]DECLARE @c_i_abteilungID int
DECLARE @c_vc_vorname varchar(500)
DECLARE c_abteilungenCursor CURSOR
FOR SELECT ID FROM [dbo].[Abteilung]
OPEN c_abteilungenCursor
FETCH NEXT FROM c_abteilungenCursor
INTO @c_i_abteilungID
WHILE (@@FETCH_STATUS = 0)
BEGIN
DECLARE c_selectUeberstundenCursor CURSOR
FOR SELECT vorname FROM STAMMDATEN
WHERE AbteilungID = @c_i_abteilungID
OPEN c_selectUeberstundenCursor
FETCH NEXT FROM c_selectUeberstundenCursor
INTO @c_vc_vorname
WHILE (@@FETCH_STATUS = 0)
BEGIN
SELECT @c_vc_vorname
FETCH NEXT FROM c_selectUeberstundenCursor
END
CLOSE c_selectUeberstundenCursor
DEALLOCATE c_selectUeberstundenCursor

FETCH NEXT FROM c_abteilungenCursor INTO @c_i_abteilungID
END
CLOSE c_abteilungenCursor
DEALLOCATE c_abteilungenCursor[/highlight]

Kann man evtl Einstellungen bzgl maximale Anzahl von Resultsets irgendwo vornehmen?

Muss ich das System wechseln, wenn ich sowas von einem System verlange? Oder muss man das anders lösen?

Als ich ein Metadaten Manager für eine Oracle Datenbank geschrieben habe, da hat die Datenbank nicht so rumgezickt.

Hat evtl wer eine andere Lösung?

Beste Grüße und ein Frohes Neues Jahr
Daman

[O. Helper]

Hallo Daman,

ich glaube Du interpretierst die Fehlermeldung falsch; die ist nicht von der Database Engine, die führt das Statement schon vollständig aus.
Die Meldung kommt von SSMS selbst, den Du führst da mehr als 1.000 einzelne SELECT Statements aus, nämlich dies
[highlight=SQL]SELECT @c_vc_vorname[/highlight]
und das liefert dir eben jedes mal einen ResultSet mit theoretisch x Datensätze (Stichwort MARS [hier nur ein Row je Set]) und da denkt sich SSMS halt: "Mehr als 1000 ResultSet * n Rows kann der Knabe vor der Glotze eh nicht mehr überblicken und durchscrollen, da schenke ich mir doch gleich die Anzeige und beglück ihn mit einer Fehlermeldung".

Ein Cursor ist immer die aller letzte Wahl, man sollte es immer Mengenorientiert lösen und in der Regel kann man das auch immer; es sein den man hat ein ungünstiges Datenmodel gewählt.

Alles im Allen mutet Dein Cursor hier auch etwas sehr merkwürdig an.
Was willst Du damit überhaupt erreichen?

[ebis]

1) http://entwickler-forum.de/showthread.php?t=42101SQL kann man auch ordenlich formatieren
2)
Wozu macht Du im inneren Cursor SELECT @c_vc_vorname ?
Gibt halt immer ein Resultset...

Als ich ein Metadaten Manager für eine Oracle Datenbank geschrieben habe, da hat die Datenbank nicht so rumgezickt.

Ob das für oder gegen Oracle spricht....

Hat evtl wer eine andere Lösung?

wozu überhaupt einen Cursor?

[O. Helper]

Das hier
[highlight=SQL]SELECT vorname
FROM [STAMMDATEN] AS STD
INNER JOIN
[Abteilung] AS ABT
ON STD.AbteilungID = ABT.Id[/HIGHLIGHT]
liefert Dir das gleiche und zwar als 1 ResultSet mit n Datensätze und das völlig ohne Cursor.

[Daman]

Leute ich wünschte es wäre alles so einfach. Aber mein Vorgänger hat sich keine Gedanken darüber gemacht, Primärschlüssel und Fremschlüssel einzuführen. Er hat es einfach irgendwie reingespeichert. Nun fällt mir nix anderes ein, als alle Werte einzeln zu vergleichen.

Ich hab des alles anders gelöst. Hab es in einzelne Funktionen zerlegt. in 3 genauer gesagt. Jetzt ist des zwar nicht mehr so schön, aber es funktioniert.

Danke für die Feedbacks

[Daman]

wozu überhaupt einen Cursor?

einen Cursor brauche ich, um alle Spalten jedes Mitarbeiters in jeder Abteilung temporär für einen Vergleich zu besitzen.

[O. Helper]

Primärschlüssel und Fremschlüssel einzuführen.

Um Tabellen in einem Select-Statement zu joinen, sind PK/FK nicht zwingend notwendig.

Das Statement, was ich gepostet habe, macht das gleiche wie Dein Cursor; egal ob PK/FK vorhanden ist oder nicht.

[Daman]

[highlight=sql]DECLARE @c_i_abteilungID int
DECLARE @c_vc_vorname varchar(500)
DECLARE c_abteilungenCursor CURSOR
FOR SELECT ID FROM [dbo].[Abteilung]
OPEN c_abteilungenCursor
FETCH NEXT FROM c_abteilungenCursor
INTO @c_i_abteilungID
WHILE (@@FETCH_STATUS = 0)
BEGIN
DECLARE c_selectUeberstundenCursor CURSOR
FOR SELECT vorname FROM STAMMDATEN
WHERE AbteilungID = @c_i_abteilungID
OPEN c_selectUeberstundenCursor
FETCH NEXT FROM c_selectUeberstundenCursor
INTO @c_vc_vorname
WHILE (@@FETCH_STATUS = 0)
BEGIN
-- Hier tu ich noch was
-- UPDATE Table bla, wenn Entry vorhanden
-- Ansonsten Insert Into Table bla


FETCH NEXT FROM c_selectUeberstundenCursor
END
CLOSE c_selectUeberstundenCursor
DEALLOCATE c_selectUeberstundenCursor

FETCH NEXT FROM c_abteilungenCursor INTO @c_i_abteilungID
END
CLOSE c_abteilungenCursor
DEALLOCATE c_abteilungenCursor[/highlight]


Dass ich bei den Cursor jeweils nur eine Variable selektiert habe is nur zur Verdeutlichung. Es sind ein wenig mehr. Diese Variablen werden dann noch für Subtraktions/Additions/Multi... - Transaktionen verwendet.

Es kann sein, dass es mit dem Innerjoin funktioniert. Aber ich seh es einfach als übersichtlicher und einfacher, wenn ich es durch einen Cursor löse.