FAQ n°24388, publiée le 01/01/2015
Dans quel cas la connexion à une base de données est permise en développement, mais échoue après déploiement d'un site ou d'un webservice hébergé par le serveur d'application de WEBDEV ?

Lorsqu'un site ou un webservice se connecte à une base de données client/serveur avec un connecteur natif, il faut que le client de la base de données soit installé sur le serveur. C'est exactement le même principe que pour le poste de développement (cf FAQ 19840).


Si après le déploiement d'un site ou d'un webservice, et installation sur le serveur web du client de la base de données, la connexion avec HOuvreConnexion reste impossible : 

"Erreur de l'accès natif Oracle, ou SQL SERVER, ou PostgreSQL, ou MySQL, ou MariaDB..."

"Aucune bibliothèque d'accès à ???" (numéro d'erreur 1038),

"Le connecteur natif ??? nécessite la DLL ??? et ses dépendances" (numéro d'erreur 52)


C'est que le client ne peut pas être chargé car soit : 

  • il a été installé dans un mode de compilation 32/64 bits différent de celui du serveur d'application de WEBDEV :
    • si le serveur d'application est installé en 32 bits, le client de la base de données doit être en 32 bits,
    • si le serveur d'application est installé en 64 bits, le client de la base de données doit être en 64 bits,
    • si pour une base de données le client n'est disponible qu'en 32 bits et que le serveur d'application a été installé en 32 bits, il faut donc réinstaller le serveur d'application en 64 bits,
    • inversement si un client d'une base de données n'est proposé par son éditeur qu'en 64 bits mais que le serveur d'application a été installé en 32 bits, il faut donc réinstaller le serveur d'application en 64 bits.

      Le mode de compilation 32 / 64 bits d'un serveur d'application peut être vu à distance en interrogeant sa version : 
      Comment interroger à distance le serveur d'application de WEBDEV

  • il a été installé pour un utilisateur du serveur qui n'est pas celui avec lequel le site est exécuté.

    En effet le code WLangage serveur d'un site web, ou d'un webservice, est exécuté par défaut avec un compte Windows "invité internet" aux droits restreints. Il faut que le client de la base de données soit visible pour cet utilisateur de Windows. Par exemple si le PATH sert à trouver le client de la base de données, il faut que le PATH de l'utilisateur qui exécute le site contienne l'emplacement du client de la base.


Bon à savoir sur le sujet :

  • Le même principe s'applique lorsque la connexion à une base de données se fait avec un provider OLE DB, ou un pilote ODBC.

  • L'utilisateur qui sert à exécuter le code des sites et webservices est :
      • ouvrir le centre de contrôle d'hébergement (CCHébergement.exe),
      • ouvrir le détail de l'utilisateur avec lequel le site ou webservice dont la connexion échoue a été déployé,
      • vérifier l'utilisateur de l'OS configuré dans le volet "Compte OS" : 



    • vérifiable dans le volet "Détail" du gestionnaire de tâche de Windows, en consultant la colonne "Nom d'utilisateur" du processus WD280SESSION.EXE : 



  • Il est possible de vérifier le contenu du PATH auquel le code serveur d'un site à accès avec la fonction SysEnvironnement.

  • Les clients des bases de données peuvent avoir des dépendances système manquantes (package redistribuable Microsoft...). Dans ce cas la même erreur remonte en cas d'échec de connexion. Les DLLs manquantes peuvent être repérées sur le serveur avec l'utilitaire Procmon, en filtrant les accès fichiers de WD280SESSION.EXE. On peut ainsi voir le chargement du connecteur natif, puis toutes les DLL qui sont ensuite rechercher pour le client de la base de données. Un "NOT FOUND" apparaît lorsque le système ne sait pas trouver une DLL nécessaire.

  • Le blog contient une sujet détaillé sur ce principe dans le cas des éditeurs : 
    Connexion à une base de données depuis l'analyse d'un projet, l'importance du mode de compilation 32/64 bits de l'éditeur de WINDEV ou WEBDEV ...