Comprendre les Recordset ADO

Dans la programmation standard des bases de données en Visual Basic, il y a toujours une source de données (dans le cas de cet article, une base Access exemple : biblio.mdb).

Pour utiliser cette source de données, il faut utiliser un programme qui sait manipuler ces données, on l'appelle le fournisseur (dans certains cas serveur). Un fournisseur qui expose une interface OLE DB est appelé Fournisseur OLE DB.

Dans le cas qui nous intéresse, votre code, qui demande des données est le consommateur (ou client).

Attention, dans certains articles portant notamment sur les contrôles dépendants vous pourrez trouver ces termes avec une autre signification. En effet, si vous liez des zones de texte à un contrôle ADODC, le contrôle ADODC sera (improprement) appelé Fournisseur de données et vos zones de textes seront consommatrices.

Pourquoi est-ce impropre ?

Comme on ne voit pas le code que le contrôle ADODC utilise pour demander des informations, on tend à faire l'amalgame entre les deux. Mais c'est une erreur, car le contrôle est le consommateur de données. Nous verrons l'importance de cela avec les curseurs et le paramétrage des contrôles de données.

Un fournisseur de service permet d'ajouter des fonctionnalités au fournisseur de données. Il y en a plusieurs dans ADO tel que « Microsoft Data Shaping Service » qui permet la construction de recordset hiérarchique ou « Microsoft OLE DB Persistence Provider » qui permet de stocker les recordset sous forme de fichier. L'appel de ces fournisseurs n'est pas toujours explicite (cf. Recordset persistant)

Un composant de service n'a pas d'existence propre. Il est toujours invoqué par un fournisseur (ou plus rarement par d'autres composants) et fournit des fonctionnalités que le fournisseur n'a pas. Dans cet article nous allons beaucoup parler du « Service de curseur pour Microsoft OLE DB » plus couramment appelé moteur de curseur.

Lorsque le fournisseur extrait des données de la source (requête SELECT), il s'agit de données brutes (sans information annexe) n'ayant pas un ordre particulier. Celles-ci ne sont pas très fonctionnelles, et il faut d'autres informations pour pouvoir agir sur la source de données. En fait, un recordset est un objet contenant des données de la base agencées de façon lisible, et des métadonnées. Ces métadonnées regroupent les informations connexes des données telles que le nom d'un champ ou son type et des informations sur la base telles que le nom du schéma.

Cette organisation est produite par un composant logiciel qui est le point central de la programmation ADO, le moteur de curseur. Le résultat ainsi obtenu est appelé curseur de données. Il y a dans ce terme un abus de langage qui explique bien des erreurs de compréhension. Le terme curseur vient de l'anglais « cursor » pour « CURrent Set Of Rows ». On tend à confondre sous le même terme le moteur de curseur qui est le composant logiciel qui gère l'objet Recordset, l'objet Recordset (données, métadonnées et interface) et enfin le curseur de données qui n'est rien d'autre que l'enregistrement en cours. Cet amalgame vient de l'objet Recordset qui contient à la fois des informations destinées au moteur de curseur, des données et des méthodes qui lui sont propres. Dans la suite de cet article comme dans la majorité de la littérature disponible, vous trouverez sous la dénomination « curseur » le paramétrage de l'objet recordset vis-à-vis du moteur de curseurs.