DataRelation dans DataSet

Bonjour à tous,

Je développe une application en interaction avec une base de donnée, on m'a demandé de remonter toutes les données au chargement de l'application afin d'avoir une plus grande fluidité pendant l'utilisation de celle-ci.
(évidemment ils décident ça a 2 jours de la validation de cette étape de la programmation :aie:)


Je créé donc un DataSet, rempli par des DataTables.
J'aimerai joindre les tables par une Data relation mais je me confronte à une erreur :
Je créé ma relation de cette manière :

Code:

---

1 2 3

Dim relationiliiim As New DataRelation("ili_iim", DataSetGlobal.Tables(0).Columns(1), DataSetGlobal.Tables(2).Columns(1)) DataSetGlobal.Relations.Add(relationiliiim)

---

A l'execution voici le message d'erreur que j'obtiens :

Citation:

---

Ces colonnes n'ont pas actuellement de valeurs uniques.

---

D'après la doc que j'ai lu sur MSDN, l'erreur vient du fait que dans le champ parent, il existe un ou plusieurs résultat(s) qui ne sont pas unique.

Or lorsque j'execute ma requête sur le serveur dans une table temporaire TEMP et que je fais un :

Code:

---

1 2	SELECT Produit,COUNT(*) FROM TEMP GROUP BY Produit HAVING COUNT(*) <> 1

---

La table ne me retourne aucun résultat.
Lorsque je ne fais qu'un simple :

Code:

---

1 2	SELECT Produit, COUNT(*) FROM TEMP GROUP BY Produit

---

Je vois bienque tous les count ont pour valeur 1 et que j'ai autant de résultat qu'il y a de ligne dans ma table.

D'où peut venir le fait que visual studio me dise que les valeurs de mon champ ne sont pas uniques ? Si dans la table enfant il y a plusieurs lignes avec le même "Produit" est-ce grave (d'après la doc MSDN non) ?
Connaissez vous un autre moyen de remonter des table d'une base de données et de joindre ces tables ?
La DataRelation est-elle la seule façon de joindre plusieurs DataTables d'un même DataSet ?
Avez vous de l'aspirine ?:aie:

Merci à vous de prendre le temps de me lire et bonne journée !


----------
Précisions :
Les données sont remontées en 2minutes ~. Si je fais la jointure avant de remonter pour ne créer qu'une table, cela met plus de 10minutes et c'est trop long d'après l'utilisateur.

Si je fais mes requêtes en live à chaque clic, j'ai des freezes de 30sec ~ et même problème.
Je dois donc absolument arriver à optimiser la requête qui doit avoir lieu au chargement de l'application.

L'erreur la plus probable est:

L'inversion des paramètre childcolumn et parentcolumn sur le constructeur de ta datarelation.

Je me suis dit la même chose. J'ai vérifié dans l'info-bulles ce n'était pas ça.
(Dans le doute j'ai tout de même échangé mais cela n'a pas résolu le problème) :aie:

Les index des colonnes ne devrais pas commencé à 0?, En principe la première colonne devrais être la clé donc essaie plutôt ceci.

Code:

---

1 2 3

Dim relationiliiim As New DataRelation("ili_iim", DataSetGlobal.Tables(0).Columns(0), DataSetGlobal.Tables(2).Columns(0)) DataSetGlobal.Relations.Add(relationiliiim)

---

Citation:

---

Envoyé par lilroma

Les index des colonnes ne devrais pas commencé à 0?, En principe la première colonne devrais être la clé donc essaie plutôt ceci.

Code:

---

1 2 3

Dim relationiliiim As New DataRelation("ili_iim", DataSetGlobal.Tables(0).Columns(0), DataSetGlobal.Tables(2).Columns(0)) DataSetGlobal.Relations.Add(relationiliiim)

---

---

Et bien en fait lorsque je déclarais la clé primaire de ma table j'avais la même erreur.
Ce que je ne comprends d'ailleurs pas car comme je le disais, lorsque j'execute directement la requête sur iSeries, il me renvoi que chaque produit n'existe qu'une seule fois dans la table et ce pour toute les lignes. ( pas de null ou doublons)
Du coup ma 1ère colonne est un RRN(TABLE) qui génère un nombre unique sur lequel je me base pour ma clé primaire.
Mon code produit est donc la 2ème colonne et donc bien la numéro index 1.

Requête qui remplit ma DataTable :

Code:

---

1 2	SELECT RRN(MaLibrairie.MonFichier),IPROD,IITYP,ICLAS,IDESC,IREF,IWHS from MaLibrairie.MonFichier WHERE IWHS NOT IN ([mes filtres]) AND IID NOT IN ([mes filtres]) AND IPROD NOT IN ([mes filtres])

---

