récupérer les relations table Access en c#

[jojo150393]

Bonjour à tous,
malgré mes nombreuses recherches je n'arrives toujours pas a trouver une solution.

Coté base de donnée, j'ai deux tables, "Posts" et "Users". La table "Posts" possède une champ "user_id" qui permet de relier le post à l'utilisateur. J'ai bien relié les deux tables dans Access.
Voici le code pour récupérer la table "Posts":

 DataSet result = new DataSet();
            OleDbCommand cmd = new OleDbCommand();

            connection.Open();
            cmd.Connection = connection;
            cmd.CommandText = "SELECT * FROM Posts";
            OleDbDataAdapter adapter = new OleDbDataAdapter(cmd);
            adapter.Fill(result);
            DataRelationCollection relations = result.Relations;
            foreach (DataRelation r in relations)
            {
                MessageBox.Show(r.ParentColumns[0].ColumnName);
            }

Ce que j'aimerais, ça serais de récupérer la colonne correspondante de la table "Users" est-ce que c'est possible ou il faut récupérer toutes les relations à la main ?

Merci pour vos éclaircissement.
-----

[invite0bbe92c0]

Bonjour

Votre question n'est pas tout à fait claire.

Vous voulez récupérer le schema de la base ? C'est possible avec presque tous les SGBD en, adressant des vues internes mais Access n'ayant que marginalement les caractéristiques d'un SGBD standard, je ne sais pas si c'est faisable en tout cas via OleDB.

Merci de préciser exactement ce que vous voulez faire et de poster le DDL des tables (car contrairement à ce que votre titre laisse penser, il semble que ce soit plus un problème SQL qu'un problème C#).

Accessoirement, on ne doit jamais utiliser la syntaxe "select *" autrement que pour un test dans un outil client.

Bref, on ne sait pas trop si vous souhaitez récupérer des données (auquel cas on se demande ce que vient faire DataRelationCollection ici) ou la description des relations. SI c'est pour des données, faire une requête avec jointure sur les deux tables.

[jojo150393]

Merci de votre réponse.
J'aimerais récupérer les données. Je pensais que oleDb nous facilité le travail en nous renvoyant directement les tables liées et qu'elles se trouvaient dans dataRelationCollection. J'ai pas du tout d’expérience avec les bdd en c# pardonnez mon ignorance. Il est vrais qu'avec une requêtes sql c'est peut être plus simple qu'en utilisant oleDb. Je pense que je vais revoir l'architecture car ça n'à pas l'air d'être correct.

En faite j'aimerais seulement que la requête vers la table "Posts" me renvoi aussi la table "Users" en fonction des "user_id". En gros un quelques chose comme ça :

Posts{
  1 => {
     id => 1
     title = "un titre"
     user_id = 2
    }
 }
Users{
 1=>{
    id => 2
    name = "un nom"
}

Je sais pas si c'est faisable donc de pourvoir récupérer quelque chose directement. En faite je m'inspire surtout de ce que je fais en PHP où j'ai beaucoup plus pratiquer avec les bdd.

[invite0bbe92c0]

Je sais pas si c'est faisable donc de pourvoir récupérer quelque chose directement. En faite je m'inspire surtout de ce que je fais en PHP où j'ai beaucoup plus pratiquer avec les bdd.

Une requête ne renvoie pas de table, elle renvoie des lignes avec des colonnes.
C'est donc bien une question de SQL.

Il suffit de prendre la bonne requête :

Par exemple :

select u.id, name, title 
from users u 
inner join posts p 
on p.user_id = u.id

C'est du SQL standard, mais il y a des chances que ca marche avec Access, machin pas vraiment standard.

Si Access n'accepte pas l'aliasing utiliser :

select users.id, name, title 
from users
inner join posts
on posts.user_id = users.id

[A voir en vidéo sur Futura]

[jojo150393]

Merci bien pour la réponse. Le problème avec cette solution c'est qu'il faut connaitre le user_id avant d'aller le chercher. Si je veux récupérer tous les postes et les users, ça veut dire qu'il y aura autant de requête que de post (pas terrible niveau perf) et c'est assez lourd à mettre en place. J'ai cherché une solution propre et efficace mais j'ai pas réussis à trouver. Même sur internet, la question n'ai jamais traité, pourtant le c# est orienté web et on fait constamment ce genre de chose en web...

[Jack]

pourtant le c# est orienté web

Curieuse affirmation. Qu'est-ce qui te fait dire çà? C# est plutôt orienté applications locales.

[jojo150393]

Ce que je veux dire c'est qu'il peut faire les deux, c'est pas comme le c++ que je n'ai jamais croisé dans le web. Enfin bref c'est pas le sujet. Je vais voir si j'arrives a trouver une solution convenable et assez propre.

[invite0bbe92c0]

Curieuse affirmation. Qu'est-ce qui te fait dire çà? C# est plutôt orienté applications locales.

Ni l'un ni l'autre à vrai dire.

[invite0bbe92c0]

Merci bien pour la réponse. Le problème avec cette solution c'est qu'il faut connaitre le user_id avant d'aller le chercher. Si je veux récupérer tous les postes et les users, ça veut dire qu'il y aura autant de requête que de post (pas terrible niveau perf) et c'est assez lourd à mettre en place.

Si tu avais précisé dès le début que ton niveau en SQL est "en dessous de 0" j'aurais été plus explicite, mais on est pas devin.
La requête que je t'ai passé récupère tous les postes et users. (il n'y a pas de clause where); tout le reste de ton message est donc dénué de sens.

J'ai cherché une solution propre et efficace mais j'ai pas réussis à trouver. Même sur internet, la question n'ai jamais traité, pourtant le c# est orienté web et on fait constamment ce genre de chose en web...

Ta question n'ayant rien à voir avec le web on ne voit pas trop ce que veut dire "le c# est orienté web", d'autant que c'est faux.

[jojo150393]

Mon niveau de SQL n'est absolument pas de 0, c'est juste que j'ai toujours utilisé une classe d'abstraction qui me permettait de ne pas réinventé la roue et de se coltiner à chaque fois les requêtes SQL et la récupération des liaisons entre les tables. Mais bon apparemment je suis "au dessous de 0" alors bon je vais laisser le savoir aux grands sages et retourner dans le peuple ignorant.

Quand je fais le lien avec le web c'est uniquement parce qu’on utilise constamment des bases de données et que les langages et techno dans ce domaine sont très bien fichus (PHP, Doctrine et j'en passe) et que j'espérais, comme on a la possibilité de faire du web avec c#, qu'il le soit aussi. Mais bon apparemment il ne sait faire "ni l'un, ni l'autre" donc en gros il sert a rien selon toi.

