Dieses Beispiel verwendet eine einfache Abfrage, um zu illustrieren, wie verschiedene Cursortypen auf eine Zeile in der Ergebnismenge reagieren, die aktualisiert wird und dadurch die Reihenfolge in der Ergebnismenge verändert.
Es gibt die folgende Abfolge von Ereignissen:
Eine Anwendung öffnet in der Beispieldatenbank in der folgenden Abfrage einen Cursor.
SELECT EmployeeID, Surname FROM Employees; |
EmployeeID | Surname |
---|---|
102 | Whitney |
105 | Cobb |
160 | Breault |
... | ... |
Die Anwendung ruft die erste Zeile durch den Cursor ab (102).
Die Anwendung ruft die nächste Zeile durch den Cursor ab (105).
Eine weitere Transaktion aktualisiert die Mitarbeiter-ID des Mitarbeiters 102 (Whitney) auf 165 und schreibt die Änderung fest.
In dieser Situation hängen die Ergebnisse der Cursor-Aktionen von der Cursor-Empfindlichkeit ab.
Unempfindliche Cursor Das UPDATE wird weder in der Mitgliedschaft noch in den Werten der Ergebnisse, wie sie durch den Cursor gesehen werden, widergespiegelt:
Maßnahme | Ergebnis |
---|---|
Vorherige Zeile abrufen | Gibt die ursprüngliche Kopie der Zeile zurück (102). |
Erste Zeile abrufen (absoluter Abruf) | Gibt die ursprüngliche Kopie der Zeile zurück (102). |
Zweite Zeile abrufen (absoluter Abruf) | Gibt die ungeänderte Zeile zurück (105). |
Empfindliche Cursor Die Mitgliedschaft der Ergebnismenge hat sich insofern geändert, dass jetzt Zeile 105 die erste Zeile in der Ergebnismenge ist:
Maßnahme | Ergebnis |
---|---|
Vorherige Zeile abrufen | Gibt Zeile nicht gefunden zurück. Die Mitgliedschaft der Ergebnismenge hat sich geändert und 105 ist jetzt die erste Zeile. Der Cursor wird auf die
Position vor der ersten Zeile verschoben.
|
Erste Zeile abrufen (absoluter Abruf) | Gibt Zeile 105 zurück. |
Zweite Zeile abrufen (absoluter Abruf) | Gibt Zeile 160 zurück. |
Außerdem wird beim Abrufen durch einen empfindlichen Cursor die Warnung SQLE_ROW_UPDATED_WARNING ausgegeben, wenn die Zeile seit dem letzten Lesen geändert wurde. Die Warnung wird nur einmal ausgegeben. Aufeinander folgende FETCH-Vorgänge für dieselbe Zeile lösen keine weitere Warnung aus.
Ähnlich gibt auch eine positionsbasierte UPDATE- oder DELETE-Anweisung durch den Cursor auf einer Zeile, die seit dem letzten Abruf geändert wurde, die Fehlermeldung SQLE_ROW_UPDATED_SINCE_READ aus. Eine Anwendung muss das Abrufen einer Zeile nochmals durchführen, damit UPDATE oder DELETE bei einem empfindlichen Cursor funktionieren.
Eine Aktualisierung einer Spalte bewirkt die Warnung oder den Fehler, auch wenn die Spalte vom Cursor nicht referenziert wird. Beispiel: Ein Cursor auf einer Abfrage, der Surname zurückgibt, würde die Aktualisierung melden, auch wenn nur die Spalte Salary geändert worden wäre.
Wertempfindliche Cursor Die Mitgliedschaft der Ergebnismenge ist unveränderlich, und daher ist Zeile 105 weiterhin die zweite Zeile in der Ergebnismenge. Das UPDATE wird in den Werten des Cursors widergespiegelt und erzeugt ein tatsächliches "Loch" in der Ergebnismenge.
Maßnahme | Ergebnis |
---|---|
Vorherige Zeile abrufen | Gibt Zeile nicht gefunden zurück. Die Mitgliedschaft der Ergebnismenge hat sich geändert und 105 ist jetzt die erste Zeile. Der Cursor wird über dem
Loch positioniert: er befindet sich vor Zeile 105.
|
Erste Zeile abrufen (absoluter Abruf) | Gibt Keine aktuelle Cursorzeile zurück. Die Mitgliedschaft der Ergebnismenge hat sich geändert und 105 ist jetzt die erste Zeile. Der Cursor wird über dem
Loch positioniert: er befindet sich vor Zeile 105.
|
Zweite Zeile abrufen (absoluter Abruf) | Gibt Zeile 105 zurück. |
Nicht-empfindliche Cursor In Bezug auf Änderungen sind Mitgliedschaft und Werte der Ergebnismenge unbestimmt. Die Antwort auf einen Abruf der vorherigen Zeile, der ersten Zeile oder der zweiten Zeile hängt von der entsprechenden Optimierungsmethode für die Abfrage ab, nämlich ob die Methode die Erstellung einer Arbeitstabelle erfordert und ob die abgerufene Zeile vom Client vorab abgerufen wurde.
Warnungs- und Fehlerbedingungen für Aktualisierungen kommen in Massenvorgängen nicht vor (Option -b für Datenbankserver).
Kommentieren Sie diese Seite in DocCommentXchange. Senden Sie uns Feedback über diese Seite via E-Mail. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |