A voir également:
- Requete échoue sans code erreur
- Erreur 0x80070643 - Accueil - Windows
- Code asci - Guide
- Code puk bloqué - Guide
- Code telephone oublié - Guide
- Erreur 0x80070643 Windows 10 : comment résoudre le problème de la mise à jour KB5001716 - Accueil - Windows
5 réponses
Reivax962
Messages postés
3672
Date d'inscription
jeudi 16 juin 2005
Statut
Membre
Dernière intervention
11 février 2021
1 011
Modifié par Reivax962 le 14/11/2016 à 15:29
Modifié par Reivax962 le 14/11/2016 à 15:29
Bonjour,
Je peux te suggérer de lancer un Profiler (Outils, Profiler) sur ta base de données, et d'essayer de capturer la requête qui te pose soucis.
Ça te permettra de voir :
1 - Si elle est effectivement exécutée ;
2 - Son texte exact, que tu pourras essayer de lancer directement ;
3 - Son temps d'exécution. Une erreur possible est en effet un timeout, qui se déclencherait via ODBC mais pas via MS SQL Server Management Studio.
Xavier
Je peux te suggérer de lancer un Profiler (Outils, Profiler) sur ta base de données, et d'essayer de capturer la requête qui te pose soucis.
Ça te permettra de voir :
1 - Si elle est effectivement exécutée ;
2 - Son texte exact, que tu pourras essayer de lancer directement ;
3 - Son temps d'exécution. Une erreur possible est en effet un timeout, qui se déclencherait via ODBC mais pas via MS SQL Server Management Studio.
Xavier
Merci de ta réponse Xavier
quelques éléments de réponse :
1 - Elle n'est pas exécutée et en plus, en étant au sein d'une transaction, son échec fait que la transaction est annulée.
2 - Je récupère déjà son texte exact et en le passant dans Sql Server, je n'ai aucune erreur
3 - Son tps d'exécution est immédiat et conduit presque instantanément à l'erreur. Donc à priori, pas de problème de timeout.
Je pensais à un code erreur renvoyé par Sql Serveur que la couche ODBC n'aurait pas en transco et du coup, ne renverra rien. Mais je ne comprends toujours pas pourquoi, il y aurait un code erreur alors que la rqte passe sans problème.
Il m'arrive parfois d'avoir un échec sur une rqte qui est correct pour un problème de verrou par exemple, mais j'ai bien un message clair.
Là, rien.
Clark
quelques éléments de réponse :
1 - Elle n'est pas exécutée et en plus, en étant au sein d'une transaction, son échec fait que la transaction est annulée.
2 - Je récupère déjà son texte exact et en le passant dans Sql Server, je n'ai aucune erreur
3 - Son tps d'exécution est immédiat et conduit presque instantanément à l'erreur. Donc à priori, pas de problème de timeout.
Je pensais à un code erreur renvoyé par Sql Serveur que la couche ODBC n'aurait pas en transco et du coup, ne renverra rien. Mais je ne comprends toujours pas pourquoi, il y aurait un code erreur alors que la rqte passe sans problème.
Il m'arrive parfois d'avoir un échec sur une rqte qui est correct pour un problème de verrou par exemple, mais j'ai bien un message clair.
Là, rien.
Clark
Reivax962
Messages postés
3672
Date d'inscription
jeudi 16 juin 2005
Statut
Membre
Dernière intervention
11 février 2021
1 011
14 nov. 2016 à 16:10
14 nov. 2016 à 16:10
Et dans le profiler, tu la vois passer ?
Bonjour au forum,
désolé Reivax, je n'ai pas reçu de mail m'informant de ta réponse!?!
Oui je la vois passer par contre, j'ai un BatchStarting mais pas de BatchCompleted ce qui paraît normal vu l'erreur.
Autre élément qui a peut-être son importance.
Dans 99% des cas, cette erreur survient lors de l'ajout d'une ligne dans une table de mouvement de stock. Cette table ayant un trigger qui lors d'un ajout, met à jour 2 autres tables (stock dispo et stock courant)
Le 1% restant concerne des select (très simple)
En espérant que quelqu'un pourra m'aider car je patauge et le client perd un peu patience, même si heureusement, c'est sans conséquence sur les données
Clark
désolé Reivax, je n'ai pas reçu de mail m'informant de ta réponse!?!
Oui je la vois passer par contre, j'ai un BatchStarting mais pas de BatchCompleted ce qui paraît normal vu l'erreur.
Autre élément qui a peut-être son importance.
Dans 99% des cas, cette erreur survient lors de l'ajout d'une ligne dans une table de mouvement de stock. Cette table ayant un trigger qui lors d'un ajout, met à jour 2 autres tables (stock dispo et stock courant)
Le 1% restant concerne des select (très simple)
En espérant que quelqu'un pourra m'aider car je patauge et le client perd un peu patience, même si heureusement, c'est sans conséquence sur les données
Clark
Reivax962
Messages postés
3672
Date d'inscription
jeudi 16 juin 2005
Statut
Membre
Dernière intervention
11 février 2021
1 011
23 nov. 2016 à 10:46
23 nov. 2016 à 10:46
Je suis désolé, mais là, franchement, je ne vois pas... Tu as vérifié les logs de la base de données ? Ils sont assez horribles à lire mais bon...
RE-bonjour au forum,
je n'ai toujours pas la solution à mon problème mais j'ai de nouveaux éléments.
Après SQLInfoGene, je ne récupérai que le libellé du message d'erreur qui était vide comme dit plus haut, pas le code (je pensais le faire et qu'il était vide).
J'ai modifié mon log pour récupérer aussi le code erreur et j'obtiens 00000
Ce qui est bizarre, c'est que, d'après la doc ODBC, ce code signifie un succès. Je ne comprends donc pas pourquoi SQLExec considère que c'est un échec.
Autre chose, j'ai analysé de nouveau les logs du profiler, je vois bien passé la requête, sauf que contrairement à ce que je dis plus haut (décidément), il y a bien un batchcompleted après le batchstarting.
Donc la rqte semble bien s'exécuter dans SQL Server (sauf que, comme je récupère une erreur, j'annule la transaction contenant la rqte) et ODBC renvoi un code erreur succès
Alors, est-ce un problème côté SQLExec? J'ai envoyé une demande côté PCSoft, on verra ce que ça donnera.
Maintenant, si ces nouveaux éléments font tilt chez quelqu'un,n'hésitez pas.
Clark
je n'ai toujours pas la solution à mon problème mais j'ai de nouveaux éléments.
Après SQLInfoGene, je ne récupérai que le libellé du message d'erreur qui était vide comme dit plus haut, pas le code (je pensais le faire et qu'il était vide).
J'ai modifié mon log pour récupérer aussi le code erreur et j'obtiens 00000
Ce qui est bizarre, c'est que, d'après la doc ODBC, ce code signifie un succès. Je ne comprends donc pas pourquoi SQLExec considère que c'est un échec.
Autre chose, j'ai analysé de nouveau les logs du profiler, je vois bien passé la requête, sauf que contrairement à ce que je dis plus haut (décidément), il y a bien un batchcompleted après le batchstarting.
Donc la rqte semble bien s'exécuter dans SQL Server (sauf que, comme je récupère une erreur, j'annule la transaction contenant la rqte) et ODBC renvoi un code erreur succès
Alors, est-ce un problème côté SQLExec? J'ai envoyé une demande côté PCSoft, on verra ce que ça donnera.
Maintenant, si ces nouveaux éléments font tilt chez quelqu'un,n'hésitez pas.
Clark
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Je n'ai toujours pas résolu mon problème.
J'ai eu un retour de PCSoft qui n'ont pas connaissance de ce problème et me demande un projet test, sauf que ce problème ne se produit que chez le client et, bien que quotidienne, de façon assez aléatoire.
Donc je continue mes recherches en écumant les forums.
Donc si quelqu'un a une idée, je suis toujours preneur.
Clark
J'ai eu un retour de PCSoft qui n'ont pas connaissance de ce problème et me demande un projet test, sauf que ce problème ne se produit que chez le client et, bien que quotidienne, de façon assez aléatoire.
Donc je continue mes recherches en écumant les forums.
Donc si quelqu'un a une idée, je suis toujours preneur.
Clark
