Lorsqu'une analyse contient des descriptions de tables provenant d'une base de données externe, l'établissement de la connexion à la base par l'éditeur d'analyses doit charger le client de la base de données. Cela s'applique :

  • aux connexion en accès natif ou via un provider OLE DB,
  • à toutes les bases de données, Oracle, SQL Server, MySQL, PostgreSQL, MariaDB...


Le client de la base de données est toujours fourni par l'éditeur de la base, sous la forme d'une ou plusieurs DLL (libmysql.dll pour MySQL, libpq.dll pour PostgreSQL, oci32.dll pour Oracle ...). Si le client de la base de données n'a pas une procédure d'installation qui ajoute toutes ses DLL et dépendances dans un dossier système de Windows, ou connu de la variable d'environnement PATH, la DLL du client doit être copiée le dossier du framework de l'éditeur (dossier rappelé plus loin).

 

Le mode de compilation 32 ou 64 bits de l'ensemble des protagonistes est donc ici déterminant, car Windows interdit à un programme 32 bits de charger des DLL 64 bits. Et inversement, un programme 64 bits ne peut pas charger des DLL 32 bits.


Donc, si WINDEV ou WEBDEV est installé en 64 bits, il ne pourra pas effectuer une connexion si le client de la base de données n'est installé qu'en 32 bits. Si tel est le cas, un message indiquera que l'accès natif nécessite la couche client de la base de données. Par exemple :

 

 

Le même cas se présente pour le mode test GO d'un projet. Si le test est lancé en 64 bits, donc si la configuration courante du projet est un exécutable 64 bits, alors que le client de la base de données n'est qu'en 32 bits, le client ne sera pas trouvé lors d'un appel de HOuvreConnexion pas exemple. Et donc bien sûr le même principe est aussi appliqué à l'exécutable déployé, s'il est compilé en 32 bits, donc créé à partir d'une configuration de projet 32 bits, il devra trouver les DLL 32 bits du client de la base de données. Et s'il est compilé en 64 bits, il devra avoir les DLL du client 64 bits de la base de données.


Cela explique pourquoi on peut avoir :

  • sur un même poste une version de WINDEV ou de WEBDEV qui parvient à se connecter, et pas une autre. Elles ne sont simplement pas installées dans le même mode de compilation 32 / 64 bits. Rappelons qu'un petit rond en haut à droite de la barre de titre des éditeurs permet immédiatement de savoir si l'installation est en 32 ou 64 bits ...


  • un utilitaire comme WDSQL ou WDMAP qui parvient à se connecter, mais pas l'application en mode test. Par exemple WDSQL64.EXE (donc 64 bits) permet une connexion à la base utilisée par un site WEBDEV, mais depuis le test du même site la connexion échoue : le test a été lancé en 32 bits et non pas en 64 bits. Rappelons que l'option "Déboguer en 64 bits" du bouton "Mode test" du volet "Projet" du ruban de WEBDEV permet d'indiquer sur le poste de développement si le test Go du site est lancé en 32 ou 64 bits :

 

Le même cas se présente pour le déploiement d'un site web ou d'un webservice (cf FAQ 24388). Le serveur d'application de WEBDEV qui héberge le site, ou le webservice, devra avoir un client de la base de données installé :

  • dans le même mode de compilation que lui.
    Si le serveur d'application est installé en 64 bits, il faut que le client de la base de données soit en 32 bits. Et inversement, si le serveur d'application est en 64 bits, il faut obligatoirement le client de la base de données en 64 bits.
    Le mode de compilation d'un serveur d'application déployé est visible par l'URL permettant de consulter sa version à distance.
  • pour l'utilisateur qui exécute le site. Par défaut les traitements WLangage serveurs d'un site ou d'un webservice sont exécutés avec le compte WEBDEV configuré pour l'exécution des sites. C'est un compte invité interne IUSR.


Dans tous les cas, afin de permettre le chargement du client d'une base de données, il faut donc bien avoir :

  • WINDEV ou WEBDEV installé dans le même mode de compilation que le client de la base de données,
  • placer la ou les DLL du client de la base de données dans le dossier du framework de l'éditeur.
    Il s'agit du dossier suivant :
    • pour un client de base de données 32 bits :
      \WINDEV ou WEBDEV\Programmes\Framework\Win32x86\
    • pour un client de base de données 64 bits :
      \WINDEV ou WEBDEV\Programmes\Framework\Win64x86\

 

