Grrr je pige pas les Schame XML !!

bon, allons y pour la visite guidée. essaye de faire l'effort de lire
jusqu'au bout :o)


le Dataset, comme tu as pu le remarquer, est un mini sgbd en mémoire locale
dans ton appli.
et en fait, on va dire que c'est un élément différentiel, il enregistre pour
chaque ligne les modifications que tu y apportes (modifiée, effacée, tout
ça)

maintenant, le Dataset est capable de decrire n'importe quelle base de
donnée. mais à un moment, on va bien lui decrire celle qui nous interesse.
en général, c'est à la conception. mais parfois, c'est à l'execution.
bon, ben ça, c'est le rôle du xsd. il dit, "j'ai une table machin, avec une
colone id qui est clef primaire de type entier et qui s'autoincremente de 2
en 2", etc etc...

mais tu pourrais trés bien par programme ajouter la table, ajouter les
colones, les contraintes et tout et tout.
et ensuite, tu pourrais tres bien passer par la classe Dataset directement
pour manipuler tes données.

y'a juste que pour des feignasses comme nous qui aimons que VS trouve les
erreurs à la compil, ecrire :
decimal montant = (decimal)dataset.Tables["clients"].Rows[8]["montant"] ;
c'est aller droit dans un mur. l'approche, c'est donc de creer une classe
heritiere du dataset, qui propose des propriétés portant les noms des
tables, les noms des colones, avec les bon types, histoire que ça le fasse.
la encore, le xsd intervient. vu qu'il fourni l'ensemble de ces informations
de descriptions, on peut generer la classe automatiquement. ça, c'est le
dataset typé.

maintenant, tu vas me dire "ok, moi je bosse avec une base de données,
bricoler un tableau en mémoire, j'en ai rien à battre".
pas tant que ça en fait. le dataset et la base de données sont completement
deconnectés. c'est volontaire, et tu verras pourquoi.

celui qui fait la jonction avec ta base, c'est le DataAdapter. un
DataAdapter, c'est 4 requetes sql : select, update, insert, delete. en gros,
ansi, tout ce que tu fais sur un tableau, tu peux le faire sur une table du
sgbd. le boulot du DataAdapter, c'est Fill et Update.
- Fill va pomper des lignes en executant le select, et les balances dans le
dataset de ton choix.
- Update regarde toutes les lignes que tu as changé, et execute pour chacune
d'elle l'operation sql qui va bien.

si tu veux la jouer du genre, "oui mais moi, je veux juste effacer une
ligne, alors je veux executer directement le sql, paske ça doit ralentir
d'avoir un paquet d'intermediaires comme ça", t'es mal barré, et t'as rien
compris. déja paske c'est pas plus lent, et de deux parceque ça te rend
independant du moteur de base de données que tu utilises. en plus de cela,
il va falloir écrire ton sql donc ça va être genre :

string sql = @"select * from client where = nom = ' " + textbox1.Text + " '
" ;

et moi je dis, "ah ah ah".

pourquoi, parce que si ton text contient un ' ou une sequence de controle,
ça fout tout par terre, le sql est faux.
et n'importe quel gamin de 12 ans qui a envie de foutre le bordel quelque
part va saisir dans la textbox un truc du genre : dudule' OR TRUE ; DELETE
FROM [utilisateurs] ; //
tout ceci nous amene à la notion de Parameter :

