erasorz a écrit:

Bonjour, à tester : DBHandle().

Cela ne fonctionne pas car le  DBHandle() déclenche un dberror de type "transaction not connected" lorsque justement la transaction n'est pas connectée...
D'ailleurs, je suis justement en train de supprimer tout ces DBHandle() qui ne sont pas utilisés à bon escient. reste à trouver son remplacement...

Dernière modification par Dadone (08-08-2013 13:49:46)

xlat a écrit:

erasorz a écrit:

Bonjour, à tester : DBHandle().

confirme que ca marche avec une connexion odbc en tout cas.

Code: pb

 lb_connected = sqlcq.dbhandle()<> 0 

As tu du code dans la routine événementielle dbrror() de la classe transaction ?
Car chez moi le dbHandle() déclenche cette routine.
En plus le help PB est explicite cette fonction ne sert pas à cela...

Dernière modification par Dadone (08-08-2013 13:55:16)

xlat a écrit:

cette fonction te permet d'obtenir un pointeur bas niveau sur la structure d'acces a ta connexion ( utile pour partager la connexion avec du code écrit en dehors de pb) si il n'y a pas de connexion alors on obtiendra un pointeur null.

Cela n'en reste pas moins une fonction appliquée à un objet de transaction : SQLCA.DBHandle( )
En l'absence de connexion à la bas de données, la fonction n' a pas de sens , ce qui est conforme au fait que cela déclenche le dberror() de la classe transaction comme n'importe qu'elle tentative de communication avec la BD qui est dès lors impossible.

HELP PB :
Transactionobject must exist, and the database must be connected.
DBHandle returns a valid handle only if you are connected to the database. It is not able to determine if the database connection does not exist or has been lost.

Dernière modification par Dadone (08-08-2013 14:45:26)

Bon c'est fin de journée je vais me permettre...

tu peux faire un FileDelete sur le fichier .DB, si ça ne fonctionne pas c'est probablement qu'il y a une transaction connectée

Sinon, tu peux lancer une requête SQL bidon pour voir, du genre :

Code: pb

select 1 into :ll_test from dummy using ta_transaction ;

Déclencher une erreur pour éviter une erreur ????
Je précise que lorsque l'on code la routine événementielle dberror() de la classe transaction, celle-ci se déclenche lorsqu'il y a eut une erreur de base de données.
Par exemple un setTransobject() déclenche cette routine si la transaction n' a pas été initialisée. De même pour un ordre disconnect.
Le but est donc d'éviter ce type d'erreur, en regardant au préalablement avant de lancer certains ordres, si la transaction est bien ouverte afin d'éviter de lancer l'ordre qui déclenchera une erreur BD.
Si la transaction n'est pas ouverte, un disconnect ou un setTransObject() cela ne sert pas à grand chose... et déclenche une erreur BD.
C'est plus clair comme cela ?

Dernière modification par Dadone (09-08-2013 07:36:05)

erasorz a écrit:

Quid d'une variable d'instance ib_connected assignée à la connexion, déconnexion ?

J'ai atterri dans un environnement ou je dois, tant que faire ce peu, améliorer la robustesse.
Cet environnement a près de 15 ans de couches successives, c'est une vraie usine à gaz...
Lorsque pour la première fois j'ai implémenté la classe transaction d'une routine d'erreur, j'en ai eut une vingtaine pour du code qui tourne en production !!!
Bref des connexions, des select SQL, il y a en partout mais vraiment partout. Même avant de se connecter à une BD quelconque, par exemple accéder à la date du serveur avant le login sur la base...
"Et pourtant elle tourne" aurait dit Galilée....
D'où ma question sur le forum car je ne peux pas tracer toutes les connexions et mettre un indicateur...
Tant pis si cela n'existe pas, j'ai magouillé avec une constante qui a la valeur "Transaction not connected" et je contrôle que la base de données à bien été renseigné dans la chaine de connexion. Avec cela j'ai réussit à éviter 80% des déclenchements d'erreurs de la BD pour le reste j'ai supprimé du code pour arriver à zéro pour le moment.
Mais c'est quant même étonnant que cela n'existe pas...mais c'est vrai que lorsque l'on code "normalement", j'en avais jamais eut le besoin....

Dernière modification par Dadone (09-08-2013 13:57:32)