procédure stockée/connection timeout

Bonjour,

J'écris car je suis un peu perdu...

Une application qui a fonctionné sans souci pendant un moment s'est mis à renvoyer une erreur durant mes vacances.

Voici les quelques premières lignes du détail de l'erreur:

Citation:

---

************** Exception Text **************
System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning()

---

J'ai un peu de mal... Est-ce un timeout lors de la connexion ou lors de l'exécution de la procédure stockée ?

L'un comme l'autre, cela me pose problème étant donné que différents contrôles sur le formulaire sont bien remplis et tirent leurs données dans la même DB. Du coup, je me dis que la connexion est sensée bien se passer.

De l'autre, lorsque j'exécute la procédure dans management, elle me donne le résultat en 0 sec. Du coup, je me dis que le problème ne vient pas de là non plus.

Je tourne donc en rond. Auriez-vous une suggestion ?

SqlException est souvent due à un souci de connexion à ta base de données et d'après le message d'erreur il s'agit de la durée de connexion qui prend trop de temps à s'ouvrir.

Pour modifier la durée minimale avant de lancer une exception si la connexion ne s'ouvre pas tu peux le faire via la chaine de connexion en ajoutant Connect Timeout= duree_en_minute.

Cela peut ne pas corriger ton problème vu que tu dis que certaines formulaires arrivent bien à communiquer avec ta base de données et récupérer des données.

En effet, je ne pense pas que cela résoudra mon problème (je vais tout de même tester).

Voici tout de même quelques détails supplémentaires :

Je ne travaille qu'avec des datasets fortement typés qui utilisent uniquement des procédures stockées (j'essaie en fait d'éviter toute instruction sql du côté .net pour laisser cela sur le server sql).

J'ai un dataset qui contient 4 TableAdapters (et leur DataTable correspondante).

3 d'entre-eux servent à remplir 3 Combobox différentes qui servent en fait de paramètres pour la procédure stockée du 4e TableAdapter.

Du coup, tout ce que je fais moi, c'est utilisé les méthodes Fill de chaque TableAdapter. A part avoir défini la ConnectionString, je ne touche plus à rien.

Je suis prêt à copier un bout de code ici mais je ne vois pas trop ce qui serait intéressant dans le cas présent.

Bon et bien, après avoir simplement fait sur le tableadapter qui pose problème clic droit > configure et avoir été jusqu'au bout sans rien modifier, cela refonctionne.

Je clos donc le sujet mais cela reste tout de même étrange. P-e un charmant collègue qui aurait été changé quelque chose à la procédure stockée sans m'en informer...

Bref, ça marche.

Merci encore (et sorry pour le double post).

Griftou.

Citation:

---

Envoyé par griftou

. P-e un charmant collègue qui aurait été changé quelque chose à la procédure stockée sans m'en informer...

---

Cela me semble très très improbable, car la stack indique clairement qu'il s'agit d'un time-out de connexion, pas d'un time-out d'exécution.

Alors je donne ma langue au chat.

Qu'est-ce qui pourrait donner se genre d'erreur et être résolu en faisant un configure du tableadapter sans rien changer ?

Perso, aucune idée...

Fausse joie...

Cela a résolu le problème "en local" (cad sur ma machine de dev) mais dans l'environnement de prod (citrix), toujours la même erreur...

Si les combobox ne se remplissaient pas, je pourrais conclure que la communication avec le server sql ne se fait pas mais ce n'est pas le cas...

Comment procéderiez-vous pour trouver la cause de ceci ?

Griftou.

Je patauge toujours...

J'ai même été fouillé dans le code du dataset pour voir où il ouvrait la connexion mais je ne vois rien de suspect...

Y a-t-il des outils qui me permettraient de détecter où se trouve le blocage ?

Griftou.

Citation:

---

Envoyé par griftou

Bon et bien, après avoir simplement fait sur le tableadapter qui pose problème clic droit > configure et avoir été jusqu'au bout sans rien modifier, cela refonctionne.

---

Tu as effectué cette action à partir de la base de production ou de la base de développement ?
Si c'est avec la base de Dev et que ça ne fonctionne plus avec la base de Prod alors regardes bien si les schémas sont identiques, que la procédure stockée marche très bien sur la Prod etc.

C'est bien identique des 2 côtés...

