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 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, 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 également pour le déploiement d'un site web. Le serveur d'application de WEBDEV qui héberge le site, devra avoir un client de la base de données installé dans le même mode de compilation que lui. Au passage le mode de compilation d'un serveur d'application déployé est visible par l'URL permettant de consulter sa version à distance.


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...

< Retour

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


© 2020 PC SOFT. Tous droits réservés. Réalisé  avec WEBDEV