try catch en sql on obtient un « 0 row(s)

Pourquoi lorsqu’on rajoute un try catch en sql on obtient un « 0 row(s) affected » qui peut poser souci en java pour catcher l’erreur.

Avec myBatis, lorsqu’on travaille avec stored procedure avec try catch et que le premier résultat n’est pas une erreur (0 row(s) affected). MyBatis n’arrive pas à attraper l’erreur, dans mon cas il suffit d’ajouter « set nocount on » pour éviter ce problème. Mais je me pose quand même la question d’où vient ce «0 row(s) affected » ?
Voici un exemple :

Code:

---

SELECT 1/0

---

result

Code:

---

1 2	Msg 8134, Level 16, State 1, Line 1 Divide by zero error encountered.

---

Code:

---

1 2 3 4 5 6 7

--SET NOCOUNT ON BEGIN TRY SELECT 1/0 END TRY BEGIN CATCH RAISERROR('teqt',16,1) END CATCH

---

Result avec l'ajout d'une ligne supplémentaire

Code:

---

1 2 3

(0 row(s) affected) Msg 50000, Level 16, State 1, Line 7 teqt

---

Merci d’avance

Citation:

---

Envoyé par zoltix

Pourquoi lorsqu’on rajoute un try catch en sql on obtient un « 0 row(s) affected » qui peut poser souci en java pour catcher l’erreur.

---

Ce n'est pas le try/catch qui provoque le « 0 row(s) affected ».
c'est plutôt le SET NOCOUNT OFF (et c'est l'option par défaut) qui permet l'affichage du nombre de lignes renvoyées par la requête SQL.
En positionnant l'option SET NOCOUNT à ON tu ne verras plus l'affichage du nombre de lignes renvoyées par la requête SQL.

Par ailleurs, comme best pratice, il faut éviter les bavardages inutiles dans vos procédures SQL en position l'option NOCOUNT à ON

Citation:

---

Envoyé par zinzineti

Ce n'est pas le try/catch qui provoque le « 0 row(s) affected ».
c'est plutôt le SET NOCOUNT OFF (et c'est l'option par défaut) qui permet l'affichage du nombre de lignes renvoyées par la requête SQL.
En positionnant l'option SET NOCOUNT à ON tu ne verras plus l'affichage du nombre de lignes renvoyées par la requête SQL.

Par ailleurs, comme best pratice, il faut éviter les bavardages inutiles dans vos procédures SQL en position l'option NOCOUNT à ON

---

Mais ça ne répond pas a ma question,

Code:

---

SET NOCOUNT OFF

---

est en commentaire.
Je sais qu'il toujours mieux d'éviter le bavardage malgré ça je n'arrive pas a comprendre ce "0 row affected".
Je confirme que c'est bien le try catch qui génère "0 row affected". on peut faire un essai dans SSMS. Comme si, que malgré l'erreur dans un block try catch, il y a toujours un résultat pour pouvoir catcher l'erreur.?? mais pourquoi?

Citation:

---

Envoyé par zoltix

Mais ça ne répond pas a ma question,

Code:

---

SET NOCOUNT OFF

---

est en commentaire.
Je sais qu'il toujours mieux d'éviter le bavardage malgré ça je n'arrive pas a comprendre ce "0 row affected".
Je confirme que c'est bien le try catch qui génère "0 row affected". on peut faire un essai dans SSMS. Comme si, que malgré l'erreur dans un block try catch, il y a toujours un résultat pour pouvoir catcher l'erreur.?? mais pourquoi?

---

Parce que ... Honnêtement je ne vois pas d'autre réponse.
D'ailleurs quand on exécute ce genre de procédure dans SSMS, on voit qu'il ouvre un result set avec rien dedans ; il fait effectivement le select sur rien. Logiquement, on peut voir ça ainsi : l'instruction SELECT initialise un result set. Puis l'exécution plante ; le plantage est rattrapé ; il reste donc un result set vide (il n'est pas fermé).
Il faut juste le savoir et donc prévoir en conséquence.

Votre requête renvoyant zéro lignes, le message renvoyé est parfaitement correct ! Qu'est ce qui vous choque ?
De plus le message de nombre de ligne n'est pas un message d'exception...
Seule le premier paramètre de votre procédure renvoie le code d'erreur. Ce paramètre existe par défaut et n'a pas à être déclaré.
C'est la variable de retour (RETURN) de la proc.

Bref, commencez par vous former à SQL Server....

A +

C'est bien ce que j'explique aussi ça parait normal mais le problème est plus complexe qu'il ne parait dans java. Par exemple dans myBatis, si la première ligne n'est pas une exception dans le résultat il ne détecte pas l’erreur.
Un simple print avant raiserror suffit pour que myBatis ne voit pas l'erreur. C'est peut être un problème de driver ou autre mais on a rien trouvé.
Et surtout, j'aimerais comprendre et savoir comment le résultat est renvoyé et comment il signal qu'il y a une exception au client (protocole).
Ça peut paraître bête mais je vous assure que cela pose beaucoup de problème a de nombreux développeurs java sous myBatis .

Encore merci de votre aide



http://code.google.com/p/mybatis/

Les OR comme MyBatis sont des grosses merdes mal développées, très buguées et sont des bombes à retardement dans les applications.
On a dit des ORM, que c'était le vietnam de l'informatique
Bref, si vous voulez développer correctement évitez ce genre d'horreur !

Comme je l'ais dit c'est le paramètre n°0 de type numérique qui s'il est différent de zéro indique qu'il y a eu une erreur. Dans ce cas, l'objet qui a appelé la proc doit dépiler la pile d'erreur.
Si les gens qui sont conçu cette merde de MyBatis ne savant pas ça, ça promet pour le reste !

A +

J'adore ta réponse. Les architectes java de mon entreprise, on choisi cette crasse comme standard de l'entreprise.
Merci je ne me sens plus seule, mais comment les faire changer d'avis sans une grosse catastrophe car ils vont sans doute dire que c'est la faute de microsoft, je connais bien la rengaine.
Encore un grand merci de ta franchise

Ce message a été composé samsung mobile

Pour faire changer d'avis les doux dingues qui vous emplois, voici quelques éléments :

1) l’article que j'ai écrit il y a déjà quelques années sur l'imbécilité d'utiliser des ORM comme outil systématique de développement dans l'entreprise :
http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

2) l'origine du terme "vietnam de l'informatiqu"
http://blogs.tedneward.com/2006/06/2...r+Science.aspx

3) Dans ce site des débats sur le sujet avec divers avis de professionnels :
http://www.developpez.net/forums/d12...vs-jdo-vs-jpa/
http://www.developpez.net/forums/d12...-baton-milieu/

4) un benchmark qui montre à quel point les ORM sont d'une extrême lenteur face à un code direct :
http://ormeter.net/
Vous y verrez que certains ORM (NHibernate pour e pas le nommer) sont 25 fois plus lent qu'une requête SQL dans une mise à jour !!! Or comme les mises à jour sont bloquantes (accès exclusif) c'est une bombe à retardement qui fait qu'à la montée en charge on est 100 à 10 000 fois plus lent qu'avec des requêtes directes !!!

Pour ma part j'ai fait une dizaine d'audit dans des boites ou les clients avaient des problèmes de perf lié directement à l'usage de l'ORM. Dans deux cas, les boîtes ont fait faillite à cause de cela (éditeurs informatique)

A +