Discussion :

[Higgins]

Bonjour,

J'utilise une TSQLconnection pour accéder à une base de données SQL Server 2008 à partir d'une application FMX (RAD STUDIO XE3)
J'ouvre la connexion au lancement de l'application et je la garde ouverte jusqu'à la fermeture.
En mode "Client lourd", tout va bien. En revanche, en environnement distribué (type citrix), il semble y avoir des ruptures de connexion. L'état de la connexion est toujours Open mais elle n'est plus reliée au serveur SQL(sans que ce soit intercepté par onDisconnect). Du coup, lorsque j'essaie d'exécuter une procédure stockée: Violation d'accès.
J'ai temporairement résolu le pb en fermant/réouvrant la connexion à la demande, mais les performances en souffrent (tps d'attente à chaque reconnexion au serveur).
Avez-vous au choix:
- un moyen de détecter la perte de connexion?
- des "best practices" pour gérer les connexions dans ce contexte et en général?
- d'autres idées?
Merci d'avance

[ShaiLeTroll]

En DBX, C++Builder 2007 et Sybase Anywhere 10, il semble que mon ancien collègue avait un problème similaire

Toujours connecté sur TSQLConnection mais pas vraiment car micro-coupure réseau ou que sais-je !

La solution, était d'encaspuler tous les appels au Query dans une série de fonction
Si la fonction échoue, selon le code d'erreur en retour, cela laissait l'erreur remonté si c'était "une erreur gérée" ou alors se tentait d'abord une reconnexion, relançait le SQL, et si l'erreur persistait, cela la laissait remonter

Ainsi la reconnexion ne se produit que si il y a une erreur, en temps normal, on a rarement des erreurs avec ses SQL
en tout cas, moi j'en ai peu en prod à cause du code toujours à cause du contexte,
comme une violation de clé (fait parti des code d'erreur gérée)
comme une perte de connexion (ne fait pas parti des erreurs gérées)

[Higgins]

La solution, était d'encaspuler tous les appels au Query dans une série de fonction
Si la fonction échoue, selon le code d'erreur en retour, cela laissait l'erreur remonté si c'était "une erreur gérée" ou alors se tentait d'abord une reconnexion, relançait le SQL, et si l'erreur persistait, cela la laissait remonter

C'est effectivement ce sur quoi je suis en train de travailler.
Accessoirement, j'ai une autre erreur bizarre: à l'exécution d'une procédure stockée, j'obtiens

La connexion est occupée avec les résultats d'une autre commande

alors que SQLConnection.datasetcount=0 juste avant l'appel

[Higgins]

Faute de solution plus "propre", j'ai appliqué la méthode de ShaiLeTroll.
Pour ceux que ça intéresse, en ce qui concerne l'erreur

La connexion est occupée avec les résultats d'une autre commande

J'ai réussi à activé MARS (Multiple Active Result Set) sur SQL server, il suffit d'ajouter

Mars_Connection=True

dans la section Params du TSQLConnection