Une base de données client/serveur comme Oracle, SQL Server, MySQL , MariaDB, PostgreSQL (...) peut être utilisée depuis :
  • un exécutable 32 ou 64 bits WINDEV,
  • un webservice WINDEV placé sur un serveur,
  • un service WINDEV fonctionnant en tâche de fond sans session,
  • un site WEBDEV ...

 

Dans tous les cas, et c'est la "clé de voûte" du principe client/serveur, l'accès réel aux données se fait par le programme client de la base de données installé en local, fourni par l'éditeur de la base. Il n'y a jamais d'accès direct aux données, c'est ce principe qui assure la sécurité de la base. En effet de cette manière la base peut être totalement inaccessible, sauf pour son client "légitime".

Lorsqu'une application, ou un site, ouvre une connexion puis exécute un "SELECT", il n'y a donc pas de lecture directe dans la base de données. L'application, ou le site, demande au client local de la base de lire l'information. C'est le client qui se charge de lancer la lecture réelle des données sur le serveur, puis du rapatriement des données avant de faire suivre le résultat à l'application à l'origine de la demande.

Le client de la base de données a donc une importance majeure. Dès qu'une application est dépendante de données d'une base, il faut s'assurer de l'utilisation du bon client d'accès.

En guise d'illustration, voici deux exemples pour lesquels le support reçoit régulièrement des demandes de la forme :
  • "mon interrogation donne le bon résultat avec l'exécutable de l'application, ou le mode test, mais pas après déploiement en Webservice",
  • "l'application WINDEV récupère les données, mais pas le site WEBDEV déployé avec pourtant la même base de données",
  • et plus généralement : "ça marche sur un poste, mais pas l'autre"...

  1. Avec SQL Server dans sa version 2008, un nouveau type "date" est proposé, en plus du type "datatime" historique. La lecture des données d'une colonne date de la base ne pose aucune difficulté, lorsque le client de la base de données est bien celui de SQL Server 2008. Par contre, la même application, connectée au même serveur, mais exécutée sur un poste avec un client SQL Server plus ancien, va récupérer la date tronquée et/ou avec formatage erroné...
  2. Avec MySQL, lorsque la base et l'application utilisent unicode, il est tout à fait possible d'obtenir des résultats inattendus, illisibles, décodage erroné, lors des lectures de la base, simplement en ayant une version du client MySQL (libmysql.dll) dans une version trop ancienne.

En conclusion, dès qu'une application se connecte à une base de données, il faut tenir compte du client de la base à tous les stades :
  • si la version de la base de données à utiliser est imposée par un existant, utiliser sur le poste de développement la même version du client d'accès à la base, que celle qui sera utilisée en production.
  • à l'inverse, en ayant la maîtrise de la version, s'assurer que le client de la base qui sera installé en production, sera bien celui validé avec l'application lors des tests.
  • pour la documentation, les pré-requis, spécifier les clients testés et compatibles,
  • pour le déploiement, s'assurer de la conformité du client de la base installé...

Cela s'applique aux connexions faites via un pilote ODBC, un provider OLE DB, ou solution recommandée, un accès natif optionnel. Si besoin voici le lien direct sur la page détaillant les possibilités de connexion :

Mise à jour 28/5/2019

 

La version du client de la base de données utilisé pour les accès reste déterminante.

Depuis l'édition de ce billet, des possibilités ont été ajoutées via les informations optionnelles de connexion :

  • le mot-clé WD CLIENT LIBRARY permet d'indiquer la DLL cliente qui accomagne une base Progress,
  • le mot WD CLIENT VERSION (en complèment de h.ModeSQLServer) permet de forcer la version d'un client SQL Server (msoledbsql) qui doit être préféré au pilote/driver fournit en standard par windows (sqloledb).

 

- Mise à jour 8/7/2020 -

La fonction EXEListeDLL peut permettre de vérifier la version exacte d'un client base de données utilisé par une application, lorsque l'application s'exécute et que la connexion est effective.

Une illustration est donnée dans le billet "Énumérer / vérifier les dépendances d'une application : DLL, composants".

 

Mise à jour 17/3/2022 -

La version du client d'une base de données notamment son mode de compilation est également déterminante pour l'éditeur d'analyse de WINDEV :

Mise à jour 14/3/2023 -

L'utilisation par erreur du client SQL SERVER 2019 avec une base trop ancienne toujours en version 2012 provoque un échec de connexion : "La chaîne de certificats a été fournie par une autorité qui n'est pas approuvée".

< Retour