Un exemple avec ADO

adOpenStatic. Le
curseur peut être du côté serveur (par
défaut) ou du côté client.

Pour atteindre un enregistrement,
ADO doit explorer un Recordset séquentiellement.
Et, pour atteindre des
tables multiples, il faut effectuer une
requête JOIN pour renvoyer les résultats
sous la forme d’un Recordset. Bien
que l’objet Recordset supporte l’accès
aux données déconnecté, ADO est encore
conçu principalement pour l’accès
aux données connecté. Ce mode
d’accès connecté immobilise des ressources
précieuses côté serveur. En
outre, pour transmettre un Recordset,
il faut utiliser COM marshalling. COM
marshalling est l’opération qui consiste
à  convertir des types de données, au
prix de ressources système supplémentaires.

A partir de la version ADO 2.1,
Microsoft a ajouté le support XML au
modèle d’objet ADO, afin que l’on
puisse sauvegarder un Recordset
comme un document XML. Mais ce
n’est qu’à  partir d’ADO 2.5 que certaines
restrictions et des limitations du
support XML dans ADO 2.1 (la persistance
d’objets Recordset hiérarchiques,
par exemple) ont été levées. Bien qu’ADO puisse lire un document
XML dans un Recordset, il ne peut lire
qu’un schéma propriétaire appelé
ADTG (Advanced Data TableGram).

Souhaitant avoir un mécanisme
d’accès aux données déconnecté,
Microsoft a étendu ADO et a introduit
RDS (Remote Data Services). RDS
s’inspire d’ADO et permet de transférer
un Recordset à  un client (un navigateur
Web, par exemple) sans avoir
besoin d’une connexion active.
Toutefois, à  l’instar d’ADO, RDS utilise
COM marshalling pour transférer les
Recordsets du serveur au client.