SQLite : codes d’erreur

L'erreur SQLITE_NOLFS peut être retournée sur des systèmes qui ne prennent pas en charge de grands fichiers lorsque la base de données devient plus grande que ce que le système de fichiers peut gérer. "NOLFS" signifie "NO Large File Support".

Le code de résultat SQLITE_NOMEM indique que SQLite n'a pas été en mesure d'allouer toute la mémoire nécessaire pour terminer l'opération. En d'autres termes, un appel interne à sqlite3_malloc() ou sqlite3_realloc() a échoué dans un cas où la mémoire étant attribuée était nécessaire pour poursuivre l'opération.

Lorsque vous tentez d'ouvrir un fichier, l'erreur SQLITE_NOTADB indique que le fichier ouvert ne semble pas être un fichier de base de données SQLite.

Le code de résultat SQLITE_NOTFOUND est exposé de trois manières : Le code de résultat SQLITE_NOTFOUND est également utilisé en interne par l'implémentation SQLite, mais ces utilisations internes ne sont pas exposées à l'application.

Le code de résultat SQLITE_NOTICE n'est retourné par aucune interface C/C++. Cependant, SQLITE_NOTICE (ou plutôt l'un de ses codes d'erreur étendus) est parfois utilisé comme le premier argument dans un callback sqlite3_log() pour indiquer qu'une opération inhabituelle a lieu.

Le code de résultat SQLITE_NOTICE_RECOVER_ROLLBACK est passé au callback de sqlite3_log() lorsqu'un journal chaud est retourné.

Le code de résultat SQLITE_NOTICE_RECOVER_WAL est transmis au callback de sqlite3_log() lorsqu'un fichier de base de données en mode WAL est récupéré.

Le code de résultat SQLITE_PERM indique que le mode d'accès demandé pour une base de données nouvellement créée n'a pas pu être fourni.

Le code de résultat SQLITE_PROTOCOL indique un problème avec le protocole de verrouillage des fichiers utilisé par SQLite. L'erreur SQLITE_PROTOCOL n'est actuellement retournée qu'en utilisant le mode WAL et en essayant de démarrer une nouvelle transaction. Il y a une condition de course qui peut se produire lorsque deux connexions de base de données distinctes essayent de démarrer une transaction en même temps en mode WAL. Le perdant de la course recule et essaie de nouveau, après un bref retard. Si la même connexion perd la course de verrouillage des dizaines de fois sur une période de plusieurs secondes, il finira par abandonner et retourner SQLITE_PROTOCOL. L'erreur SQLITE_PROTOCOL devrait apparaître en pratique très rarement, et seulement lorsqu'il y a beaucoup de processus séparés qui rivalisent intensément pour écrire sur la même base de données.

Les indices d'erreur SQLITE_RANGE indiquent que l'argument du nombre de paramètres pour une routine sqlite3_bind ou le nombre de colonne dans une routine sqlite3_colonne est hors de portée.

Le code de résultat SQLITE_READONLY est retourné lorsqu'une tentative est faite pour modifier certaines données pour lesquelles la connexion de base de données actuelle n'a pas la permission d'écriture.

Le code de résultat SQLITE_READONLY_CANTINIT provient de la méthode xShmMap d'un VFS pour indiquer que la région mémoire partagée utilisée par le mode WAL existe mais que son contenu n'est pas fiable et inutilisable par le processus actuel puisque le processus actuel n'a pas d'autorisation d'écriture sur la région mémoire partagée. (La région mémoire partagée pour le mode WAL est normalement un fichier avec un suffixe "-wal" qui est mmappé dans l'espace de processus. Si le processus actuel n'a pas d'autorisation d'écriture sur ce fichier, alors il ne peut pas écrire dans la mémoire partagée.) La logique de niveau supérieur dans SQLite interceptera normalement le code d'erreur et créera une région mémoire partagée temporaire dans la mémoire afin que le processus actuel puisse au moins lire le contenu de la base de données. Ce code de résultat ne devrait pas atteindre la couche d'interface de l'application.

Le code d'erreur SQLITE_READONLY_CANTLOCK est un code d'erreur étendu pour SQLITE_READONLY. Le code d'erreur SQLITE_READONLY_CANTLOCK indique que SQLite n'est pas en mesure d'obtenir un verrou sur une base de données en mode WAL parce que le fichier mémoire partagée associé à cette base de données est en lecture seule.