La page d'aide des accès natifs indique les modules et les spécificités éventuelles de chaque client :

  • Connecteur Natif MySQL pour WINDEV et WEBDEV,
  • Connecteur Natif MariaDB pour WINDEV et WEBDEV,
  • Connecteur Natif Oracle pour WINDEV et WEBDEV,
  • Connecteur Natif SQL Server pour WINDEV et WEBDEV,
  • Connecteur Natif PostgreSQL pour WINDEV et WEBDEV...

 

Au passage, le même principe s'applique pour tout module diffusé sous la forme d'une DLL :

  • le champ ActiveX par exemple, au niveau de l'éditeur verra les ActiveX :
    • 32 bits uniquement si l'éditeur est en 32 bits,
    • 64 bits uniquement si l'éditeur est en 64 bits.
  • les fonctions appelées dans une DLL de Windows ou d'un pilote spécifique d'une périphérique, via une description d'API...

Cas particuliers / bon à savoir :

  • Le test d'un webservice en local ne propose pas de choix du mode de compilation. Il est par défaut en 32 bits. Un mode opératoire spécifique permet de forcer le test en 64 bits si besoin :
    https://faq.pcsoft.fr/23344-faq-read.awp

  • Si le chargement d'un client d'une base de données reste en échec alors qu'il est installé dans même mode de compilation que le processus qui tente une connexion (éditeur, application, site, webservice...), c'est qu'une dépendance du client de la base de données est manquante. Par exemple l'éditeur du client de la base de données utilise une API d'un package redistribuable Visual C++ de Microsoft qui :
    • n'est pas installé sur le poste,
    • ou a été installé sur le poste, mais pour un autre utilisateur que celui qui exécute le processus. Par exemple le processus est un site web ou un webservice, exécuté avec un invité internet (IUSR*) qui n'a pas accès à l'emplacement contenant le client, ou ses dépendances.

      Dans pareil cas un utilitaire tel que procmon "accroché" au processus lorqu'il tente la connexion permet de repérer immédiatement les dépendances manquantes :
      https://blogs.pcsoft.fr/post.awp?title=analyse-performances-audits-utilitaire-pour-toutes-les-applications,2,297

  • On peut avoir besoin de connaître toutes les DLL nécessaires à une connexion. Voici un code autonome qui peut être copié/collé dans un projet de test avant de faire une connexion à la base. Le débogeur permet de voir les DLL qui sont effectivement chargées par le client de la base de données, lui même chargé par le connecteur natif.

    L'exemple et l'illustration montrent une connexion à une base Oracle avec son "instant client " version 21 dont le chemin a été ajouté dans la variable d'environnement PATH. Le principe est le même pour toutes les bases de données. On voit que le chargement de connecteur natif a provoqué le chargement de la DLL principale OCI.DLL du client Oracle, qui a provoqué à son tour le chargement de nombreuses DLL ...

cnxOracle est une Connexion
cnxOracle..Provider = hAccèsNatifOracle
cnxOracle..Serveur = "//oracle-mon-serveur"

cnxOracle..BaseDeDonnées = ""
cnxOracle..Utilisateur = "mon-user"
cnxOracle..MotDePasse = "mon-mot-passe"


tabDLLChargées est un tableau de chaîne
tabDLLNouvelles est un tableau de chaîne

POUR TOUT CHAÎNE sDLL de ExeListeDLL(ExeDonnePID(exePID)SEPAREE PARAR RC
tabDLLChargées.Ajoute(sDLL)
FIN


SI HOuvreConnexion(cnxOracle) ALORS

POUR TOUT CHAÎNE sDLL de ExeListeDLL(ExeDonnePID(exePID)SEPAREE PARAR RC
SI tabDLLChargées.Cherche(tcLinéaire, sDLL) > 0 ALORS

SINON
tabDLLNouvelles.Ajoute(sdll)
FIN
FIN

STOP // >> visualiser tabDLLNouvelles dans les expressions du débogueur

HFermeConnexion(cnxOracle)
ToastAffiche("OK")
SINON
Erreur("KO", ErreurInfo(errComplet))
FIN

< Retour

1 commentaire

Diego
19/04/2023 - 05:41 - Répondre
Excelente, muchas gracias

Publier un commentaire : 
Votre adresse email ne sera pas publiée