Je ferme le sujet et je n'y répondrais plus, les sujets qui partent sur des débats inutiles ça me saoul.

Merci quand même pour vos bonnes volontés.

[invite0bbe92c0]

Mon niveau de SQL n'est absolument pas de 0,

Ben si : quand on ne peut pas relire une requête de jointure basique, c'est comme dire qu'on connait le C mais sans savoir faire une boucle "for".


C'est bien sur pas un problème de pas connaitre SQL, mais affirmer le contraire dans ce cas c'est bizarre.

c'est juste que j'ai toujours utilisé une classe d'abstraction qui me permettait de ne pas réinventé la roue et de se coltiner à chaque fois les requêtes SQL et la récupération des liaisons entre les tables. Mais bon apparemment je suis "au dessous de 0" alors bon je vais laisser le savoir aux grands sages et retourner dans le peuple ignorant.

Curieux. Si tu utilisais un ORM (EF, Hibernate, etc .) ca ne dispense pas de l'écriture des PS, donc de la connaissance du SQL.

Quand je fais le lien avec le web c'est uniquement parce qu’on utilise constamment des bases de données et que les langages et techno dans ce domaine sont très bien fichus (PHP, Doctrine et j'en passe) et que j'espérais, comme on a la possibilité de faire du web avec c#, qu'il le soit aussi. Mais bon apparemment il ne sait faire "ni l'un, ni l'autre" donc en gros il sert a rien selon toi.

Là on tombe dans le n'importe quoi mais quelque part on comprend mieux, venant de quelqu'un qui considére PHP comme "bien fichu" (les bras m'en tombent ).
Contrairement à PHP on peut tout faire avec C#, sauf des drivers et de l'ABI.

Je ferme le sujet et je n'y répondrais plus, les sujets qui partent sur des débats inutiles ça me saoul.

Ca tombe bien, je n'ai plus l'intention de te répondre.