Discussion :

[castorcharly]

Bonjour,

Je rencontre un problème avec une connexion à une base de donnée MsSql sous service.

Je suis sous DXE2 enterprise. et je travaille avec un serveur Mssql local 2008 R2 sous OS Seven 64.

les unités de mon projet peuvent être compilée sous deux exe, le premier est le service de prod, le second projet est un exe win32 classique.
Ces deux projets utilisent la même unité et les mêmes params pour la connexion à la base.
Ce sont tous les deux des projets 32 bits.

Lorsque j'exécute l'exe win32, la connexion se déroule sans problème, quand je lance le service j'ai une erreur comme quoi il ne trouve pas la librairie VendorLib (sqlncli10.dll) qui est située sur mon poste dans
C:\Windows\SysWOW64

J'ai fait pas mal de tentative pour permettre au service de pouvoir localiser cette DLL:
1) Compte de connexion du service sous mon compte
2) passage comme paramètre du chemin complet de la lib
3) renseignement du chemin C:\Windows\SysWOW64 dans le path général.

Rien n'y fait, j'ai toujours le même message d'erreur en exécutant le service.

Avez-vous une idée pour palier ce problème ?

[ShaiLeTroll]

Un Service 32Bits dans un environnement 64Bits !

J'aurais proposé le compte de session, tu a déjà fait, mince si ça fonctionne pas !
Peut-être forcer le service comme "interactif"

[castorcharly]

Un Service 32Bits dans un environnement 64Bits !

J'aurais proposé le compte de session, tu a déjà fait, mince si ça fonctionne pas !
Peut-être forcer le service comme "interactif"

Je développe sur un OS 64, mais mon projet n'ira pas forcement sur une machine 64bits.

J'ai aussi indiqué au service de travailler sous Interactif et nada.

Merci, d'autres idées ?

[Andnotor]

Un service 32 bits fonctionne très bien sur une machine 64 bits

Logiquement, tu ne devrais pas avoir à spécifier de chemin du tout ! Si tu en passes un du genre C:\Windows\SysWOW64, l'OS va te le convertir en C:\Windows\SysWOW64\SysWOW64

[ShaiLeTroll]

Je me rappel que pour ADO
il fallait pour un service :
une alias ODBC de type "source de données système"
Et ne pas oublier le CoInitialize dans TService.OnStart car c'est plus ou moins TApplication que le fait (initialization de Forms) pour un EXE VCL et un service n'ayant pas de TApplication mais TApplicationService ... forcément !

Un service 32 bits fonctionne très bien sur une machine 64 bits

Il fonctionne mais isolé dans sa bulle

nos services peuvent fonctionner en mode manuel (exe) ou mode service
nos services embarquent du DCOM,
en mode manuel, tu te retrouves avec une instance par client au lieu d'une commune ...
en mode service, je ne sais pas, je crois que mon reponsable a encore un soucis à ce sujet
Comme on passe en DataSnap en abandonnant le DCOM, le problème n'existera plus !

[castorcharly]

Je me rappel que pour ADO
il fallait pour un service :
une alias ODBC de type "source de données système"
Et ne pas oublier le CoInitialize dans TService.OnStart car c'est plus ou moins TApplication que le fait (initialization de Forms) pour un EXE VCL et un service n'ayant pas de TApplication mais TApplicationService ... forcément !


Il fonctionne mais isolé dans sa bulle : Serveur DCOM MultiThread

Hummmm! Coinitialize, ça c'est une bonne idée, je vais vérifier de ce coté.

Un service 32 bits fonctionne très bien sur une machine 64 bits

Logiquement, tu ne devrais pas avoir à spécifier de chemin du tout ! Si tu en passes un du genre C:\Windows\SysWOW64, l'OS va te le convertir en C:\Windows\SysWOW64\SysWOW64

Je suis tout à fait d'accord, j'ai juste fait un test en mettant le chemin complet, mais je suis revenu au format normal.

[castorcharly]

Merci ShaiLeTroll,




Coinitalize à bien résolu le problème dans le service.

Pourtant, j'ai l'habitude de l'utiliser mais j'ai le cerveau ramolli par la canicule !