Discussion :

[Slyteck]

Bonjour à tous,
Je vais tâcher d'expliquer clairement mon problème.
J'ai un service windows développé en Delphi qui inspecte une table.
Quand il y trouve une ligne, il lance une Dll (développée aussi en Delphi) qui utilise les données pour imprimer une édition Crystal. Une fois l'édition terminée, le service libère la dll et attend la prochaine ligne.
Mon problème étant que le service qui lance la dll ne meurt pas, et pire, son process monte à 100% de CPU. J'ai pu tracer que c'est au FreeLibrary(dll) que mon service se plante...

Quelques explications subsidiaires :
J'ai migré cette Dll d'une connexion SQLinks vers ODBC, en utilisant le même composant BDE : TDataBase. Je précise cela car avec SQLinks, je n'ai pas de souci. Je n'ai le problème qu'avec une version de cette dll qui passe par l'ODBC.

Mes pistes envisagées :
Les 2 versions de Dll sont vraiment quasi identique, en tout cas dans leur fermeture, rien n'a changé. L'une fonctionne et pas l'autre.
Je pense donc que c'est vraiment liée à l'ODBC, ce qui empêche le service de libérer la dll correctement...

Quelques détails sur mon environnement :
dll et service développé en Delphi 5
Base de données : Informix
Driver de connexion fourni par OLEDB
Plateforme Windows 2008 server

Que dire de plus ? J'espère avoir été clair.

[ShaiLeTroll]

Tu arrives à lancer une édition Crystal depuis un Service Windows sous Windows 2008 Server, cela ne pose de problème d'interaction avec le bureau ?

Tu utilise encore le BDE ? C'est obsolète depuis 10 ans !
Il faudrait passer en ADO si tu veux exploiter ODBC, ou même un OLEDB en direct, dans un service, tu n'as pas besoin de DataSet et de DBControls, la couche d'accès API sera bien plus performante !

as-tu fourni une session à ton service via SC.exe ?
Le comportement du Service change vraiment entre mode SYSTEM et un mode SESSION

tient un sujet de fulster, un ancien collègue qui avait eu ce problème

[Slyteck]

Je suis précisément en pleine migration BDE vers ADO. Et cette dll fait partie de la prochaine étape.
Mais dans l'attente, pour la compatibilité, j'ai migré cette dll en ODBC.
Le service n'a pas de composant Dataset ou DBControls. Il lance la dll avec des paramètres, qui elle, contient les composants.
Et oui, le service est lancé en mode session. Sur celle de l'administrateur qui plus est. Donc à priori, pas de souci de droit d'accès...

[ShaiLeTroll]

Mais dans l'attente, pour la compatibilité, j'ai migré cette dll en ODBC.

C'est quoi en ODBC ? Tu veux dire utilisation directe avec OLEDB ?

Pense au Coinitialize et CoUninitialize si tu utilises des objets COM de l'ODBC, ces fonctions devant être lancer dans le LoadLibrary et FreeLibrary !

J'ai récemment développé des DLL, plus en 1 an qu'en 10, j'ai constaté des problèmes liés aux Threads lancés DANS une DLL (ou sous DLL en liaison statique C++Builder), il semble que soit préférable de les arrêter avant le FreeLibrary, d'ailleurs bcp de DLL tiers fonctionne aussi avec des fonctions Initialize et Cleanup, j'ai procéder de la même façon !
J'avais comme toi, une consommation processeurs ou une sorte de DeadLock, les threads ayant du mal a s'arrêter !
Par contre, l'appelant était un EXE !

Je parle bien de threads créés dans la DLL, j'avais plutôt pratiquer des thread créés dans l'EXE utilisant simultanément la même DLL, là il n'y a pas de problème !

Sous Server 2008, même avec un mode SESSION, j'ai constaté de grosse limitation sur l'interactivité avec le bureau par exemple (ShellExecute ou CreateProcess)

Tu es en 32 ou 64Bits ?

[Slyteck]

Le driver que j'utilise est le suivant : IBM INFORMIX ODBC DRIVER (fourni par OLEDB).

Et pour répondre à ta dernière question je suis en 32bits, mais le 64 n'est pas très loin dans le planning... :-)

[Slyteck]

Me revoilà ! Et je viens apporter des précisions sur mon problème, puisque ce n'est pas exclusivement lié au fait de passer par un service.

J'ai un EXE (développé en Delphi) qui utilise la même dll. Et je viens de me rendre compte que là aussi, cela plante sur les FreeLibrary de cette dll.

Vous me direz, mais pourquoi tu ne l'as pas vu avant ? Tout simplement parce que les Freelibrary avaient été oublié !

Je pose donc la question (bien que j'ai vu un autre sujet là-dessus) : les FreeLibrary sont-ils si indispensables que ça ?
Car en débugant, j'ai constaté que toutes les procédures Destroy de ma dll s'exécute complètement...