SqlCommand command = new SqlCommand(sqlConnection,"SELECT * FROM [Clients]
WHERE nom = @pnom") ;
command.AddParameter("@pnom",textbox1.Text) ;
...

bref, le DataAdapter fabrique toutes les requetes de cette façon, et tout
seul. ça serait quand même con de perdre des heures à reinventer la poudre,
et la reinventer à moitié.

maintenant, il y'a la Connection. ça existe toujours ça. et c'est necessaire
pour que le DataAdapter puisse papoter avec la base. sauf que la, on a plus
cette notion archaique de "je m'identifie et je garde la connection ouverte"
pendant toute la durée de vie du programme, et des que je rouvre, je
m'identifie à nouveau, et donc, j'en fait une variable globale de l'appli.

la, tu places une connection par form, et la politique c'est que tu laisses
le DataAdapter se demerder. autrement, dit, elle reste fermée en permanence,
sauf quand le DataAdapter à besoin de travailler sur la base. apres, y'a un
pool de connections, ça se debrouille tout seul, tu verras.

maintenant, pour le coté composant de saisie, tu as le DataBinding qui fait
tout tout seul. du moment que tu definis un dataset comme etant celui geré
par la feuille, tu pourras associer à la conception par simple click tous
les champs qui t'interessent avec des textbox, des combos et autres
composants qui t'arrangent.

ET ENFIN, UN EXEMPLE CONCRET :

1) ouvre ton VS, fais toi un projet winform, prend la Form1.
2) ouvre l'explorateur de serveurs (CTRL+ALT+S).
3) si c'est pas encore fait, ajoute une reference dedans vers ta base de
données preferée. disons de l'Access.
4) deroule les tables, prend en une et glisse la sur la Form1.
5) repond "inclu le mot de passe", on va a l'essentiel.
6) sur la feuille tu viens d'obtenir un oleDbConnection1 et un
oleDbDataAdapter1.
7) bouton droit sur le dataAdapter, tu fais "generer le groupe de données".
tu choisi "nouveau", et tu donnes un nom à ton Dataset.
8) il viens de creer un dataset1 sur ta feuille. et au passage il a creer le
schéma qui a permis de fabriquer la classe tout seul.
9) tu poses une grille sur ta feuille et tu affectes DataSource au dataset1,
et DataMember au nom de ta table.
10) poses un bouton "remplir", et OnClick, tu fais
this.oleDbDataAdapter1.Fill(this.dataSet1) ;
10) poses un bouton "mise à jour", et OnClick, tu fais
this.oleDbDataAdapter1.Update(this.dataSet1) ;

ensuite, nous parlerons de concurence, transaction, de ce qui change par
rapport au mode connecté, de ce qui ne change pas, et de comment il faut
faire pour obtenir les effets escomptés.

pour l'instant, bon amusement avec le bidule :o)

>
ensuite, nous parlerons de concurence, transaction, de ce qui change pa r
rapport au mode connecté, de ce qui ne change pas, et de comment il f aut
faire pour obtenir les effets escomptés.

pour l'instant, bon amusement avec le bidule :o)

He bien !! Merci pour tout ça.

MAIS (ya toujours un mais) : Moi je veux pas me servir d'un serveur...
je veux justement que ma base de donnée soit stocké dans un fichier
XML... J'ai pas de base Acces, ni SQL....

Vois-tu mon problème ?? :))

Encore merci :)

> Vois-tu mon problème ?? :))

ben c'est tout vu. t'as plus besoin de DataAdapter et de Connection

tu utilises le ReadXml et le WriteXml du Dataset (avec les bonnes options)
evidement, tu perds les propriétés habituelles du sgbd : multi-utilisateur,
coherence...

mais si c'est ça que tu veux

amplitude wrote:

MAIS (ya toujours un mais) : Moi je veux pas me servir d'un serveur...
je veux justement que ma base de donnée soit stocké dans un fichier
XML...

Bonjour,

XML est un support pour l'échange de données et pour le travail en
déconnecté sur un sous-ensemble de données extraites d'une base de
données "standard". XML est trop bavard et trop redondant pour
constituer un bon format pour un SGBD (même si certains éditeurs ont
sorti des SGBD "natifs XML", je reste très dubitatif).

Mais comme dit A.K., si c'est votre choix, le DataSet fera l'affaire.

J'ai pas de base Acces, ni SQL....

Il n'est nul besoin d'avoir Access pour stocker et manipuler des données
dans ce format. ODBC et ADO donnent directement accès à ce format qui
est donc par conséquent accessible également via ADO .Net. Je vous
rappelle également que le MSDE est gratuit. Ce n'est ni plus ni moins
qu'un SQL Server local. Toutes les classes .Net Sqlxxxxx sont donc
utilisables sur le MSDE.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

Ambassadeur Kosh a écrit :

Vois-tu mon problème ?? :))

ben c'est tout vu. t'as plus besoin de DataAdapter et de Connection

tu utilises le ReadXml et le WriteXml du Dataset (avec les bonnes optio ns)
evidement, tu perds les propriétés habituelles du sgbd : multi-util isateur,
coherence...

mais si c'est ça que tu veux

Oui, m'en fiche du multi-utilisateur! :)

Mais j'utilise dejà ReadXml et WriteXML, avec succés.. :)

mais comment utiliser les Schéma XML en plus ?? là est ma question! : )

Comment géré es base XML avec le fichier XSD ?? :))

Merci! :)

>
Il n'est nul besoin d'avoir Access pour stocker et manipuler des donné es
dans ce format. ODBC et ADO donnent directement accès à ce format q ui
est donc par conséquent accessible également via ADO .Net. Je vous
rappelle également que le MSDE est gratuit. Ce n'est ni plus ni moins
qu'un SQL Server local. Toutes les classes .Net Sqlxxxxx sont donc
utilisables sur le MSDE.

