Discussion :

[dinbougre]

Bonjour, je voudrai savoir si le datareader sous .net était l'équivaleur du recordset sous Vb6 ? si non, quel est son équivalent ?

Jusqu'à maintenant j'utilise un datareader pour y lire les données retournées par une requête SQL... Le hic c'est que je ne peux ouvrir 2 datareader en même temps (ex: parcourir un premier datareader, puis ouvrir un second pour faire des traitements à côté qui nécessite des infos du 1er datareader). Pour l'instant je contourne le problème en placant les résultats du 1er datareader dans un tableau avant d'ouvrir le second....

[prophetky]

tu peux utiliser le DataSet qui l'équivalent du recordSet VB6 mais en nettement améliorer.

Il s'utilise à l'aide d'un DataAdpater ( et une (SQL)Command).
Pour remplir ton DataSet tu utilise la méthode Fill de ton DataAdpater qui reçois en paramètre ton DataSet.

[dinbougre]

ok donc c'est plus juste que d'utiliser un datareader comme équivalent du recordset ?

[Keihilin]

Non non...Le DataReader est plus proche de l'ancien Recordset que ne l'est le DataSet.

Le problème que tu rencontres est au niveau de la connection. Bien que ta technique soit tout à fait valable, tu peux aussi ouvrir une seconde connexion et donc avoir une nouveau datareader.

Mais pour te conseiller la solution optimale, il faudrait savoir quel genre de traitement tu effectues.

[prophetky]

Non non chaque composant à son utilité

Le dataReader est rapide, mais bloque la connexion il est très utilise pour remplir des liste ( listbox, comboBox, Treeview, ... ). on dit que tu travailles en mode connecté

Le DataSet te permet de travailler sur tes données en mode deconnecté. tres utile pour l'affichage dans une grid par exemple.

[dinbougre]

donc pour vous résumer le contexte que voici :
- j'ai une requête qui retourne plusieurs enregistrement
- je récupère l'id et un autre id de clé étrangère de chacun de ces enregistrements
- je boucle sur chacun de ces enregistrements et à chaque fois j'ai une 2è requête qui s'éxecute sur l'id de la clé étrangère et juste après ça je supprime l'enregistrement lu

ça ne peut pas être fait d'une requête, je dois parcourir chacun des enregistrements

que me conseillez vous ?

ça se fait d'ouvrir une 2e connexion sur la meme base de données uniquement pour ouvrir un second datareader ?

[Keihilin]

Non non chaque composant à son utilité

Je n'ai pas dis le contraire

Le dataReader est rapide, mais bloque la connexion il est très utilise pour remplir des liste ( listbox, comboBox, Treeview, ... ). on dit que tu travailles en mode connecté

Le DataSet te permet de travailler sur tes données en mode deconnecté. tres utile pour l'affichage dans une grid par exemple.

Je ne vois aucune différence entre remplir une "listbox" ou une "grid", désolé.

On ne va pas refaire le débat Datareader/DataSet, je crois qu'on a fait largement le tour...Juste pour info, un DataSet utilise un DataReader pour obtenir ses données, donc je persiste : choisir entre l'un ou l'autre dépend majoritairement du traitement que l'on souhaite faire sur les données.

J'irais même plus loin : étant donnée la lourdeur du DataSet, il y a bien des cas ou la méthode de dinbougre (placer temporairement les données dans un tableau et ouvrir un autre reader) est la meilleure en terme de performances.

[neguib]

Bonjour dinbougre

Je rejoins absolument toutes les remarques et suggestions de Keihilin.
Cependant, il me semble que tu as besoin de preciser un autre aspect qui est:
As-tu la possiblité de faire des modifications au sein même de la base de données. Je soupçonne en effet, qu'une partie de ce que tu veux faire pourrait être traité côté SGBDR (vues, procedure stockées). De plus quel est le SGBD concerné dans ton cas :

[Keihilin]

- je récupère l'id et un autre id de clé étrangère de chacun de ces enregistrements
- je boucle sur chacun de ces enregistrements et à chaque fois j'ai une 2è requête qui s'éxecute sur l'id de la clé étrangère et juste après ça je supprime l'enregistrement lu

ça ne peut pas être fait d'une requête, je dois parcourir chacun des enregistrements

A vu de nez (mais sans garantie), ça doit pouvoir se faire un 2 requêtes, pas plus. Il y a juste la suppression qui doit être fait dansun second temps.

Est-ce que tu peux nous donner la structure de tes tables ?

[dinbougre]

donc c'est une base de données sous access.

