Dynamische Cursor (Datenbankmodul)

Dynamische Cursor sind das Gegenteil von statischen Cursorn. Dynamische Cursor spiegeln alle Änderungen an den Zeilen in den Resultsets beim Scrollen durch den Cursor wider. Die Datenwerte, Reihenfolge und Mitgliedschaft der Zeilen im Resultset können sich bei jedem Abrufvorgang ändern. Jede UPDATE-, INSERT- und DELETE-Anweisung, die von einem Benutzer ausgeführt wurde, ist über den Cursor sichtbar. Aktualisierungen sind sofort sichtbar, wenn sie über den Cursor mithilfe einer API-Funktion, wie z. B. SQLSetPos, oder der WHERE CURRENT OF-Klausel von Transact-SQL ausgeführt wurden. Aktualisierungen, die außerhalb des Cursors ausgeführt werden, sind nur dann sichtbar, wenn ein Commit für sie ausgeführt wurde, es sei denn, die Transaktionsisolationsstufe des Cursors wurde so festgelegt, dass ein Commit vor dem Lesevorgang nicht ausgeführt sein muss.

Dynamische Cursorpläne verwenden nie Räumlichkeitsindizes.

Hinweis

Wenn der zum Ausführen einer Abfrage für einen dynamischen Cursor ausgewählte Ausführungsplan einen Heapscan verwendet, und es ist eine Seiten- oder Tabellensperre aktiviert, kann das Löschen einer Zeile dazu führen, dass die Zuordnung für die gesamte Seite aufgehoben wird. In diesem Fall können die Marker, die von dynamischen Cursorn zum Positionieren verwendet werden, ungültig werden, und ein nachfolgender Abrufvorgang vom Cursor kann den Fehler 16931 erzeugen. Mögliche Lösungen sind z. B. das Erstellen eines gruppierten Indexes in der Tabelle, das Verwenden eines anderen Cursortyps oder Überlegungen, ob es möglich ist, Sperren auf der Seiten- und Tabellenebene zu verhindern.

Hinweis

In SQL Server werden für dynamische Cursor immer Aktualisierungen der Arbeitstabelle durchgeführt. Das bedeutet, dass die aktuelle Zeile aktualisiert wird, selbst wenn im Rahmen der Aktualisierung Schlüsselspalten geändert werden. In SQL Server 2000 wurde die aktuelle Zeile als gelöscht markiert (so wie das bei an der falschen Stelle positionierten Keysetcursorn der Fall gewesen wäre), aber die Zeile wurde nicht an das Ende der Arbeitstabelle eingefügt (wie das bei Keysetcursorn der Fall war). Das führte dazu, dass bei der Cursoraktualisierung die Zeile nicht gefunden werden konnte und als fehlend gemeldet wurde. SQL Server gewährleistet die Synchronität der Cursorarbeitstabelle, und die Aktualisierung kann die Zeile finden, weil sie die neuen Schlüssel enthält.