Mais cette solution n'est pas viable pour une jointure entre deux tables :(

(Je travaille sur un AS400 si cela peut changer quelque-chose...)

Citation:

---

on m'a demandé de remonter toutes les données au chargement de l'application afin d'avoir une plus grande fluidité pendant l'utilisation de celle-ci.

---

Encore l'idée lumineuse de quelqu'un qui n'a rien compris aux bases de données.

Citation:

---

Les données sont remontées en 2minutes ~. Si je fais la jointure avant de remonter pour ne créer qu'une table, cela met plus de 10minutes et c'est trop long d'après l'utilisateur.

---

Plutôt étrange. 10 minutes est vraiment trop long même pour des tables de plusieurs dizaines de Go de données.

Dans ta base, les colonnes servant de clés sont-elles déclarées comme clés primaires (déjà ça éviterais les doublons sur ces colonnes) ????
Ces clés sont-elles associées à des index.

Ensuite les colonnes qui rentrent régulièrement dans tes clauses where sont-elles, elles aussi, indexées ???

Pour ton problème de requete, est-ce que la colonne Produit sur laquelle tu teste ta requete correspond-elle à la colonne que tu essaye de mettre dans ta relation, car c'est sur cette colonne qu'il y a un doublon. Le doublon n'est pas forcément sur toute la ligne.

Citation:

---

Envoyé par sevyc64

Encore l'idée lumineuse de quelqu'un qui n'a rien compris aux bases de données.

---

Malheureusement je suis en CDD pour une mission, je n'ai pas mon mot à dire :(

Citation:

---

Plutôt étrange. 10 minutes est vraiment trop long même pour des tables de plusieurs dizaines de Go de données.

---

Je récupère des infos sur 8tables de plusieurs milliers (dizaines de miliers puisque y'a des table d'historique de transaction depuis 1996 :D )
sur des tables, des vues etc... avec les joyeux INNER JOIN et GROUP BY qui vont avec (la requête qui prend 10minutes fait quand même plus de 45 lignes :aie:)

Citation:

---

Dans ta base, les colonnes servant de clés sont-elles déclarées comme clés primaires (déjà ça éviterais les doublons sur ces colonnes) ????
Ces clés sont-elles associées à des index.

---

Les clé primaires sont composés de 3 ou 4 colonnes sur certaines tables, mais le champ "Produit" de ma table parente ne retourne bien q'un résultat par produit". Je n'ai pas accès aux sources des fichiers de l'AS 400 qui décrivent les tables, les clé primaires etc...
(D'ailleurs je devait commencer ma mission avec l'analyse déjà faite car je suis développeur sortant à peine de mon BTS et suprise rien n'a été fait je dois tout faire sans les ressources nécéssaires, établir des requêtes sur des tables que je ne connais pas et composées uniquement d'acronymes :( J'ai déjà du retard sur mon planning (réalisé moi même, en sortant de l'école c'est dur d'estimer sa vitesse de travail :aie:) car je dois établir des MCD sur une base de données de plusieurs Tera sans avoir accès a tous les fichiers et je ne finirai pas ma mission a temps en gros suis dans le caca :aie: mais là est un autre problème )

Citation:

---

Ensuite les colonnes qui rentrent régulièrement dans tes clauses where sont-elles, elles aussi, indexées ???

---

Idem c'est compliqué car on me demande impérativement de passer par tel ou tel fichier logique et les index changent selon le fichier et je n'ai pas accès aux définitions des logiques

Citation:

---

Pour ton problème de requete, est-ce que la colonne Produit sur laquelle tu teste ta requete correspond-elle à la colonne que tu essaye de mettre dans ta relation, car c'est sur cette colonne qu'il y a un doublon. Le doublon n'est pas forcément sur toute la ligne

---

Tout à fait dans toutes les table on retrouve ce champ précédé d'une lettre définissant la table :
TProduit pour produit de la table Transaction
Cproduit pour produit de la table Couts etc...


