Discussion :

[irongomme]

Ya un truc que je ne comprends pas très bien :

Je viens de voir que le moyen de faire un pont entre un DataSet et la base de donnée, c'est le DataAdapter. Seulement le DataSet comprends plusieurs DataTable, qui ont chacune leur requete pour se remplir, pour effacer un enregistrement, le modifier, ou en ajouter. Mais le DataAdapter ne peut stocker qu'une seule requète pour chaque action de chaque table ... faut t'il autant de DataAdapter qu'on a de tables ?? mais ca me semble pas logique ! Ou alors, faut t'il pour chaque action, transmettre au DataAdapter la commande qu'il doit effectuer ??? J'aimerais savoir ce que je n'ai pas du comprendre dans le fonctionnement , si quelqu'un peut m'aider

[mlebreton]

Oui, il y a une étroite relation entre l'objet DataAdapter et l'objet Table. Les commandes du DataAdapter reflètent la structure de la Table sur laquelle il s'applique.

Oui, il faut à priori UN DataAdapter pour chaque Table du DataSet. Généralement, les commandes Insert, Update, Delete sont définies une fois pour toutes. En revanche, il est tout a fait possible de faire évoluer la commande Select en fonction de nos besoins au cours des différentes phases de l'execution de notre programme. Ainsi, on peut dire qu'avec un seul et même DataAdapter nous pouvons effectuer toutes les opérations dont nous aurons besoin pour une seule et même table (il y a évidemment toujours des cas particuliers).

Là où la confusion s'installe c'est qu'il existe des DataSet fortement typés. Je pense que c'est à cela que vous faites allusion quand vous dites "le DataSet comprends plusieurs DataTable, qui ont chacune leur requete pour se remplir, pour effacer un enregistrement, le modifier, ou en ajouter". C'est vrai que c'est pratique, quelque clics de souris pour ajouter un nouveau fichier DataSet, du drag and drop pour y glisser des tables...

Mais, en fait, on pourrait presque dire que ce genre de DataSet ne fait pas vraiment parti de .Net. Si on y regarde de plus près, ces DataSet sont produits par un ensemble d'assistants de Visual Studio qui génèrent du code à notre place (en ASP.NET la structure XML est convertie à la compilation). Ainsi, les requêtes que nous voyons dans le designer sont ensuite intégrées dans des DataAdpater. Regardez le code généré vous en ferez le constat. Dans la réalité, le DataSet ou les Tables ne contienent aucune requête SQL. Ce sont bel et bien les DataAdpater qui s'occupent de ce travail.

Notez que les DataSet fortement typés appliquent une stratégique bien spécifique à laquelle ont peut trouver des avantages mais aussi des inconvéniants.

Il est tout à fait possible avec .Net d'imaginer une autre stratégie. C'est personnellement ce que je fais. J'ai développé mes propres assistants et j'applique ma propre logique (en locurence une logique métier avec séparation DAL / BOL).

C'est dire combien tout cela est vaste et puissant.

[irongomme]

Merci pour la réponse, cependant je ne passe pas par l'assistant de visual studio etant donné que j'exploite une base MySql avec le driver officiel de mysql pour .net, et j'utilise un DataSet principal qui contient la collection de DataTable. Seulement j'ai vu que le DataAdapter peut reproduire le shéma de la base de donnée, et donc générer toutes les DataTable nécessaires, et c'est de là que viennent mes doutes, car :

On peut faire : monDataAdapter.fill(monDataSet)
ou bien : monDataAdapter.fill(monDataSet, "maTable")

Dans le deuxieme cas, ok, cela ne concerne qu'une seule table, mais dans le premier, cela peut t'il concerner n tables ??

[Pilloutou]

Bonjour,

Dans le deuxieme cas, ok, cela ne concerne qu'une seule table, mais dans le premier, cela peut t'il concerner n tables ??

Et non cela ne peut concerner qu'une seule table.
Si tu utilises la méthode tonDataAdapter.Fill(tonDataSet) sans avoir défini le mapping de tables et de colonnes, une nouvelle DataTable va être crée. Cette DataTable portera le nom "Table".
Si tu définis le mapping de table et de colonnes, aucune DataTable ne sera crée dans le DataSet. La DataTable utilisée sera celle que tu auras défini dans le mapping de table. Les colonnes qui sont présentes dans ta SELECTCOMMAND et qui n'ont pas été mappés seront ajoutés à la table mappée.

A bientôt
Bye

[mlebreton]

Tout à fait d'accord.

[irongomme]

Ok , d'accord, mais alors comment mapper les tables ??? existe t'il une solution qui pourrait faire ca automatiquement a partir du shéma de la base de donnée, en reprenant toutes les relations de cle etrangères existantes dans la base ??

Ou sinon, je vois donc qu'il vaut mieux créer un nouveau DataAdapter pour chaque création de DataTable que l'on ajoute au DataSet, non ? Mais cela oblige pour les relations à devoir toutes les ecrires en dur alors qu'elles existent déjà dans la base de donnée !!

Ou mieux , existe t'il une classe déjà écrite qui permettent d'exploiter au mieux sa base de donnée sans devoir se taper la réecriture de toutes les contraintes fonctionelles, et tout et tout ??

Merci en tout cas à tous pour vos lumières !!