J'ai une instruction d'insertion très simple étant exécutée à partir d'un script PHP exécuté sur un serveur Web Apache Linux Apache. Je peux exécuter la requête amende à partir de SQL Management Studio et elle fonctionne normalement de PHP. Cependant, de temps en temps, je reçois un message d'erreur de mon script PHP que la requête a échoué et la fonction MSSQL_GET_LAST_MESSAGE () renvoie "L'instruction a été terminée".
Quelles sources peuvent provoquer le renvoi de ce message de SQL Server?
3 Réponses :
Vous avez trouvé l'une des parties les plus gênantes de SQL Server. Il existe des situations où une erreur peut être relevée et SQL a généré deux messages d'erreur: le premier à expliquer ce que l'erreur était, et la seconde à dire quelque chose d'utile comme "la déclaration a été résiliée" (qui, techniquement, est le numéro d'erreur 3621). La chose est que SQL, et la plupart de tout ce qui le touche - tel que PHP - ne peut que voir / récupérer / traiter / ou utiliser autrement ce dernier message d'erreur impeccable. Celui qui est en fait utile se perd.
Le moyen rapide de comprendre ce qui se passe est d'exécuter la séquence de commandes menant à l'erreur de SSMS. Ceci, apparemment, ne fonctionnera pas pour vous.
Un moyen Fussier de la comprendre est de définir le profileur SQL pour suivre l'événement d'exception, puis exécutez votre processus. Cela devrait montrer toutes les erreurs qui se sont produites. TANGER dans d'autres événements pertinents (SP: Démarrage, SP: STMTSTARTING, SQL: BatchStarting, tout ce qui est applicable au code Votre soumission à la base de données) indiquera quelle commande augmente l'erreur.
Pour obtenir un code d'erreur numérique à partir de MSSQL, vous pouvez faire une sélection qui ressemble à quelque chose comme
SELECT @@ ERROR comme ERRORCODE
Qui devrait renvoyer le code d'erreur correct.
Vous pouvez également essayer ce code qui est affiché sur php.net.
Donc, avec votre exemple, si je détecte mon message "L'instruction a été résilié", je devrais pouvoir soumettre la requête que vous avez fournie pour obtenir le code d'erreur?
Nevermind, votre solution en théorie semble bonne. Cependant, la variable @@ error sera écrasée si une autre requête frappe la base de données avant d'avoir la possibilité de la questionner. Sur un serveur occupé, cela est très probable.
Le problème que vous rencontrez est un problème connu avec le pilote MSSQL apparemment. Regardez php.net/manual/fr/funcund.msql- Get-Last-Message.php , surtout les commentaires en bas. Les gens ont eu des difficultés avec ce problème depuis longtemps.
Le bloc Type / Catch conserve la portée des choses comme @@ error ou error_message () dans SQL Server afin que vous attrapiez l'erreur correcte. Cependant, puisque MSSQL_Query s'appelle deux fois (une fois dans le si, l'autre dans le corps de l'IF), celles-ci pourraient en fait être deux erreurs différentes, car elles étaient appelées à des moments différents. Je suggérerais de simplement mettre l'essai / attraper autour de la requête avant de l'exécuter du tout, donner le message d'erreur un alias distinct et après avoir exécuté la requête, vérifiez spécifiquement pour que cet alias puisse voir si une erreur a été produite.
Il s'agit d'une référence sur le comportement d'un essai / attrape dans SQL Server: MSDN. microsoft.com/en-us/library/ms175976.aspx
Vous pouvez utiliser le code dans le message pour savoir quelle est l'erreur. Par exemple:
[2627: La déclaration a été résiliée.] p> blockQuote>
Dans ce cas, le code d'erreur est 2627, donc si vous exécutez le SQL ci-dessous, vous connaîtrez le message P>
SELECT msg.text FROM sys.messages msg INNER JOIN sys.syslanguages lng ON lng.msglangid = msg.language_id WHERE msg.message_id = 2627 AND lng.alias = 'English'