Delphi 7 Studio - Librairie Eyrolles

Olivier Dahan
Paul Toth
Delphi 7
Studio
Titre_Delphi7 24/10/02 13:07 Page 1
© Groupe Eyrolles, 2003
ISBN : 2-212-11143-6

9
Les différents modes d’accès
aux données
Depuis Turbo Pascal et son « Toolbox fichier », l’accès aux données a toujours été intégré
dans les environnements Pascal de Borland. Aujourd’hui, Delphi offre de nombreuses tech-
niques fort différentes. Si on ajoute à ces moyens les types Pascal de gestion de fichiers, si on
puise dans Windows lui-même ou l’ensemble des composants développés pour Delphi par
de nombreuses sociétés dans le monde, les possibilités de choix deviennent pléthoriques.
Procéder à une sélection objective et appropriée pour chaque développement réclame de
bien connaître chacune des possibilités offertes par Delphi. Le présent chapitre expose
l’ensemble de ces dernières pour que vous puissiez adopter la meilleure solution en toute
connaissance de cause. Les chapitres qui suivent détailleront certains modes d’accès en
raison de leur introduction récente dans Delphi et de l’intérêt technique qu’ils présentent
(comme dbExpress apparu dans Kylix 1 et Delphi 6, expliqué au chapitre suivant).
Les données, matière première de l’application
En dehors de quelques cas extrêmes, les applications travaillent sur des données persis-
tantes, quel que soit le mode de stockage choisi. Avant de se déterminer pour un moyen
d’accès aux données, il faut au préalable bien définir les données à traiter.
Dans cet esprit, le titre d’un célèbre ouvrage de Niklaus Wirth, créateur du Pascal, est fort éclairant : Algo-
rithmes + structures de données = programmes (1976). Il pose bien l’essentiel du problème de l’écriture
d’une application : trouver l’adéquation entre structures de données (et les moyens d’accès) et les algo-
rithmes qui les traitent. On pourra trouver le titre de cet ouvrage un peu réducteur car il évacue la néces-
saire qualité de l’analyse fonctionnelle et la prise en compte des impératifs d’exploitation, mais Wirth
traitait de l’aspect technique de l’écriture d’un programme et non de méthodologie.
© Groupe Eyrolles, 2003

La gestion des bases de données
TROISIÈME PARTIE
182
Une application typique gère habituellement les types de données suivants :
• des données de configuration du logiciel ;
• des données de mémorisation de l’état de l’interface utilisateur ;
•des données temporaires « de travail » ;
•des données techniques, consignation de diagnostics, journaux d’application, messages
d’erreurs sauvegardés ;
• des données propres au métier de l’utilisateur final.
Les données de configuration et de mémorisation de l’état de l’interface sont le plus
souvent stockées dans des fichiers
INI ou dans la base de registre de Windows. On peut
parfois stocker une partie de ces informations dans une base de données afin d’échapper
au partage de la base de registre en réseau et de permettre aux utilisateurs de retrouver
leur configuration quel que soit le poste de travail qu’ils utilisent. Reportez-vous au
chapitre 8, « Persistance de l’interface et autres paramètres », qui détaille la gestion des
fichiers paramètres.
Les données temporaires utilisent tous les formats possibles et sont spécifiques aux trai-
tements qui les impliquent. Il peut s’agir de texte, d’images, de collections d’objets ou de
n’importe quoi d’autre. Elles sont stockées soit dans la mémoire, soit sur disque, et leur
format dépend du contexte.
Les données techniques sont un peu comme les données de configuration : on peut les
stocker tout ou partie en local sur le disque de l’utilisateur ou préférer un stockage en
base de données pour les mêmes raisons. La gestion de ces paramètres applicatifs est
aussi abordée au chapitre 8.
Enfin, les données propres au métier de l’utilisateur occupent un rôle central et sont le plus
souvent stockées dans des bases de données, ne serait-ce que pour en assurer le partage
sur un réseau. On rencontre aussi des fichiers dits externes liés à l’application. Il s’agit
généralement de documents de toutes sortes : images, traitement de texte, etc.
Delphi propose des solutions pour chaque cas :
• les fichiers texte pur, gérés par le type Pascal
TextFile ;
• les fichiers d’enregistrements, gérés par le type Pascal
File Of Record ;
• les fichiers
INI gérés via des TStrings ou la classe TIniFile ;
• la base de registre de Windows, gérée par la classe
TRegistry ;
• les fichiers binaires, gérés par le type Pascal
File ;
• les fichiers binaires, gérés par des flux (classe
TFileStream ) ;
© Groupe Eyrolles, 2003

