C#, Access, ADO, Dataset, DataAdapter

Bonjour,

Je viens vers vous aujourd'hui car je n'ai pas réussi à dompter ce que sont les DataAdapter et les DataSet, je pense avoir compris ce qu'ils représentaient...
Mais mon souhait était d'afficher dans mon DataGridView les infos nécéssaire, or ces infos sont récupérées à l'aide de multiple jointure (Left, iNNER).
En passant par des Ds et des Da je n'arrive pas à utiliser les command de mis à jour, d'update, etc...
Ma question est la suivante après avoir lu moulte infos et cours sur ADO.Net, faut il dans mon code représenter mes BDD avec des DataAdapter et des relations, en gros reproduire ma bdd relationnel en local dans le code ?

Je travaille actuellement en c# et avec une BDD Access (oui je sais c'est d'la marde :aie:)

Merci d'avance, je veux juste réussir à utiliser ces outils qui semble vraiment intéressant dans mon cas.

Ton dataadapter dispose de 4 command.
Le SelectCommand est récupéré du command qui a servit à interroger la base.
Et les autres sont déduit automatiquement du select... mais quand il y a des jointures, impossible de savoir ce que tu veux mettre à jour.

Dans ce cas, il faut les créer à la main en indiquant les requêtes a effectuer.

Attention : un update, insert, delete ne peut porter que sur une seule table à la fois.

C'est là qu'Access va avoir sa limite (enfin... une des ses myriades de limites) : pas moyen de faire des vues modifiables.

Avec SQL Server par exemple au lieu de passer par une requête avec des jointures, tu aurais fait une vue.
Ensuite, quelques triggers insead of sur la vue, et tu peux gérer les opérations de CRUD sur la vue en alimentant les différentes tables jointes.

Pas possible avec Access.

Et merde....
Du coup inutile dans mon cas de passer par des DataSet et des dataAdapter, mon souhait était de gérer les insertions et les updates plus proprement....
jusqu'à maintenant je gère tout à la main avec des requêtes SQL....
En ce qui concerne SQL server et les vue tu aurais des sources concernant le sujet, pour ma culture personnelle...

J'aurais adoré maitriser ces outils qui m'ont l'air vraiment solides et gérable dans le temps....

C'est pas tout à fait sur le sujet, mais ce billet que j'ai écrit contient des exemples de vue avec triggers d'insert, update et delete
https://www.developpez.net/forums/bl...-base-donnees/

Sinon, en supposant que EntityFramework sâche utiliser Access, tu peux essayer de simplifier ton code en l'utilisant.
Il devrait être capable d'aller modifier en cascade des données liées.

Après, je n'ai aucune compétente sur EF : je ne l'ai jamais utilisé, car je préfère maîtriser mes accès aux données.

Merci je vais regarder ça...
Et donc dans mon cas je n'ai pas d'autres solutions que de faire des insert et update en cascade à la main ?
EDIT: Je regarde du côté d'Access à mon niveau je ne cerne peut être pas tout, mais il semblerait qu'il soit possible de faire des vues sur Access.

Salut StringBuilder, désolé du double post, je n'arrivais pas à éditer le post....
Je vais peut être migrer sur SQL SERVER et donc j'ai lu le billet que tu m'as donnée, sur la création de vue, etc.
Si je comprends bien tu fais une vue avec toutes les données qui t'intéresse, tu la blinde de triggers et de procédure, qui "met à jour en cascade" en quelque sorte ?

Merci d'avance :zoubi:

Oui c'est ça.

Du moment que la vue porte sur plusieurs tables, il faut expliquer au SGBD quelles actions effectuer lorsqu'on fait du CRUD.

Par exemple, si j'ai une vue "v_commande", qui récupère toutes les entêtes de commande, en complètant avec l'adresse du client, lorsque je supprime, dois-je supprimer les entêtes de commande concernées, sans toucher au client, dois-je supprimer le client et toutes les commandes qui lui sont liées ? Dois conserver le client sauf s'il n'a plus aucune commande ? etc.

Seuls des triggers sur vue permettent de s'en sortir.
Autre solution, plus "old school" et moins pratique (notamment car impossible à utiliser avec un ORM) c'est de remplacer les opération CRUD par des procédures stockées qui s'occupent de faire tout ça (à la place des triggers).

Sinon, Access ne permet pas à proprement parler de créer des vues.
On peut créer des "requêtes", qui sont alors utilisables comme des vues.
Mais on ne peut pas mettre de trigger dessus pour aurant, ni faire du CRUD dessus.

Citation:

---

Envoyé par StringBuilder

Oui c'est ça.
Sinon, Access ne permet pas à proprement parler de créer des vues.
On peut créer des "requêtes", qui sont alors utilisables comme des vues.
Mais on ne peut pas mettre de trigger dessus pour autant, ni faire du CRUD dessus.

---

Ah Access, pour une première avec les bases de données, je suis gâté ^^"
Je vais essayer de migrer ma base Access sur SQL Server, ce qui va détraquer tout le code de mon IHM en c#:calim2::calim2:
En tout cas je vais essayé d'appliquer les triggers sur SQL SERVER.

Si tu as écrit ton code correctement, tu n'as pas "grand chose" à modifier au niveau de ton IHM.

Principalement tous les objets OdbcXXXXX à replacer par des objets SqlXXXXX, et chaîne de connexion.

Pour le reste, SQL est un langage standardisé, par conséquent il n'y a pas beaucoup de différence syntaxique d'un SGBD à l'autre (tant qu'on fait pas des trucs trop complexes qui auraient été implémenté par la SGBD avant de l'être dans le standard).

Oui je suis en train de m'en rendre compte ^^".

J'ai une question, si je veux faire des objets métiers pour gérer les données dans mon IHM (winform) comment faut il gérer le CRUD ? J'essaye de m'intéresser au Pattern MVC mais je ne trouves rien de bien solide... si jamais vous avez des sources ?