Je développe en Delphi depuis plusieurs années et je me suis remis à la base de données il y a peu.

Donc je fais un petit mémo expliquant ce que j’ai compris, en espérant que cela fera gagner du temps à ceux qui n’y arrivent pas, et en sautant les étapes de l’aide Delphi, qui, quoique très précise et détaillée, aurait tendance dans un premier temps à plus nous embrouiller qu’autre chose.

Dans une application “orientée base de données”, il faut tout d’abord afficher les données. Il y a les composants de données, qui commencent tous par TDB (TDBGrid, TDBEdit, TDBMemo etc.). On prend le composant, on le dépose sur la fiche. On a une “DBGrid1” qui s’affiche.

Ensuite, il faut aller chercher les données qu’on veut afficher. Une “source de données”. En Anglais, un composant “TDataSource”. On prend le composant, on le pose sur la fiche, on initialise la propriété “DataSource” de notre “DBGrid1” à “DataSource1”.

Ensuite, ce composant “source de données” doit aller chercher les données quelque part. Mais où ? Eh bien chez un “serveur de données”. Pour cela il nous faut un objet appelé le client. Ça peut paraitre bizarre, mais on l’appelle “client” parce que c’est lui qui ira demander des informations à un serveur de données. C’est le client de données du serveur de données. Donc un client d’ensemble de données, en Anglais : “TClientDataSet”. On prend un composant “TClientDataSet”, on le pose sur la fiche, et on initialise la propriété “DataSet” de “DataSource1” à “ClientDataSet1”.

Ce fameux Client, lui, doit donc se connecter à un serveur de données. C’est intéréssant dans la mesure ou ce fameux serveur peut être “hors” de l’application, sur un autre ordinateur, mais faisons simple : on va supposer que ce serveur est directement intégré à l’application. On utilise donc un composant fournisseur de données, en Anglais : “TDataSetProvider”. On prend un composant “TDataSetProvider”, on le pose sur la fiche, et on initialise la propriété “ProviderName” de “ClientDataSet1” à “DataSetProvider1”.

On y est presque !

Il reste le côté purement physique, c’est à dire l’objet réel qui ira lire les informations. Nous allons prendre un objet TTable. (Il y a les objet TIBTable pour Interbase, TMyTable pour MySQL, TSQLTable pour dbExpress, bref, plein de tables dont on se sert de la même manière que TTable). On prend un composant “TTable, on le pose sur la fiche, et on initialise la propriété “DataSet” de “DataSetProvider1” à “Table1”.

Voilà l’image résultat :

Voilà le trajet des informations :

Lorsque la grille de données voudra lire des informations pour les afficher, la demande suivra ce trajet :

DBGrid1 => DataSource1 => ClientDataSet1 => DataSetProvider1 => Table1

et la Table ira lire les bonnes informations, et créera une réponse. La réponse fera le trajet inverse :

Table1 => DataSetProvider1 => ClientDataSet1 => DataSource1 => DBGrid1

L’intérêt d’avoir autant de composants c’est qu’on peut faire deux applications : le client qui affiche les données, et le serveur, qu’on peut mettre sur un autre ordinateur.

Il est possible de “couper” directement la route et de ne faire qu’un lien direct entre DataSource1 et Table1. (Le propriété DataSource1.DataSet = “Table1”). Mais ce ne sera pas du tout évolutif. A éviter donc.