maTable1 (t1) : t1_id, t1_nbr
maTable2 (t2) : t2_id, t1_id
maTable3 (t3) : t3_id, t3_nbr

Je veux supprimer un élément de t1, ce qui implique de supprimer tous les éléments dans t2 liés à un t1. De plus il faut que je mette à jour dans t3 le champ t3_nbr en lui retirant t1_nbr car supprimé (t3_nbr = t3_nbr - t1_nbr)

J'ai t1_id à supprimer.
J'ouvre un recordset sur t2 où t1_id = l'id à supprimer
Je parcours tout ça via une boucle tant qu'il y a des enregistrements.
Ensuite à chaque tour de boucle j'ouvre un autre dataread qui va chercher lire dans t3 la valeur de t3_nbr pour faire des vérifs et ensuite lui retrancher t1_nbr et c'est au moment où je dois le lire que j'ouvre le second datareader qui gêne.

J'ai conscience que je peux passer par des requêtes dans access mais j'avais envie de tout centrer dans mon appli, c'est mal ?

[Keihilin]

Ok, je pense avoir à peu prêt compris.

Une dernière question et je te fais une proposition de code : est-ce que tu dois absolument lire t3_nbr ? Qu'est-ce que tu fais de cette valeur pendant ton traitement ?

[dinbougre]

En fait j'ai légèrement simplifié le truc.
Normalement il y a une autre table intercalé qui fonctionne pareil avec des suppressions en cascade.
C'est pas le t3_nbr que je lis normalement, je voulais juste ne pas détailler les 4 tables

Je sais que je peux utiliser la suppression en cascade d'access mais ce truc me fait peur en cas de mauvaise manip, il risque de tout supprimer.

Je viens de ressortir des classeurs que je m'étais fait des différents tutoriaux sur ado.net dont celui de developpez.com. A l'époque j'avais vaguement assimilé la théorie des dataset, datareader, dataadatapter, datatable... mais maintenant que je commence à plus utiliser dotnet je vais peut être mieux comprendre.

C'est ok pour ma description ou je n'ai pas été clair encore ?

[Keihilin]

Ne t'inquiète pas, on va se passer de la suppression en cascade.
Mais s'il y a encore une autre table incluse dans le traitement, merci de complèter ta description.

[dinbougre]

Ok je re détaille mieux.

maTable1 (t1) : t1_id, t1_nbr
maTable2 (t2) : t2_id, t1_id
maTable2 (t3) : t3_id, t2_id
maTable3 (t4) : t4_id, t4_nbr

Je veux supprimer un élément de t1, ce qui implique de :
=> supprimer tous les éléments dans t2 liés au t1 supprimé
=> supprimer tous les éléments dans t3 liés au t2 supprimé

Donc je supprime un enregistrement 'dans t1 qui entraine la suppression en cascade des t3 rattachés aux t2 rattachés au t1 supprimé.
Au final je met à jour t4_nbr auquel je retranche t1_nbr supprimé (t4_nbr = t4_nbr - t1_nbr)

Pour faire cela, j'ouvre un recordset Rs1 sur t2 des enregistrements à supprimer dans t2. J'ouvre un recordset Rs2 sur les t3 des enregistrements à supprimer dans t3 liés aux t2 supprimés. Là ça coince.

Et pour finir je dois mettre à jour t4_nbr mais là il n'y a pas de problème

[Keihilin]

Bon, je ferais ça comme ça :

Récupération de t1_nbr avec un datareader.

Ouverture d'une transaction

Un ExecuteNonQuery avec la commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
 
delete t3
where t2_id in (select t2_id from t2 where t1_id=@t1_id)

je suppose que tu sais utiliser les paramètres (est-ce que c'est bien @ pour Access ??)

Un ExecuteNonQuery avec la commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
 
delete t2
where t1_id = @t1_id

L'update, toujours avec un ExecuteNonQuery()

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
 
update t4
set t4_nbr = t4_nbr - @t1_nbr

t'as plus qu'à faire le delete de t1 et à valider la transaction.

pas besoin de dataset...

[dinbougre]

ok merci

mais si jamais un cas se produit où il est vraiment indispensable d'avoir 2 requêtes SELECT ouvertes en même temps... faudra que j'utilise un dataset alors ?

[Keihilin]

Oui, ou alors un DataTable (plus léger). Cela dit, ta méthode de tableau temporaire est parfaitement valable, surtout si c'est juste pour conserver des id.

[dinbougre]

ok merci

je trouvais, a tord apparement, que c'était lourd comme code avec le tableau

merci à tous, je le flag en [résolu]