Alimenter une datagridview via un sqladapter impliquant une requête Left Join

Hop,

Aller je me lance car je trouve ça aberrant de ne pas avoir de solution en 5 heures de recherche.

Je développe une nouvelle appli VB.net qui contient un datagridview , j'ai mappé ma source de données (une base Access), créé le databindingsource, le sqladapter et tout et tout jusqu'ici tout vas bien .

Si via le SQL builder je fais une requête mono table, là aussi tout va bien j'ai mon dgv qui m'affiche mes données.

Par contre si j'écrit une requête un peux plus élaborée, avec un left join par exemple, je ne vois pas comment dans la logique du truc je peux dire à mon dgv que sont datasource = tbl_databindingsource correspondant à ma table Data alors que je veux afficher une colonne supllémentaire d'une autre table (La table pointage) du coup je n'ai aucune erreur mais je ne vois pas comment afficher cette colonne heure dans mon dgv...

J'ai bien essayé de créer une colonne supplémentaire via le designer "Heure" dans le dgv mais elle ne m'affiche rien non plus et franchement je vois pas trop niveau code comment l'alimenter.

Alors j'ai bien pensé avoir trouvé la solution sur le net mais après plusieurs tests Nada :-(

Certains parlent de transposer le sqladapter sur un sqlreader d'autre de fill sur une datatable, breff il y a à manger et à boire mais sans résultat probant de mon coté, en tous cas j'ai pas réussi à adapter de solution.

La requete Left Join :

Code:

---

1 2 3 4 5

SELECT Tbl_Data.ID, Tbl_Data.Reference, Tbl_Data.Designation FROM (Tbl_Data LEFT OUTER JOIN (SELECT ID_Affaire_Pointage, SUM(Nb_Heure) AS Heure FROM Tbl_Pointage GROUP BY ID_Affaire_Pointage) Tbl_Pointage ON Tbl_Data.ID = Tbl_Pointage.ID_Affaire_Pointage)

---

Le code d'appel :

Code:

---

1 2 3 4 5 6 7 8

Try Tbl_DataTableAdapter.ClearBeforeFill = False Tbl_DataTableAdapter.See_ALL(Me.MydatabaseDataSet.Tbl_Data) Catch ex As System.Exception System.Windows.Forms.MessageBox.Show(ex.Message) End Try dgv.DataSource = "TblDATABindingSource"

---

Ca me rappel la galère il y a quelques mois pour une autre requête élaborée intégrant fonction sql IN() où j'avais galérer à trouver la solution de contournement...

Bref, j'aurais éventuellement la solution de faire une requête mono table + une requête sur la table pointage puis créer un dico puis boucler sur toutes les lignes du DGV pour alimenter ma colonne "Heure" avec ce même dico, mais bon franchement je trouve ça dommage niveau temps d'exécution du code et la syntaxe à me frapper.

Si quelqu'un à la solution je suis preneur.

@MicroSoft : Prochaine étape prévoir des DataSet qui gèrent des requêtes "complexes" !

Merci d'avance !

Peall13

Bonjour,
Je ne suis pas sur d'avoir tout compris, mais si tu veux afficher les heures il te suffis de les ajouter dans le Select !

Code:

---

1 2	SELECT Tbl_Data.ID, Tbl_Data.Reference, Tbl_Data.Designation, Tbl_Pointage.heure FROM (Tbl_Data LEFT OUTER JOIN

---

Hello Thumb down,

Merci d'essayer de m'aider, malheureusement ce n'est pas un pas un problème de requête elle fonctionne très bien (testé en direct sur Access et j'ai bien mes heures totales qui remonte pour chaque ligne)

Le vrais soucis c'est comment j'alimente mon datagridview alors que celui-ci est lié en théorie aux champs de ma table Data alors que ma requête est le résultat de 2 tables.

Peall13

Bonsoir,

Citation:

---

Le vrais soucis c'est comment j'alimente mon datagridview alors que celui-ci est lié en théorie aux champs de ma table Data alors que ma requête est le résultat de 2 tables.

---

Le vrai souci est de savoir comment tu exécutes ta jointure et comment tu en récupères le résultat dans ton programme.

