SQLITE_BUSY

Der Ergebniscode SQLITE_BUSY gibt an, dass die Datenbankdatei aufgrund gleichzeitiger Aktivität einer anderen Datenbankverbindung, normalerweise einer Datenbankverbindung in einem separaten Prozess, nicht geschrieben (oder in einigen Fällen gelesen) werden konnte. Wenn sich Prozess A beispielsweise mitten in einer großen Schreibtransaktion befindet und Prozess B gleichzeitig versucht, eine neue Schreibtransaktion zu starten, erhält Prozess B ein SQLITE_BUSY-Ergebnis zurück, da SQLite jeweils nur einen Writer unterstützt. Prozess B muss warten, bis Prozess A seine Transaktion abgeschlossen hat, bevor er eine neue Transaktion starten kann. Die Schnittstellen sqlite3_busy_timeout() und sqlite3_busy_handler() sowie das Busy_timeout-Pragma stehen Prozess B zur Verfügung, um ihn bei der Behandlung von SQLITE_BUSY-Fehlern zu unterstützen. Ein SQLITE_BUSY-Fehler kann zu jedem Zeitpunkt einer Transaktion auftreten: beim ersten Start der Transaktion, bei Schreib- oder Aktualisierungsvorgängen oder beim Commit der Transaktion. Um zu vermeiden, dass mitten in einer Transaktion SQLITE_BUSY-Fehler auftreten, kann die Anwendung BEGIN IMMEDIATE statt nur BEGIN verwenden, um eine Transaktion zu starten. Der Befehl BEGIN IMMEDIATE gibt möglicherweise selbst SQLITE_BUSY zurück, aber wenn er erfolgreich ist, garantiert SQLite, dass keine nachfolgenden Vorgänge in derselben Datenbank bis zum nächsten COMMIT SQLITE_BUSY zurückgeben. Siehe auch: SQLITE_BUSY_RECOVERY und SQLITE_BUSY_SNAPSHOT. Der Ergebniscode SQLITE_BUSY unterscheidet sich von SQLITE_LOCKED darin, dass SQLITE_BUSY auf einen Konflikt mit einer separaten Datenbankverbindung hinweist, wahrscheinlich in einem separaten Prozess, während SQLITE_LOCKED auf einen Konflikt innerhalb derselben Datenbankverbindung (oder manchmal einer Datenbankverbindung mit einem gemeinsam genutzten Cache) hinweist.