D'ailleurs, pour builder l'exe que je distribue, je modifie la connectionstring dans les settings pour avoir une connexion vers la db de prod.

Donc je teste bien sûr une dernière fois avant de distribuer l'exe et cela fonctionne.

Je teste ensuite l'exe que je place sur le serveur et ça marche.

Par contre une fois que je teste en y accédent via une connexion citrix, là ça plante. Et encore une fois, seulement pour un seul tableadapter.

Bonsoir,

Avez-vous essayé de mettre le TimeOut de la commande à 0 (donc l’infini), un collègue a déjà fait ça pour résoudre ce genre de problème. Ca avait fonctionné même si MSDN déconseille cela :

Citation:

---

A value of 0 indications no limit, and should be avoided in a CommandTimeout because an attempt to execute a command will wait indefinitely.

---

Citation:

---

Envoyé par Sankasssss

Avez-vous essayé de mettre le TimeOut de la commande ...

---

Je ne pense pas que cela soit lié au CommandTimeout de la commande sinon le message d'erreur ne renverrai pas une SqlException.

Je n'en ai aucune idée, je vois juste ceci :

Citation:

---

System.Data.SqlClient.SqlException (0x80131904): Timeout expired

---

Cela ne coûte rien d'essayer... :aie:

Ne cherchez plus. C'est résolu...

C'est un problème avec le serveur d'imprimante (spooler) d'après ce que j'ai compris (j'y connais pas grand chose du côté technique citrix ^^).

Mes collègues du helpdesk, après moult insistances de mon collègue (qui avait aussi des soucis dans diverses applications) et moi, ont finalement consenti à regarder s'il n'y avait pas qqch qui clochait de leur côté et bizarrement, après avoir restarté certains trucs, ça marche tout de suite mieux...

Vive la gueguerre entre services...

Bref, merci à tous d'avoir passé un peu de temps là dessus.

Griftou.

P.S. : Le pourquoi de ce message d'erreur m'intrigue tout de même...

certains se sont laissé piéger par le "sqlconnection" de la pile des appels d'erreur
j'ai fait le test car ça me semblait bien être la pile du CommandTimeout

et un timeout d'exécution affiche le même message et la même pile que ce que cite le posteur de départ, c'en est donc bien un

pour l'explication, lorsque qu'on exécute une requete (ou une procédure stockée ou autre) par défaut on a le droit à 30 secondes, si la requete (ou la sp) met plus de temps à s'exécuter arrivé à 30s ca déclenche l'erreur que tu as
le temps maximum est définissable sur le SqlCommand.CommandTimeOut comme le disait sankasssss

Une chose dont je suis sûr est que je ne suis pas le seul à ne pas comprendre le rapport entre le serveur d'imprimante et ta procédure stockée. :aie:

Ah mais moi non plus je ne comprends pas...

C'est p-e du au fait que la procédure sert à remplir un rapport MS Reporting Service et que le report viewer cherche l'imprimante par défaut.

Enfin ça me semble gros quand même.

Ca peut aussi venir d'une interaction bizarre avec l'environnement citrix...

Citation:

---

Envoyé par griftou

C'est p-e du au fait que la procédure sert à remplir un rapport MS Reporting Service et que le report viewer cherche l'imprimante par défaut.

---

Une explication plausible. :ccool:

Sinon un lien que j'ai trouvé et qui pourrait être utile la prochaine fois.

Sinon, j'ai quand même une question...

En utilisant des datasets fortement typés avec des procédures stockées, vous la mettez où l'instruction pour augmenter le timeout ? Pcq via le tableadpter, je n'ai pas trouver l'objet sqlcommand:aie:

Citation:

---

Envoyé par griftou

En utilisant des datasets fortement typés avec des procédures stockées, vous la mettez où l'instruction pour augmenter le timeout ? Pcq via le tableadpter, je n'ai pas trouver l'objet sqlcommand:aie:

---

Très bonne question. :ccool: Tu devrais pouvoir y arriver avec la solution exposée ici utilisant les classes partielles.

Merci ! Dans l'idéal, je ne devrais jamais avoir à l'utiliser (une procédure stockée qui met plus de 30s à s'exécuter, c'est qu'il y a un problème à la db en général) mais je vais le garder sous le coude. On ne sait jamais.