Si tu utilises un DataAdapter (et un non DataReader), les données sont ordinairement récupérées dans un DataTable. A ce moment, remplir un DataGridVBiew est facile : LeDataGridViewEnQuestion.DataSource = NomDuDataTable.

Si tu utilises un DataReader, il faut transférer ses enregistrements dans un DataTable (il existe peut-être un raccourci ... ?) pour l'affecter ensuite au DataSource du DataGridView .

... :)

Bonsoir,
Personnellement je ne comprends pas quel est le problème exactement !

J'ai le sentiment que notre ami veut voir afficher l'ID de ta table lié comme cela s'afficherait dans Access avec ses valeurs liées et non la valeur de ID!

Il serait bon qu'il explicite sa demande !

Et oui Thumb down ! Si Peall13 nous envoyait le code de sa requête sur les 2 tables, nous comprendrions mieux (peut-être :D) ce qu'il veut montrer dans le DataGridView ...

Hello,

Avant tout merci à tous pour votre aide.

Alors je vais essayer de vous expliquer au mieux le soucis

J'alimenter mes dgv jusqu'à présent comme ceci :

je créer les colonnes via le designer ou en code dans le DGV.

je lançais une requête ADODB

je transféré le résultat de ma requête dans une datatable

et je déclaré pour finir monDGV.Datasource = madatatable

Ca marché super bien quelque soit la complexité de la requête et surtout paracerque je géré les colonne présente dans mon DGV moi même.

Récemment je suis passé à une méthode plus "Clé en main" en déclarant ma data source (donc ma base Access) directement dans mon application.

Le gros avantage c'est que l'on a moins de syntaxe à écrire et faut le reconnaitre le temps d'exécution est plus rapide.

Ce système créer et prend en charge directement un tas d'objet de manipulation des données (SQL adapter, la création de requête via un SQL Builder, la possibilité de mettre un databinidingNavigator sur un USF de manière très simple etc..)

Et surtout vous avez la possibilité de mappé le DGV.datasource directement à l'une des table de votre source de données déclarée dans l'appli et créer du coup toutes les colonnes du DGV en automatique.