J'avais commencé à programmer en faisant mes requêtes en temps réel selon l'action de l'utilisateur, cela marchait à la perfection à part la latence entre chaque action du coup. Mais à 2jours de la validation ils ont décidé de changer ça et de travailler avec des fichiers tampons remontés dès le chargement de l'appli.
(Et encore je suis a l'étape 1 sur 10 à finir avant décembre :aie:)

A défaut si vous avez un échappatoire pour ce CDD... :ccool::aie::mouarf:

Ok

Alors, si tu es sur que DataSetGlobal.Tables(0).Columns(1) ne contient pas de doublons, une autre source possible du problème est peut-être que la colonne fille de la relation contient à moment donné une valeur qui ne peut-être retrouvée dans les valeurs de la colonne mère, ce qui laisserais une fille orpheline et empêcherait donc la relation de se faire

Malheureusement je viens de tester :

Code:

---

1 2	SELECT TProduit FROM TableEnfant WHERE TPRODUIT NOT IN ( SELECT PRODUIT FROM TableParent)

---

Qui ne retourne aucun résultat :(

Je fais comme toi, je sèche.

Tu as vérifier que tu n'as pas de valeur Null sur le colonne Produit de la table mère et sur la colonne TProduit de la table fille ?

Citation:

---

Tu as vérifier que tu n'as pas de valeur Null sur le colonne Produit de la table mère et sur la colonne TProduit de la table fille ?

---

Affirmatif, aucun trou dans aucune des tables :)

Citation:

---

Envoyé par sevyc64

Je fais comme toi, je sèche.

---

Ah non je sèche pas, je sue !:aie: La validation c'est demain à 10H, je vais encore finir a je ne sais pas quelle heure car ils ont décidé de tout changer 2jours avant -_-

Bon, ta relation ne se fait pas, c'est donc que tu as un couple de données incohérent.

Essaye cette requete, et regarde dans le résultat, pour chaque valeur de la 1ere colonne, tu dois obtenir exactement la même valeur dans le seconde colonne

Code:

---

SELECT TableEnfant.TProduit, TableParent.Produit FROM TableEnfant LEFT OUTER JOIN TableParent ON TableEnfant.TProduit=TableParent.Produit

---

Si tout est correct, je ne vois pas ou peut-être le problème.

J'ai bien éxécuté ta requête, exporté les résultat sur excel pour m'afficher une erreur dans la cellule d'a coté si les valeurs étaient différentes.
Pas de messages. :cry:

Faut t'il que je pense à investir dans une corde ? :aie:
(ou a changer de métier, vu le premier boulot ca commence bien :aie:)

Bon autrement faut se poser les questions suivantes:

1. Est-ce qu'il y a vraiment une contrainte relationnel sur la base de donnée (c'est quoi comme base au fait?)

- Si ce n'est pas le cas, c'est la porte ouverte aux emmerdes et tu as meilleur temps de gérer la contrainte en code. En effet tu ne pourras jamais être sur que ce que t'envoie la BD rentrera dans le moule de ton dataset (et ça peut être une ligne qui date de 10 ans en arrière...) Ceci d'autant plus s'il y a d'autres applications qui utilisent cette base.

2. Essayer de créer les tables, les contraintes (clé primaire et autre non null) et ensuite la relation (si tu arrive à utiliser le nom plutôt que l'index de colonne ça serra plus visible) dans le dataset (jusque la doit pas avoir d'erreur...) puis de remplir successivement la table mère, puis la table fille à l'aide de datareader (Avec deux traditionnel requête SELECT champ1 à champN FROM latable). Tu verras bien sur quel champ la boucle du datareader.read plante. Si ça plante pas t'as une solution "viable" pour remplir ton dataset et tu pourras te prendre la tête sur le sujet quand tu auras plus de temps. Si ça se plante tu as un début de preuve viable pour prouver qu'il n'y a pas de relation sur la BD et retour au point 1.

Quelques petites précision sur la relation:

Une relation peut concerné plus d'une colonne, mais le nombre de colonne doit être égal de chaque coté de la relation

Une relation du coté table mère doit intégrer toutes ET uniquement les colonnes définissant la clé primaire

=> Donc une parenté avec une table mère à 4 colonnes nécessite 4 colonnes chez la table fille mais un seul objet relation (et non pas 4).

Certaines base de donnée accepte une valeur Null dans la clé primaire, ADO.Net et ses datatables NON !!! (ce qui provoque un plantage du chargement de la table mère)

Au passage la requête suivante ne vérifie aucunement qu'il n'y a pas 2 fois la même clef primaire:

SELECT Produit, COUNT(*) FROM TEMP GROUP BY Produit

Et au passage avec la description de ton histoire (surtout le temps de chargement) j'ai sérieusement des doutes sur la présence de clé primaire, d'index et de relation... (Tu mixes ça avec un vieux technicien qui ne sait pas de quoi il parle et bonjour les quiproquos)

J'ai comme un doute aussi :

C'est une base de données ou y a aboslument tout :
articles, compta, transaction, comptes utilisateurs etc...

entre la majorité des table c'est le code produit qui sert de jointure, mais j'ai plus l'impression qu'il font correspondre 2champs à l'arrache plutôt qu'il y ai vriament des jointures, clé étrangères, clé primaires etc... ( la DB aura 15 ans sous peu...)

Je vais tenter tant bien que mal de définir mes contraintes avec du code...

(Dans quelle galère me suis-je embarqué :aie: pour un premier boulot c'est top :ccool:)