03 octobre 2012
publié par 
Une base de données client/serveur comme Oracle, SQL Server, MySQL 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 :


< Retour

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