Franchement je trouvé la solution plutôt bien par rapport au système ADODB (que j'ai utilisé pendant 5 ans).

Par contre ,à première vu ,c'est à double tranchant puisque le DGV n'affichant strictement que les colonnes de la table où il est lié, va m'afficher que partiellement le résultat de ma requête LEFT JOIN c'est a dire sans le résultat de la colonne (Heure) de ma table 2.

Donc je pense que le soucis et que je ne dois pas lié mon DGV.DataSource à ma table 1 mais au résultat de ma requête mais je ne sais pas écrire en code monDGV.DataSource = monsqlAdapter

Oui c'est compliquer à expliqué je sais surtout qu'il n'y a pas vraiment de code à montrer tout est géré par l'application mais voici à nouveau l'explication du processus :

Code:

---

1 2 3 4 5 6

'donc la je dis d'executer la requête que j'ai écrit dans le Sql buider et que j'ai nommer "SEE_ALL" Tbl_DataTableAdapter.See_ALL(Me.MydatabaseDataSet.Tbl_Data)   'Je déclare la source de données de mon DGV mais l'affichage est bridé aux colonnes de la table DATA , alors que dans mon résultat de requête j'ai une colonne en plus qui viens d'une autre Table 2. dgv.DataSource = "TblDATABindingSource"

---

Peall13

Bonjour,

Merci pour ces explications.

Citation:

---

Ca marché super bien quelque soit la complexité de la requête et surtout paracerque je géré les colonne présente dans mon DGV moi même.

---

Cela est faut, avec monDGV.Datasource = madatatable, tout est fait et il ne faut pas créer préalablement les colonnes, tout au plus, il faut remplacer les textes des Headers de colonnes par des libellés plus "français" que les noms des champs.

Citation:

---

Le gros avantage c'est que l'on a moins de syntaxe à écrire et faut le reconnaitre le temps d'exécution est plus rapide.

---

Moins de code à écrire, c'est sûr. Plus rapide ... ça dépend de la qualité algorithmique du code qu'on écrit.
Perso, le "gros" défaut que je trouve aux DataSet intégrés, c'est la difficulté d'accès aux codes générés par les assistants-concepteurs, ce qui t'empêche notamment de pouvoir facilement faire monDGV.Datasource = madatatable.
Mais n'étant pas fan de cette approche, je l'ai peu pratiquée et du coup, je ne la connaîs pas assez pour t'aider. Peut-être Thumb down le pourra ...

Une dernière remarque, si je peux me permettre :oops:, l'ADODB c'est dépassé depuis plus de 15 ans. L'OleDb est davantage d'actualiité.

Bonne journée,

:D

Bonjour,
Nous sommes dans le paradoxe Microsoft qui préconise de travailler au minimum en trois Tiers {Client,métier,base de données} et qui donne des solutions qui intègre fusionnellement la base de données !

Je refuse catégoriquement d'utiliser ce genre d'objets !

Note cependant qu'il est possible d'écrire ses propres requête et heureusement !

C'est la tasse de thé de Microsoft qui est fan de ce système tu as regardé sur le forum MSDN?

Je t'invites quand même à ajouter un contrôle dataset à ton formulaire si c'est la façon dont tu souhaites travailler !

Depuis trois ans tu étais dans le vrai,tu t'engage dans une voie ou c'est Microsoft qui impose sa loi et toi qui subi!

@Phil Rob

Concernant la création de colonnes, je suis pas vraiment d'accord avec toi ; en effet la data table va dessiner automatiquement les colonnes dans le DGV avec comme Header le même nom que les champs de la table Acces..MAIS ça sera forcement que des colonnes TEXTBOX hors c'est pas forcement le résultat que je veux dans mon DGV, besoin régulièrement de colonne listBox, Checkbox etc...

Alors en avant phases je crée depuis quelque temps mes colonnes dans le DGV + La datable en code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81

Dim x As Byte = 0   Dim colBouton As New DataGridViewButtonColumn Dim coltext As New DataGridViewTextBoxColumn Dim colcheck As New DataGridViewCheckBoxColumn   '0 colBouton = New DataGridViewButtonColumn colBouton.Frozen = False colBouton.HeaderText = "ID" colBouton.Name = "ColumnA" & x colBouton.DataPropertyName = "COL" & x colBouton.ReadOnly = True colBouton.Resizable = System.Windows.Forms.DataGridViewTriState.[True] colBouton.SortMode = DataGridViewColumnSortMode.Programmatic colBouton.DisplayIndex = x Dgv_Uo.Columns.Add(colBouton)   Data1.Columns.Add("COL" & x, GetType(String)) x += 1   '1 coltext = New DataGridViewTextBoxColumn coltext.Frozen = False coltext.HeaderText = "Matricule Assigné" coltext.Name = "ColumnA" & x coltext.DataPropertyName = "COL" & x coltext.DisplayIndex = x coltext.ReadOnly = True coltext.Resizable = System.Windows.Forms.DataGridViewTriState.[True] coltext.SortMode = DataGridViewColumnSortMode.Programmatic Dgv_Uo.Columns.Add(coltext)   Data1.Columns.Add("COL" & x, GetType(String)) x += 1   '2 coltext = New DataGridViewTextBoxColumn coltext.Frozen = False coltext.HeaderText = "Assigné à" coltext.Name = "ColumnA" & x coltext.DataPropertyName = "COL" & x coltext.DisplayIndex = x coltext.ReadOnly = True coltext.Resizable = System.Windows.Forms.DataGridViewTriState.[True] coltext.SortMode = DataGridViewColumnSortMode.Programmatic Dgv_Uo.Columns.Add(coltext)   Data1.Columns.Add("COL" & x, GetType(String)) x += 1   '3 coltext = New DataGridViewTextBoxColumn coltext.Frozen = False coltext.HeaderText = "Référence" coltext.Name = "ColumnA" & x coltext.DataPropertyName = "COL" & x coltext.DisplayIndex = x coltext.ReadOnly = True coltext.Resizable = System.Windows.Forms.DataGridViewTriState.[True] coltext.SortMode = DataGridViewColumnSortMode.Programmatic Dgv_Uo.Columns.Add(coltext)   Data1.Columns.Add("COL" & x, GetType(String)) x += 1   '4 coltext = New DataGridViewTextBoxColumn coltext.Frozen = False coltext.HeaderText = "Désignation" coltext.Name = "ColumnA" & x coltext.DataPropertyName = "COL" & x coltext.DisplayIndex = x coltext.ReadOnly = True coltext.Resizable = System.Windows.Forms.DataGridViewTriState.[True] coltext.SortMode = DataGridViewColumnSortMode.Programmatic Dgv_Uo.Columns.Add(coltext)   Data1.Columns.Add("COL" & x, GetType(String)) x += 1

---

Après est ce que le système ADODB est dépassé ? je ne suis pas assez caler pour mettre en doute cela, moi je vois juste que depuis que je l'utilise, je maitrise parfaitement les subtilités et la syntaxe de ce système de requête, que niveau verbeux c'est plutôt très clair et ça fait le JOB après c'est clair tu crache du code.
Mais J'ai toujours pu écrire les requêtes dont j'avais besoin, des requêtes IN() avec 30 000 items différents par exemple, des requêtes UNION impliquant 3 tables et 70 champs par table , des argument LIKE etc...
Ceci dit, si j'ai décidé d'explorer d'autres systèmes de connexion et requête en choisissant une architecture data Adapter ce n'est pas pour rien… c'est justement que je me disais qu'il y a mieux qu'ADODB tant en terme de rapidité que de syntaxe ou même de compatibilité. Je vais suivre ton conseille et me pencher sur le système L'OleDb (que je ne connais pas du tout) pour mes prochains Soft, j'espère juste que la mécanique est simple à mettre en place.

@Thumb down

Oui j'ai épluché les forums de tous bords...Après je me dis que cette solution clé en main n'est pas la meilleur solution pour tout les besoins. Le pire c'est que j'ai bosser dur pour apprendre à maitriser ce nouveau système et que je me rend compte que finalement ça donnera pas très souvent le résultat que je veux, comme dit dans mon premier poste , j'avais déjà galéré à trouver une solution de contournement (tiré par les cheveux faut reconnaitre) pour faire une requête IN()) sur le dataAdapter.


Pour conclure j'espère que L'OleDb pourra répondre à toutes mes attentes à terme, parce que j'ai aucun intérêt(et puis franchement j'ai pas le temps) d'apprendre à maitriser un tas de système de requête qui aux finals ne répond pas mon besoin réel. Donc si vous avez des suggestions de solution de connexion pérenne je suis preneur :D