Merci, mais en fait je veux utiliser XML pour éviter d'avoir un serveur
de base de donné lancé à chaque fois que j'utilise mon application finale...

> Oui, m'en fiche du multi-utilisateur! :)
Mais j'utilise dejà ReadXml et WriteXML, avec succés.. :)

quand tu vas charger tes données dans le dataset, soit ton xml va passer,
soit y va casser.

mais comment utiliser les Schéma XML en plus ?? là est ma question! :)

ben comme on te l'as dit. sinon, tu fais du xml pour de vrai et tu passes à
System.Xml.XmlDocument, et la, t'auras plus de possibilités.

tout ça se manipule graphiquement avec l'editeur de schéma et l'editeur de
propriétés.

Comment géré es base XML avec le fichier XSD ?? :))

y'a pas de sgbd xml (enfin bon, je me comprend). y'a les sgbd, et y'a xml.
ça marche pas pareil.

sinon, pour ta colone en +, c bateau. : XmlReadMode.Auto
t'as essayé au moins de bricoler l'exemple que je t'ai filé et de remplacer
save et load par les ReadXml et WriteXml qui vont bien ?

amplitude wrote:

Merci, mais en fait je veux utiliser XML pour éviter d'avoir un
serveur de base de donné lancé à chaque fois que j'utilise mon
application finale...

Bonjour,

Quand on utilise ODBC pour accéder à un fichier .MDB, on ne "lance" pas
un serveur de bases de données. C'est le driver ODBC qui fait le
travail. Idem en ADO.

En tous cas, les ressources utilisées ne seront pas plus importantes que
lorsque vous instancierez un DataSet qui est quand même un objet assez
gourmand. Rappelez vous ce qui a été expliqué: le DataSet est un mini
SGBD local qui de plus vous maintient en parallèle une répresentation
DOM (hiérarchique) des données contenues dans les tables du DatatSet.

En fait, si je comprends bien, vous voulez faire du traitement de
données sans faire du traitement de données :-)) . Si vous voulez être
complètement autonome, il ne vous reste effectivement qu'à stocker vos
données en XML, à utiliser directement un parseur (Pull, Push (Sax) ou
DOM) et à gérer tout cela vous même. Ça ne va pas être incroyablement
efficace. Si vous voulez un service minimum de gestion de données, il
vous faudra bien faire appel aux services d'un gestionnaire, à moins de
tout programmer vous même.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

> sinon, pour ta colone en +, c bateau. : XmlReadMode.Auto
t'as essayé au moins de bricoler l'exemple que je t'ai filé et de
remplacer save et load par les ReadXml et WriteXml qui vont bien ?

bon, je n'arrive pas à lui faire remplir les celulles de nouvelles colones
par la valeur par defaut, il met null systematiquement. je n'ai peut être
pas trouvé / essayé la bonne combinaison de parametres.
j'avais mis (null) au départ comme valeur par defaut dans la nouvelle colone
:o) ceci expliquant cela.

sinon, j'ai du mal de sentir si c'est plus du ressors du dataset ou du
dataAdapter de prendre ce comportement en charge. je pencherais pour le
dataset.

si tu te lances dans l'aventure, le plus "simple", c'est de pomper le code
existant à coup de reflector. lire un xsd pour l'interpreter, ça se fait à
coup de XmlDocument et de requetes xpath dans des fonctions qui
s'entrecroisent. faut connaitre le xsd de xsd sur le bout des doigts pour ne
pas oublier de cas. donc reflector, et beaucoup de courage...

en résumé, ça ressemble à ce que doit faire un sgbd classique quand tu
touches à une strucure, sauf que ça doit faire toutes les actions en une
fois. ces actions sont deduites de l'ecart entre les deux schémas
(structures) : celui des données que tu lis, et le format dans lequel tu
essayes de les faire rentrer.

interessante question que de customiser le comportement de la lecture du
schema en tout cas...

> si tu te lances dans l'aventure...

j'oubliais tellement c'etait evident . l'aventure de la reecriture du
ReadXml du Dataset, ou peut être d'une autre fonctionalité du Dataset dont
j'ignore le nom et qui transforme une ligne en une autre, en fonction de la
différence entre les deux schémas.

maintenant, à la lumiere de ce que dit Patrick, à cause du côté sgbdesque du
truc, cette transformation pourrait bien être finalement un DataAdapter. un
XmlDataAdapter, ou on edicte à la conception les comportement que doit avoir
le zinzin en l'absence de champ. y'aurait du xpath, du xsl, du xsd, et tous
les copains de w3c, et on ferait tous la fête ensemble dans la plus grande
DiscoNet du monde.