Codes SQLSTATE

SQLSTATEs fournissent des informations détaillées sur la cause d’un avertissement ou d’une erreur. Les SQLSTATEs de ce manuel sont basés sur ceux trouvés dans la spécification CLI ISO/IEF, bien que les SQLSTATEs qui commencent par la messagerie instantanée soient spécifiques à ODBC.

Contrairement aux codes de retour, les SQLSTATEs de ce manuel sont des instructions et les pilotes ne sont pas tenus de les retourner. Par conséquent, alors que les pilotes doivent retourner l’état SQLSTATE approprié pour toute erreur ou avertissement qu’ils sont capables de détecter, les applications ne doivent pas compter sur ce problème toujours. Les raisons de cette situation sont deux raisons :

• Incomplétité Bien que ce manuel répertorie un grand nombre d’erreurs et d’avertissements et les causes possibles de ces erreurs et avertissements, il n’est pas complet et probablement jamais le sera ; les implémentations de pilotes varient simplement trop. Tout pilote donné ne retourne probablement pas tous les SQLSTATEs répertoriés dans ce manuel et peut renvoyer les SQLSTATEs non répertoriés dans ce manuel.

• Complexité Certains moteurs de base de données , en particulier les moteurs de base de données relationnelles, retournent littéralement des milliers d’erreurs et d’avertissements. Les pilotes de ces moteurs sont peu susceptibles de mapper toutes ces erreurs et avertissements à SQLSTATEs en raison de l’effort impliqué, de l’exactitude des mappages, de la grande taille du code résultant et de la faible valeur du code résultant, qui retourne souvent des erreurs de programmation qui ne doivent jamais être rencontrées au moment de l’exécution. Par conséquent, les pilotes doivent mapper autant d’erreurs et d’avertissements que cela semble raisonnable et être sûr de mapper ces erreurs et avertissements sur lesquels la logique d’application peut être basée, comme SQLSTATE 01004 (données tronquées).

Étant donné que les SQLSTATEs ne sont pas retournés de manière fiable, la plupart des applications les affichent simplement à l’utilisateur avec leur message de diagnostic associé, qui est souvent adapté à l’erreur ou à l’avertissement spécifique qui s’est produit et au code d’erreur natif. Il y a rarement une perte de fonctionnalités dans ce cas, car les applications ne peuvent pas baser la logique de programmation sur la plupart des SQLSTATEs de toute façon. Par exemple, supposons que SQLExecDirect retourne SQLSTATE 42000 (erreur de syntaxe ou violation d’accès). Si l’instruction SQL qui a provoqué cette erreur est codée en dur ou générée par l’application, il s’agit d’une erreur de programmation et le code doit être résolu. Si l’instruction SQL est entrée par l’utilisateur, il s’agit d’une erreur utilisateur et l’application a fait tout ce qui est possible en informant l’utilisateur du problème.

Lorsque les applications effectuent une logique de programmation de base sur SQLSTATEs, elles doivent être préparées pour que SQLSTATE ne soit pas retourné ou pour qu’un autre SQLSTATE soit retourné. Exactement quels SQLSTATEs sont retournés de manière fiable ne peuvent être basés que sur l’expérience avec de nombreux pilotes. Toutefois, une directive générale est que les SQLSTATEs pour les erreurs qui se produisent dans le pilote ou le Gestionnaire de pilotes, par opposition à la source de données, sont plus susceptibles d’être retournées de manière fiable. Par exemple, la plupart des pilotes retournent probablement SQLSTATE HYC00 (fonctionnalité facultative non implémentée), tandis que moins de pilotes retournent probablement SQLSTATE 42021 (La colonne existe déjà).

Les SQLSTATEs suivants indiquent des erreurs ou des avertissements au moment de l’exécution et sont de bons candidats sur lesquels baser la logique de programmation. Toutefois, il n’y a aucune garantie que tous les conducteurs les retournent.

• 01004 (données tronquées)

• 01S02 (Valeur d’option modifiée)

• HY008 (Opération annulée)

• HYC00 (fonctionnalité facultative non implémentée)

• HYT00 (expiration du délai d’expiration)

SQLSTATE HYC00 (fonctionnalité facultative non implémentée) est particulièrement important, car il s’agit de la seule façon dont une application peut déterminer si un pilote prend en charge une instruction ou un attribut de connexion particulier.

Pour obtenir la liste complète des SQLSTATEs et des fonctions qui les retournent, consultez l’annexe A : Codes d’erreur ODBC. Pour obtenir une explication détaillée des conditions dans lesquelles chaque fonction peut retourner un SQLSTATE particulier, consultez cette fonction.