Peall13

Re,

Il y a une vérité incontournable (quoi qu'en disent certains), si tu maîtrises bien un outil de programmation, c'est avec celui-là qu'il te faut programmer, même s'il y aura toujours des gens (comme moi) pour te signaler que tel ou tel outil est obsolète.

De plus, il semble bien que ton problème actuel n'est pas dû à l'ADODB, il existerait aussi en OleDB. Je crois que le problème réside dans une méconnaissance du système "clés en main". Là, je ne vais pas faire de leçon, j'en connais probablement moins que toi.

Citation:

---

si vous avez des suggestions de solution de connexion pérenne

---

Je crois que rien n'est pérenne en informatique, tout évolue. Mais quand même, l'ADODB existe encore, l'OleDb a près de 20 ans (ou plus), l'ODBC existe depuis "l'antiquité", ...

En matière de suggestion, par rapport à l'OleDb, je peux te donner des exemples simples mais ils seront empreints de "mon" algorithmique. Toutefois si tu as besoin, fais signe ...

Pour ce qui de la programmation, l'usage de l'OleDb n'est pas tellement différent de celui de l'ADODB. La quantité de lignes à programmer n'est guère différente (selon l'algorithmique employée). Je suis passé de l'ADODB à l'OleDb en passant de VB6.0 à VBNet, vers 2003-2005. Je n'ai pas souvenir d'un bouleversement ...
Si tu veux examiner un peu l'OleDB, ses méthodes et ses propriétés, voici un lien :

https://docs.microsoft.com/en-us/dot...t-plat-ext-5.0

Cordialement,

:D