Comprendre les Recordset ADO

C'est probablement la modification la plus significative d'ADO.NET. L'objet recordset d'ADO a été supprimé pour être remplacé par le DataSet. Disons-le tout de suite, le nouvel objet est autrement plus performant que le recordset qui souffre de plusieurs défauts, le principal étant d'utiliser un format propriétaire. L'objet DataSet stocke les données au format XML. Il permet la construction de schémas de données complexes avec des relations, plusieurs tables pouvant provenir de diverses tables, etc.

On peut le voir comme un recordset issu du DataShaping, encore plus évolué. À tout point de vue, l'objet DataSet dépasse ce qu'il était possible de faire avec un recordset sous l'aspect mise en forme des données.

Dans une certaine mesure, on peut voir l'objet Recordset comme un Objet DataTable de l'objet DataSet. Le code suivant permet de remplir l'objet DataTable.

Dim strConnection As String = "Data Source=localhost;Initial
Catalog=Pubs;Integrated Security=True"
Dim cnn1 As SqlConnection = New SqlConnection(strConnection)
cnn1.Open( )
Dim strSelect As String = "SELECT * FROM Authors"
Dim da As New SqlDataAdapter(strSelect, cnn1)
Dim EqvRst As New DataTable("Auteurs")
da.Fill (EqvRst)

Comme nous le voyons, pas de grandes différences avec ADO à l'exception de l'objet DataAdapter. Une autre nouveauté intéressante est l'arrivée de la méthode ExecuteScalar qui permet de ne pas créer un DataSet lorsque la requête ne renvoie qu'une valeur.

Je vous ai donc dit qu'il n'y avait pas de révolution et pourtant, impossible de retrouver les curseurs dans ADO.NET. Rassurez-vous (surtout si vous n'avez rien compris à ce présent cours) ils ont été englobés dans deux objets DataReader (côté serveur) et DataAdapter (côté client) que nous allons voir maintenant. C'est là l'autre grande nouveauté d'ADO.NET, mais elle soulève nettement moins mon enthousiasme que le DataSet.

Cet objet est stricto sensu le curseur FireHose d'ADO. C'est dans ADO.NET le seul curseur serveur (connecté) disponible. Il garde les mêmes inconvénients que son homologue ADO, c'est-à-dire qu'il est exclusif sur la connexion qu'il utilise, qu'il ne connaît pas sa position absolue et qu'il ne permet de voir les mises à jour que sur les enregistrements non encore lus. Par contre il reste extrêmement rapide.

Comme son homologue ADO, il est fait pour faire de la lecture de données en un passage, typiquement pour le remplissage de contrôle visuel.

Il s'agit d'une grosse modification de stratégie quant à l'accès aux données. Il y a principalement deux raisons invoquées :

• Les applications Web demandent une connexion minimale à la source de données
• Il est plus performant d'utiliser les procédures stockées pour manipuler les données côté serveur.

Cet argumentaire est parfaitement recevable, mais à mon avis il ne prend pas le problème dans toute son ampleur.

Tout d'abord, la disparition des curseurs modifiables côté serveur entraîne la disparition de la gestion de l'accès concurrentiel par des mécanismes du SGBD. Cela va donc reporter une lourde charge sur le développeur. Ensuite il n'est pas toujours possible de stocker des procédures dans la base de données. Enfin et surtout, le fait de devoir travailler uniquement en mode déconnecté demande des utilisateurs autrement formés à la pratique de la programmation des bases de données. Nous allons voir cela dans des considérations sur l'objet DataAdapter.

Voilà le nouvel enrobage du moteur de curseur client. Cet objet est défini comme étant l'intermédiaire entre la source de données et l'objet DataSet. Nous allons regarder en détail comment sont répercutées les modifications de l'objet DataSet vers la source.

Commençons par reprendre le schéma global de fonctionnement de l'objet. Il utilise une méthode Fill pour gérer le remplissage du DataSet. Cette méthode est paramétrable par l'intermédiaire de la méthode Select de l'objet DataTable. Dans l'autre sens, on peut soit utiliser l'objet CommandBuilder, censé être l'équivalent, du point de vue du fonctionnement, du moteur de curseur, soit utiliser les méthodes de l'objet DataTable pour construire sa propre logique d'action.

X-C-1. Construire sa logique d'action▲

Dim strConn, strSQL As String
strConn = "Provider=SQLOLEDB;Data Source=(local);Initial
Catalog=Pubs;Trusted_Connection=Yes;"
strSQL = "SELECT Au_Id, Author, [year born] FROM Authors WHERE Au_Id
= 8139"
Dim da As New OleDbDataAdapter(strSQL, strConn)
Dim tblAut As New DataTable("Auteurs")
da.Fill(tblAut)
'Je modifie une ligne comme dans l'exemple ADO
tblAut.Rows(1)("Year born") = CShort(tblAut.Rows(1)("Year born" )) +
1
'Envoi de la modification à la source.
Try
da.Update(tblAut)
Console.WriteLine("Modification effectuée")
Catch ex As Exception
Console.WriteLine("Erreur lors de la modification :" &
ex.Message)
End Try

Dim strConn, strSQL As String
Dim cnn1 As OleDbConnection
'Je crée une connexion, un DataAdapter et un DataSet
strConn = "Provider=SQLOLEDB;Data Source=(local);Initial
Catalog=Pubs;Trusted_Connection=Yes;"
strSQL = "SELECT Au_Id, Author, [year born] FROM Authors WHERE Au_Id
= 8139"
cnn1 = New OleDbConnection(strConn)
Dim da As New OleDbDataAdapter(strSQL, cnn1)
Dim tblAut As New DataTable("Auteurs")
da.Fill(tblAut)
'Je définis la commande Update que va utiliser le DataAdapter
strSQL = "UPDATE Authors SET Au_ID = ?, Author = ?, [year born] = ?
WHERE Au_ID = ? ABD Author = ? AND [year born] = ?
Dim cmdUpdate As New OleDbCommand(strSQL, cnn1)
'Définition des paramètres en liaison au DataSet
Dim pcUpdate As OleDbParameterCollection = cmdUpdate.Parameters
Dim MonParam As OleDbParameter
MonParam =pcUpdate.Add("nAu_Id", OleDbType.Integer)
MonParam.SourceColumn="Au_Id"
MonParam.SourceVersion = DataRowVersion.Original
MonParam =pcUpdate.Add("nAuthor", OleDbType.VarChar,50)
MonParam.SourceColumn="Author"
MonParam.SourceVersion = DataRowVersion.Original
MonParam =pcUpdate.Add("nYearBorn", OleDbType.SmallInt)
MonParam.SourceColumn="Year Born"
MonParam.SourceVersion = DataRowVersion.Original
'Je modifie une ligne comme dans l'exemple ADO
da.UpdateCommand = cmdUpdate
tblAut.Rows(1)("Year born") = CShort(tblAut.Rows(1)("Year born" )) +
1
'J'envoie la modification
da.Update(tblAut)

strSQL = "UPDATE Authors SET Au_ID = ?, Author = ?, [year born] = ?
WHERE Au_ID = ? ABD Author = ? AND ([year born] = ? OR ((? IS NULL)
AND ([year born] IS NULL)))

X-C-2. Utiliser le CommandBuilder▲