Quote:
Oui, je suis sûr d'être connecté,
Ben non, il me semble que tu dis le contraire 3 lignes plus bas.
Quote:
Etape 1 :
Sur l'application elle-même, je m'identifie, me déconnecte, m'identifie, me déconnecte, m'identifie et... problème plus rien n'a faire pour que cela fonctionne à nouveau
Donc si je comprends bien, tu te connectes, déconnectes, reconnectes de multiples fois, jusqu'au moment où tu ne parviens plus à te connecter.
Donc quand tu as le problème, tu n'es pas connecté, comme le laisse entendre l'exception que tu donnes dans ton premier post.
Quote:
Est-ce une piste possible?
Et pourquoi avec une table identique sous Access il n'y aucun problème et qu'avec Informix...
La piste c'est que Access n'est pas Informix...
Les SGDBR et leurs pilotes (ou founisseurs de données si tu préfères) ne sont pas les mêmes, donc ne se comportent pas pareil. Bon ils servent tous deux des données c'est entendu ;) mais entre le moment où tu te connectes et celui où tu récupères tes données il s'en passe des choses.
AMHA ton problème présente le parfait symptôme d'une fuite de connexions dans un pool. Avec un langage comme C# (ou Java, puisque ce sont les mêmes ;) ) ça se produit quand une exception est mal gerée, voire muselée. Exemple en pseudo code:
try
{
OuvrirConnexion
FaireQuelquechose // Poum !! une exception levée ici
FermerConnexion
}
catch
{
TraiterException
}
Dans cet exemple ta connexion n'est pas fermée. Si tu es avec Access qui ne connaît pas les pools de connexions, la connexion est bien fermée à la sortie du bloc try si l'exception se produit MAIS si tu travailles avec un pool de connexion sous Informix (ce que je ne sais pas, mais on dirait que oui) alors la connexion peut ne pas être pas fermée si l'objet Connexion est conçu ainsi. Pour y remédier tu dois reprendre ton code pour toujours fermer explicitement les connexions comme ceci:
try
{
OuvrirConnexion
FaireQuelquechose // Poum !! une exception levée ici
}
catch
{
TraiterException
}
finally
{
FermerConnexion
}
Pour le second problème je ne sais pas à priori, sauf qu'il me semble que ça pourrait être un effet de bord du premier. Essaie de régler d'abord le premier.
Voilà j'espère t'avoir aidé. Tiens nous au courant :)
Ben non, il me semble que tu dis le contraire 3 lignes plus bas.
Donc si je comprends bien, tu te connectes, déconnectes, reconnectes de multiples fois, jusqu'au moment où tu ne parviens plus à te connecter.
Donc quand tu as le problème, tu n'es pas connecté, comme le laisse entendre l'exception que tu donnes dans ton premier post.
La piste c'est que Access n'est pas Informix...
Les SGDBR et leurs pilotes (ou founisseurs de données si tu préfères) ne sont pas les mêmes, donc ne se comportent pas pareil. Bon ils servent tous deux des données c'est entendu ;) mais entre le moment où tu te connectes et celui où tu récupères tes données il s'en passe des choses.
AMHA ton problème présente le parfait symptôme d'une fuite de connexions dans un pool. Avec un langage comme C# (ou Java, puisque ce sont les mêmes ;) ) ça se produit quand une exception est mal gerée, voire muselée. Exemple en pseudo code:
try { OuvrirConnexion FaireQuelquechose // Poum !! une exception levée ici FermerConnexion } catch { TraiterException }Dans cet exemple ta connexion n'est pas fermée. Si tu es avec Access qui ne connaît pas les pools de connexions, la connexion est bien fermée à la sortie du bloc try si l'exception se produit MAIS si tu travailles avec un pool de connexion sous Informix (ce que je ne sais pas, mais on dirait que oui) alors la connexion peut ne pas être pas fermée si l'objet Connexion est conçu ainsi. Pour y remédier tu dois reprendre ton code pour toujours fermer explicitement les connexions comme ceci:
try { OuvrirConnexion FaireQuelquechose // Poum !! une exception levée ici } catch { TraiterException } finally { FermerConnexion }Pour le second problème je ne sais pas à priori, sauf qu'il me semble que ça pourrait être un effet de bord du premier. Essaie de régler d'abord le premier.
Voilà j'espère t'avoir aidé. Tiens nous au courant :)