DataGrid et DataReader

Version imprimable

19/12/2007, 09h52
alexking2005

DataGrid et DataReader

Bonjour,

je consulte des données d'un serveur sql 2005 en utilisant les objets SQLCommand et SqlDataReader, mais lorsque je veux afficher mes données dans un datagrid, la ligne:

Code:

monDataGrid.Source = monDataReader;

ne fonctionne pas. Je pense comprendre pourquoi ça ne fonctionne pas, car un datareader ne contient qu'une ligne de données, c'est à moi de lui demander la seconde ligne et ainsi de suite.

Je peux alors passer par un datatable mais du coup je perd l'intérêt du mode connecté!

Comment faire pour afficher mes données dans un datagrid de la manière la plus rapide?

Merci bien!

Alex
19/12/2007, 09h54
Kaidan

C'est quoi l'interêt du mode connecté ?

Il est clair qu'il vaut mieux utiliser une DataTable pour binder les données dans un DataGrid.
19/12/2007, 10h58
alexking2005

L'interet, il me semble que rien n'est en mémoire donc l'appli est plus rapide et que si 2 personnes sont sur le même enregistrement, le serveur gère les verrous.
19/12/2007, 15h15
web-inside

comme tu le dis à juste titre tu consultes :)

le plus simple et le plus adapté pour travailler avec un gridview est de binder un DataTable.

tu n'as aucun interêt à conserver une connection ouverte si c'est pour afficher le contenu d'une table.

imagine que l'utilisateur décide d'aller boire un café....

à toi de gérer en reprenant l'état de ta table à chaque appel de la page.
19/12/2007, 15h33
Bluedeep

Citation:

Envoyé par alexking2005

L'interet, il me semble que rien n'est en mémoire donc l'appli est plus rapide

8O

Y'a des révisions à faire, là ....
19/12/2007, 15h52
web-inside

tu crois? :lol:
20/12/2007, 09h52
alexking2005

Messieurs, soyez un peu indulgents avec un newbie... m'enfin!

C'est pourtant ce que j'avais cru comprendre quand j'ai lu le document PDF "CsharpTout.pdf" téléchargeable depuis ce site. On y trouve ce paragraphe:

Citation:

L'entité la plus importante d' ADO .NET permettant de gérer les données en local dans une
mémoire cache complétement déconnectée de la source de données (donc indépendante de cette
source) est le DataSet en fait la classe System.Data.DataSet et la collection de classes qui lui
sont liées.

J'en ai donc déduit que si c'était chargé en mémoire, l'appli serait plus lourde!

J'ai tord?

Mais alors quel mode préféré? Je souhaite faire un prog Windows, donc client d'une bdd sql server. Je pensais que le mode le plus approprié était le mode connecté!
20/12/2007, 10h01
theMonz31

salut alexking2005

Tu veux faire de la base de données en C#, alors tu fais du deconnecté.. ;)

Tu recuperes les données dans un dataTable... du bind cela à ta grille et basta

