Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

 Delphi Discussion :

Jointure table - tableau


Sujet :

Delphi

  1. #1
    Membre régulier
    Jointure table - tableau
    Bonjour,

    j'ai un tableau "clients" qui contient une liste de clients
    j'ai une base avec une liste de client, leur appartenance a un groupe ,etc.
    je veux pouvoir "compléter" mon tableau "clients" en y ajoutant leur groupe.

    actuellement, je crée une table "client_temp" ou je vide mon tableau, je fais une requête avec une jointure entre "client_temp" et les différentes tables de ma base pour récupérer les données que je veux, et je remplis mon tableau client avec le résultat de la requête...

    je voulais savoir si je pouvais faire la même chose sans devoir créer une table "client_temp" ? sans pour cela devoir interroger la base pour chaque élément de mon tableau "clients", pouvoir faire en quelque sorte une "jointure" entre mon tableau et ma table....

    j'utilise delphi berlin, ADO, MS-SQL
    dans ma version de delphi, je peux pas utiliser FireDAC avec MSSQL

    merci !

  2. #2
    Expert éminent sénior
    Qu'est-ce qu'un tableau ?

    Une table c'est je suppose une Table dans le SGBD
    un Tableau, Est-ce une grille (DBGrid) dans Delphi ou alors un composant ADOTable relié directement à une table

    C'est pas clair du tout

    Si Table c'est Table
    Si Tableau c'est ADOTable
    Suffit de remplacer ADOTable par un ADOQuery pour le lier via un DataSource à ta DBGrid
    Ensuite dans le ADOQuery c'est une jointure normale entre toutes tes tables avec comme table principale "Clients"

    Après, si il y a de la mise à jour, j'ai pas fait bcp d'ADO et cela remonte à dix ans, je me souviens plus trop du mécanisme de mise à jour via un ADOQuery
    Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
    Attention Troll Méchant !
    "Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
    Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
    L'ignorance n'excuse pas la médiocrité !

    L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
    Il faut avoir le courage de se tromper et d'apprendre de ses erreurs

  3. #3
    Membre émérite
    ça m'a l'air bien compliqué tout ça.

    Si le tableau est un tableau Delphi, pourquoi ne pas lire plutôt les données de la base et compléter le tableau delphi à partir des données lues ??

  4. #4
    Membre régulier
    Citation Envoyé par ShaiLeTroll Voir le message
    Qu'est-ce qu'un tableau ?

    Une table c'est je suppose une Table dans le SGBD
    un Tableau, Est-ce une grille (DBGrid) dans Delphi ou alors un composant ADOTable relié directement à une table

    C'est pas clair du tout

    Si Table c'est Table
    Si Tableau c'est ADOTable
    Suffit de remplacer ADOTable par un ADOQuery pour le lier via un DataSource à ta DBGrid
    Ensuite dans le ADOQuery c'est une jointure normale entre toutes tes tables avec comme table principale "Clients"

    Après, si il y a de la mise à jour, j'ai pas fait bcp d'ADO et cela remonte à dix ans, je me souviens plus trop du mécanisme de mise à jour via un ADOQuery
    oui, désolé,

    un tableau, c'est un array of .... dans delphi
    une table, c'est une table dans la base mssql

  5. #5
    Membre régulier
    Citation Envoyé par Papy214 Voir le message
    ça m'a l'air bien compliqué tout ça.

    Si le tableau est un tableau Delphi, pourquoi ne pas lire plutôt les données de la base et compléter le tableau delphi à partir des données lues ??


    un joli dessin, avec une combobox, et une listbox

    la listbox est rempli par un appel a une API qui me retourne par exemple 1000 code_client

    dans une base de donnée locale, j'ai une table "CLIENTS" avec 50000 code_client avec leur nom de franchise.

    je veux, quand je choisi par exemple la franchise AZZO, la listbox affiche les 3 code_client venant de mon API, ayant une franchisse AZZO dans ma base de données.

    actuellement, je créais une table temporaire(avec 2 colonnes: code_client, franchisse) dans ma base pour y mettre mes 1000 clients venant de l'api, et je mettais à jour franchisse en faisant une requête UPDATE entre la table TEMP et la table CLIENTS
    du coup, quand je choisis AZZO dans ma combobox, je filtre juste sur ma requête qui interroge la table TEMP.

    tu me dis de compléter mon tableau a partir de la requête, ok maisça veut dire que pour chaque enregistrement de ma table "CLIENTS", je dois rechercher dans mon tableau le bon code_client pour mettre à jour la franchise
    et ensuite, quand je choisis dans ma combobox "AZZO", je dois parcourir mon tableau pour remplir la listbox....
    je voulais savoir si y'avais pas plus performant...

    désolé si je suis pas très clair...

  6. #6
    Membre émérite
    s'il n'y a pas de besoin de refresh permanent, et si j'ai bien compris la problématique, est-ce qu'un TList d'objets défini chacun par un numéro de client + un tableau des codes correspondants ne ferait pas l'affaire ?
    La listbox serait mise à jour sur le onchange de la combo en prenant le tableau des éléments qui correspondent au client.

    Plus besoin de créer une table à chaque utilisation

  7. #7
    Membre régulier
    Citation Envoyé par Papy214 Voir le message
    s'il n'y a pas de besoin de refresh permanent, et si j'ai bien compris la problématique, est-ce qu'un TList d'objets défini chacun par un numéro de client + un tableau des codes correspondants ne ferait pas l'affaire ?
    La listbox serait mise à jour sur le onchange de la combo en prenant le tableau des éléments qui correspondent au client.

    Plus besoin de créer une table à chaque utilisation
    la table était créée juste au demarage de l'appli ou si on faisait un refresh, ce qui me gene, c'est de creer une table dans une base qui est pas la mienne....

    pour la tlist, oui je comptais faire comme ça, mais la problématique est de la remplir avec les code_client venant de l'API, la pas de probleme, mais apres pour mettre à jour la franchise de la Tlist a partir de la table CLIENT, je suis obligé de parcourir toute la Tlist pour chaque enregistrement de la table CLIENT pour y mettre a jour la franchise....!?

    si j'ai par exemple 1000 clients de l'aPI , et 50000 dans ma table CLIENT, je vais parcourir 50000 fois la Tlist
    il est la mon problème, je peux pas faire une requête de la table CLIENT qui revoit juste les clients présent dans l'API(1000), je renvois les 50000... j'suis clair ?

  8. #8
    Rédacteur/Modérateur

    Bonsoir
    MS SQL a bien des tables temporaires (nom commençant par #) pourquoi ne pas les utiliser ?
    Bon je ne sais pas trop comment cela fonctionne avec MS SQL mais avec Firebird la table temporaire est "a la session" donc pas de mélange en cas de multi-user et cela se vise soit en fin de transaction soit en fin de session
    La seule chose absolue dans un monde comme le nôtre, c'est l'humour. » Albert Einstein

    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Tokyo, Rio) et peut être quelques autres
    SGBD : Firebird 2.5, 3, SQLite
    générateurs Etats : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Ubuntu, Androïd

  9. #9
    Membre actif
    Salut à tous,
    soit les tables:
    - CLIENTS avec au minimum les champs CODCLI (identifiant unique) et CODGRP
    - CLIGROUP avec au minimum les champs CODCLI et CODGRP
    Code sql :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    update CLIENTS A
    set A.CODGRP=(select B.CODGRP from CLIGROUP B
                            where B.CODCLI=A.CODCLI
                            group by B;CODCLI)
    where A.CODCLI in (select C.CODCLI from CLIGROUP C group by C.CODCLI)

    Mettra à jour CODGRP de tous les CLIENTS extstants dans CLIGROUP.
    Tu mets çà dans un Query connecté à ta base et ça devrait marcher avec la majorité des SGDB.
    A condition que dans la table CLIGROUP les CODCLI sont soient:
    - uniques
    - ou si pas unique, tous les records d'un même CODCLI devront avoir le même CLIGRP, sinon SQL error
    solilog

  10. #10
    Membre régulier
    salut tous,

    je viens de faire comme suggéré avec des tables temporaires, il faut juste que je garde la même Query dans mon code pour garder la même "session"

    merci beaucoup !