Les différents modes d’accès aux données
CHAPITRE 9 183
• les fichiers texte enrichi ( RTF ), gérés par la classe TRichEdit ;
• les bases de données, gérées selon leur nature.
Il est important de comprendre que tout ne se gère pas avec une base de données et savoir
utiliser tous ces moyens est un atout majeur pour une programmation efficace. Nous ne
traiterons pas ici de l’ensemble de ces moyens, certains chapitres du présent ouvrage se
chargeant d’en présenter les détails les plus utiles.
Nous nous concentrerons en revanche sur les bases de données car, malgré tout, la néces-
sité de partager des données au travers d’un réseau local ou non, voire d’un intranet ou
d’Internet, impose de plus en plus de stocker le maximum d’informations dans de telles
bases. Le choix du moyen d’accès devient alors capital pour de nombreuses raisons dont
principalement la simplicité de développement, la facilité de déploiement et, bien
entendu, la rapidité des échanges avec la base.
À proprement parler, une « base de données » n’est rien d’autre qu’une collection struc-
turée de données. On peut créer une telle base à l’aide de fichiers binaires, ou de fichiers
textes pourquoi pas, cela n’enlève rien à la nature même de la base. Toutefois, ce terme
est employé couramment pour désigner un type bien particulier de base de données : les
bases de données dites relationnelles.
Panorama des stratégies d’accès aux bases de données
Sous l’appellation « base de données relationnelle », on trouve de nombreuses solutions
techniquement fort différentes, de l’antédiluvienne dBase et ses dérivés tels que FoxPro
ou Nantucket aux bases les plus puissantes comme Oracle, MS SQL Server ou Interbase
en passant par des solutions intermédiaires comme PostgreSQL, Paradox ou MS Access.
Il ne nous appartient pas ici de faire un classement entre ces produits. Ils existent et il faut
pouvoir y accéder.
Nous n’aborderons pas non plus les notions théoriques liées à l’élaboration et l’exploita-
tion des SGBD-R (système de gestion de bases de données relationnelles) pour nous
occuper essentiellement des choix que Delphi propose pour accéder à ces systèmes, à
savoir :
• le Borland Database Engine (BDE)
•ODBC (via le BDE ou dbExpress)
• ADO
• dbExpress/DataSnap Direct
• Interbase Express
• DataSnap
• MyBase
© Groupe Eyrolles, 2003

La gestion des bases de données
TROISIÈME PARTIE
184
Le BDE face aux autres solutions, épilogue d’une fin annoncée
Le Borland Database Engine (BDE) est hérité d’un lointain passé. S’il est aujourd’hui
deprecated pour sa partie SQL Links, il reste très utilisé, et nombreux sont les déve-
loppeurs Delphi qui ne connaissent que lui. Nous l’aborderons en premier car sa popula-
rité est telle que les nouveaux moyens d’accès aux données ont calqué leur fonctionne-
ment apparent sur la logique offerte par le BDE. Comprendre les grandes lignes du BDE,
si vous ne le connaissez pas, vous permettra de mieux aborder les autres moyens mis à
disposition par Delphi.
Historique du BDE
L’histoire du BDE commence après le rachat par Borland en 1987 de Paradox, créé par
ANSA Software en 1985. À partir de ce moment, les évolutions de ce produit furent
nombreuses. Module « résidant » en mémoire sous DOS, le moteur de Paradox est
devenu le BDE sous Windows au moment du rachat de dBase à ASTON TATE par
Borland en juillet 1991. À la différence de Microsoft qui a préféré gérer ses différents
produits de façon totalement séparée (FoxPro et MS Access), Borland a alors choisi de
fusionner les deux moteurs en sa possession, le moteur de Paradox (ODAPI) et dBase, ce
qui a donné le premier embryon du BDE (IDAPI).
Pour répondre aux besoins d’accès aux bases de données externes, tout en profitant de
l’interface du logiciel Paradox, Borland créa deux ouvertures au moteur : l’accès natif à
certains SGBD-R par le biais des « SQL Links » et l’accès à toutes les bases déjà utilisa-
bles par le système ODBC. Il fut d’ailleurs déjà question à cette époque de concevoir un
système séparé du BDE pour gérer les bases SQL. Ce projet non divulgué au grand
public et qui était connu sous divers noms dont « SQL Express » fut abandonné au profit
des SQL Links lors de l’intégration du BDE dans Delphi 1. On voit aujourd’hui, avec
l’avènement de dbExpress, que cette idée a continué son chemin chez Borland pour devenir
la nouvelle stratégie dans Delphi 6 et les versions suivantes.
À ce stade, le BDE était devenu ce qu’il est encore aujourd’hui : une interface standardi-
sée de programmation ouvrant la voie vers la quasi-totalité des SGBD du marché. Et
c’est tout naturellement sous cette forme que le BDE fut intégré à la première version de
Delphi qui fonctionnait sous Windows 3.x en 16 bits et qu’on a ensuite retrouvé en
32 bits dans les versions suivantes de ce produit et de C++ Builder.
Souvent critiqué notamment pour son poids (gênant pour un déploiement de logiciel
shareware via Internet principalement, et en entreprise sur un réseau d’une centaine de
machines), le BDE est un merveilleux outil ayant rendu des services inestimables durant
des années. La partie native étant libre de diffusion (formats Paradox et dBase), le BDE
est encore utilisé par de nombreux logiciels sur le marché.
Mais tout a une fin… Avec la sortie de Kylix, Borland n’avait pas d’autres choix que de
réécrire le BDE pour le porter sous Linux ou d’inventer un nouveau système d’accès aux
données utilisable sous Linux et Windows. C’est cette dernière solution qui a été préférée
et qui a donné naissance à dbExpress que nous verrons dans la suite de ce chapitre.
© Groupe Eyrolles, 2003