Le code d'erreur SQLITE_READONLY_DBMOVED est un code d'erreur étendu pour SQLITE_READONLY. Le code d'erreur SQLITE_READONLY_DBMOVED indique qu'une base de données ne peut pas être modifiée parce que le fichier de base de données a été déplacé depuis qu'il a été ouvert, et donc toute tentative de modifier la base de données pourrait entraîner une corruption de la base de données si les processus s'effondrent parce que le journal de renversement ne serait pas correctement nommé.

Le code de résultat SQLITE_READONLY_DIRECTORY indique que la base de données est en lecture seule parce que le processus n'a pas la permission de créer un fichier journal dans le même répertoire que la base de données et la création d'un fichier journal est une condition préalable à l'écriture.

Le code d'erreur SQLITE_READONLY_RECOVERY est un code d'erreur étendu pour SQLITE_READONLY. Le code d'erreur SQLITE_READONLY_RECOVERY indique qu'une base de données en mode WAL ne peut pas être ouverte parce que le fichier de base de données doit être récupéré et la récupération nécessite l'accès à l'écriture, mais seulement l'accès à la lecture est disponible.

Le code d'erreur SQLITE_READONLY_ROLLBACK est un code d'erreur étendu pour SQLITE_READONLY. Le code d'erreur SQLITE_READONLY_ROLLBACK indique qu'une base de données ne peut pas être ouverte parce qu'elle a un journal chaud qui doit être roulé en arrière mais ne peut pas parce que la base de données est en lecture seule.

Le code de résultat SQLITE_SCHEMA indique que le schéma de base de données a changé. Ce code de résultat peut être retourné de sqlite3_step() pour une instruction préparée qui a été générée à l'aide de sqlite3_prepare() ou sqlite3_prepare16(). Si le schéma de base de données a été modifié par un autre processus entre le moment où l'instruction a été préparée et le moment où l'instruction a été exécutée, cette erreur peut résulter. Si une instruction préparée est générée à partir de sqlite3_prepare_v2() alors l'instruction est automatiquement ré-préparée si le schéma change, jusqu'à SQLITE_MAX_SCHEMA_RETRY temps (par défaut : 50). L'interface sqlite3_step() ne retournera à l'application que si l'échec persiste après cette fois de ret. Des riz.

Le code d'erreur SQLITE_TOOBIG indique qu'une chaîne ou BLOB était trop grande. La longueur maximale par défaut d'une chaîne ou BLOB dans SQLite est de 1 000 000 000 octets. Cette longueur maximale peut être modifiée au moment de la compilation en utilisant l'option SQLITE_MAX_LENGTH de compilation ou au moment de l'exécution en utilisant l'interface sqlite3_limit(db,SQLITE_LIMIT_LENGTH,...). L'erreur SQLITE_TOOBIG résulte lorsque SQLite rencontre une chaîne ou BLOB qui dépasse la durée de compilation ou la limite d'exécution. Le code d'erreur SQLITE_TOOBIG peut aussi résulter lorsqu'une instruction SQL est transmise dans une des interfaces sqlite3_prepare_v2(). La longueur maximale d'une instruction SQL est par défaut à une valeur similaire La longueur maximale de l'instruction SQL peut être définie au moment de la compilation en utilisant SQLITE_MAX_SQL_LENGTH ou au moment de l'exécution en utilisant sqlite3_limit(db,SQLITE_LIMIT_SQL_LENGTH,...).

Le code de résultat SQLITE_WARNING n'est retourné par aucune interface C/C++. Cependant, SQLITE_WARNING (ou plutôt l'un de ses codes d'erreurs étendus) est parfois utilisé comme premier argument dans un callback sqlite3_log() pour indiquer qu'une opération inhabituelle et éventuellement mal avisée a lieu.

Le code de résultat SQLITE_WARNING_AUTOINDEX est passé à la callback de sqlite3_log() chaque fois que l'indexation automatique est utilisée. Cela peut servir d'avertissement aux concepteurs d'applications que la base de données pourrait bénéficier d'index supplémentaires.