Et au moment de faire la sauvegarde, soit tu geres de la concurrence (c'est à dire que tu vas vérifier que la donnée présente dans la base est égale à la donnée initialement chargée.. si c'est le cas, pas de concurrence, tu peux sauver ta nouvelle donnée, sinon.. tu peux soit proposer à l'utilisateur de faire un choix (garder ou ecraser) ou écraser :)

Bien sur, pour faire cela, tu passes par une transaction qui va t'éviter d'avoir
des soucis de mises à jour concurrentielles au moment de ta mise à jour ...

Le principal soucis des bases de données est d'assuré la cohérence des données entre les différents clients qui mettent à jour en simultané le server de données...

Apres, il existe (enfin, j'en connais que 2) 2 approches pour gérer les problèmes de concurrences...

Soit tu gères cela au niveau Client.. Et donc, le client prendra la responsabilité de proposer le bon choix...

Soit tu crées un Manager au niveau de ta base de données.. Ce qui signifie que tu n'attaques pas ta base de données directement en frontal mais que tu passes par un manager qui lui, va "filtrer" tes demandes....

J'explique un peu plus :)

Tu fais une sauvegarde des données modifiés par ton client... Cette sauvegarde arrive sur le MAnager (appli local sur le server)... Celui ci va regarder les données sur la base, et appliquer la politique de concurrence que tu auras choisis de définir...

Voila :)

J'sais pas si j'ai été aussi clair que possible, mais bon...

A+ The Monz, Toulouse
20/12/2007, 10h28
Bluedeep

Citation:

Envoyé par alexking2005

J'en ai donc déduit que si c'était chargé en mémoire, l'appli serait plus lourde!

J'ai tord?

Sur le fait qu'elle soit plus lourde en mémoire, non, mais tu en as déduit supra une conclusion erronée (sauf, peut être, si tu "tournes" avec 512 Mo de mémoires, que tu charges 5 millions de lignes, et que tu fais tourner en prime dix ou douze programmes de calcul de modélisation :D )

Citation:

Mais alors quel mode préféré? Je souhaite faire un prog Windows, donc client d'une bdd sql server. Je pensais que le mode le plus approprié était le mode connecté!

Il n'existe pas de réponse toute faite dans la mesure où on ignore ce que fera ton application et son degré de couplage avec la DB.

Néanmoins, le mode connecté (supporté via les DataReader) n'est pas toujours le plus approprié.
20/12/2007, 12h03
alexking2005

Merci pour vos réponses.

Vous m'avez poussé à chercher un peu plus loin dans les dataset (c'est une bonne chose, vu mon niveau ça ne peut me faire que du bien). J'en suis arrivé à cette conclusion:

Les tables de ma bdd peuvent contenir jusqu'à 85 000 lignes, quand c'est filtré je n'en aurai besoin que de 5 000 environ. Je viens de faire un test. J'ai créé une form avec 2 boutons: Connecte et Deconnecte. Quand on clique sur le bouton Connecte, j'affiche une form qui me charge 21 582 lignes dans une listbox en 5 sec. Quand je clique sur le bouton Deconnecte, j'ai une autre form qui me charge les mêmes 21 582 lignes dans une listbox en 8 sec.

C'est quand même pas mal 3 sec de différence. Donc pour moi mon intérêt est bien de bosser en mode connecté. Et j'aimais bien l'idée que ce soit mon serveur SQL qui gère les verrous (concurrences) (Si ça se trouve je me trompe encore en imaginant que mon server sql va gérer les accès concurrents).

En tout cas, merci pour vos réponses :D, cela dit je ne sait toujours pas comment lier mon datagridview à mon datareader! :cry:
20/12/2007, 12h11
Kaidan

Un DataAdapter utilise toujours un DataReader en interne, c'est donc forcement un peu plus lent. Tu peux avoir un seul DataReader actif en même temps mais plusieurs DataTable.

Je comprends rien à ton histoire de verrou.

Il y a lock en lecture uniquement si une transaction modifie les données à lire et que cette transaction est dans un mode d'isolation empêchant les lectures fantômes etc. Le lecture en elle-même n'entraîne aucun lock. Ton utilisateur 1 lit les données, il trouve valeur = 3000. Ton utilisateur 2 lit les données et trouve aussi valeur = 3000. L'utilisateur 1 modifie valeur = 1500. Le second utilisateur va voir toujours 3000 vu que ces données sont pas updatées. Pas de lock donc, que ce soit en DataTable ou en DataReader.

Il faut donc, comme précisé dans un autre post, tester dans une transaction (sérialisable ?) que la valeur n'a pas été modifiée avant de la modifier.

Pour binder ton DataReader à ta DataGridView, tu lis ton Reader, tu mets le tout dans une DataTable et tu bind la DataTable ... tu reviens donc à tes 8 secondes :roll:
20/12/2007, 13h31
web-inside

8 secondes 8O

elle est au pérou ta base? :P
21/12/2007, 09h42
alexking2005

/mode jaipasdhumour
non non elle est juste à côté de moi
/mode
21/12/2007, 09h43
Bluedeep

Citation:

Envoyé par web-inside

8 secondes 8O

elle est au pérou ta base? :P

C'est pas la base qui bouffe 8 secondes, c'est la listbox.