API-Servercursor

Einschränkungen für API-Servercursor

Eine Anwendung kann die folgenden Anweisungen beim Verwenden von API-Servercursorn nicht ausführen:

• Transact-SQL Anweisungen, die SQL Server in Servercursorn nicht unterstützt.

• Batches oder gespeicherte Prozeduren, die mehrere Resultsets zurückgeben.

• SELECT-Anweisungen, die die Klauseln COMPUTE, COMPUTE BY, FOR BROWSE oder INTO enthalten.

• Eine EXECUTE-Anweisung, die auf eine remote gespeicherte Prozedur verweist.

Implementierung von API-Servercursorn

Der SQL Server Native Client-OLE DB-Anbieter und der SQL Server Native Client-ODBC-Treiber verwenden diese speziellen gespeicherten Systemprozeduren, um dem Server Cursorvorgänge zu signalisieren:

• sp_cursoropen definiert die SQL-Anweisung so, dass sie dem Cursor und den Cursoroptionen zugeordnet wird, und füllt anschließend den Cursor auf.

• sp_cursorfetch ruft eine Zeile oder einen Zeilenblock vom Cursor ab.

• sp_cursorclose schließt den Cursor und hebt seine Zuordnung auf.

• sp_cursoroption wird verwendet, um verschiedene Cursoroptionen festzulegen.

• sp_cursor wird verwendet, um positionierte Aktualisierungen anzufordern.

• sp_cursorprepare kompiliert die Transact-SQL-Anweisung oder den Batch, der einem Cursor zugeordnet ist, in einen Ausführungsplan, erstellt den Cursor jedoch nicht.

• sp_cursorexecute erstellt einen Cursor und füllt ihn auf der Grundlage des von sp_cursorprepare erstellten Ausführungsplanes auf.

• sp_cursorunprepare verwirft den Ausführungsplan aus sp_cursorprepare.

• sp_cursorprepexec kompiliert einen Plan für die übermittelte Transact-SQL-Anweisung oder den Batch, der einem Cursor zugeordnet ist, erstellt den Cursor und füllt ihn. sp_cursorprepexec kombiniert das Verhalten von sp_cursorprepare und sp_cursorexecute.

Diese gespeicherten Systemprozeduren werden in den Ablaufverfolgungen von SQL Server Profiler der Anwendungen von ADO, OLE DB und ODBC angezeigt, die API-Servercursor verwenden. Sie sind nur für die interne Verwendung des SQL Server Native Client-OLE DB-Anbieters und des SQL Server Native Client-ODBC-Treibers vorgesehen. Die vollständige Funktionalität dieser Prozeduren steht den Anwendungen über die Verwendung der Cursorfunktionalität der Datenbank-APIs zur Verfügung. Die Prozeduren direkt in einer Anwendung anzugeben, wird nicht unterstützt.

Wenn SQL Server eine Anweisung für eine Verbindung ausführt, kann erst dann eine andere Anweisung über diese Verbindung ausgeführt werden, wenn alle Ergebnisse der ersten Anweisung verarbeitet oder abgebrochen wurden. Diese Regel gilt auch beim Verwenden von API-Servercursorn; für die Anwendung entsteht jedoch der Eindruck, als ob SQL Server begonnen hätte, mehrere aktive Anweisungen über eine Verbindung zu unterstützen. Der Grund dafür ist, dass das vollständige Resultset im Servercursor gespeichert wird, und die einzigen Anweisungen, die an SQL Server übertragen werden, sind die Ausführungen der gespeicherten Systemprozeduren sp_cursor. SQL Server führt die gespeicherte Prozedur aus, und sobald der Client das Resultset abfragt, können auch andere Anweisungen ausgeführt werden. Der OLE DB-Anbieter und der ODBC-Treiber fragen immer alle Ergebnisse einer gespeicherten Prozedur sp_cursor ab, ehe die Anwendung die weitere Steuerung wieder übernimmt. Dies ermöglicht es Anwendungen, Abrufvorgänge mit mehreren aktiven Servercursorn zu verzahnen.

In dieser Tabelle wird dargestellt, wie eine Anwendung zwei Cursor gleichzeitig über eine Verbindung mithilfe von zwei Anweisungshandles verarbeiten kann.

Da nach dem Aufrufen einer gespeicherten Prozedur sp_cursor keine Ergebnisse für eine Verbindung offen bleiben, können Sie mehrere Transact-SQL-Anweisungen gleichzeitig über eine einzelne Verbindung ausführen, sofern diese alle mit API-Servercursorn ausgeführt werden.

Angeben von API-Servercursorn

Es folgt eine Zusammenfassung der Verwendungsweise von API-Servercursorn in den folgenden APIs:

• OLE DB

  • Öffnen Sie ein Sitzungsobjekt, öffnen Sie ein Befehlsobjekt, und geben Sie den Befehlstext an.

  • Legen Sie Rowseteigenschaften, wie DBPROP_OTHERINSERT, DBPROP_OTHERUPDATEDELETE, DBPROP_OWNINSERT, DBPROP_OWNUDPATEDELETE fest, um das Verhalten der Cursor zu steuern.

  • Führen Sie das Befehlsobjekt aus.

  • Rufen Sie die Zeilen im Resultset mithilfe der Methoden IRowset::GetNextRows, IRowsetLocate::GetRowsAt, IRowsetLocate::GetRowsAtBookmark und IRowsetScroll::GetRowsAtRatio ab.

• ODBC

  • Stellen Sie eine Verbindung her, und rufen Sie SQLAllocHandle auf, um Anweisungshandles zuzuordnen.

  • Rufen Sie SQLSetStmtAttr auf, um die Attribute SQL_ATTR_CURSOR_TYPE, SQL_ATTR_CONCURRENCY und SQL_ATTR_ROW_ARRAY_SIZE festzulegen. Sie können alternativ das Cursorverhalten durch Festlegen der Attribute SQL_ATTR_CURSOR_SCROLLABLE und SQL_ATTR_CURSOR_SENSITIVITY angeben.

  • Führen Sie eine Transact-SQL-Anweisung aus, entweder mit SQLExecDirect oder mit SQLPrepare und SQLExecute.

  • Rufen Sie Zeilen oder Zeilenblöcke mithilfe von SQLFetch oder SQLFetchScroll ab.

• ADO

  • Definieren Sie ein Connection-Objekt und ein Recordset-Objekt, und führen Sie dann die Open-Methode für das Connection-Objekt aus.

  • Führen Sie die Open-Methode für das Recordset-Objekt aus, und geben Sie dabei die Parameter CursorType und/oder LockType an.

  • Rufen Sie Zeilen mithilfe der Methoden Move, MoveFirst, MoveLast, MoveNext und MovePrevious des Recordset-Objekts ab.

API-Servercursor und SET-Optionen

Wenn in SQL Server eine Abrufanweisung ausgegeben wird und es eine Änderung an einer der folgenden, den Plan beeinflussenden Optionen oder an einer der für indizierte Sichten oder berechnete Spalten benötigten Optionen gibt, verwendet der Cursor einen Snapshot der Optionswerte, die zum Zeitpunkt galten, als der Cursor geöffnet wurde. Diese Werte werden für alle nachfolgenden Abrufvorgänge verwendet, und die Änderungen im aktuellen Kontext werden ignoriert.

Siehe auch

Konzepte