PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV 2025 → Requetes SQL multi-bases
Requetes SQL multi-bases
Débuté par lidwine.lassalle, 08 juil. 2024 16:32 - 8 réponses
Posté le 08 juillet 2024 - 16:32
Bonjour,

Je cherche à liste des éléments d'une table d'une base qui ne sont pas présents dans une autre table d'une autre base (sur 2 serveurs différents, sinon je sais préfixer le nom dans la base en SQL).

Ce tuto en parle
https://doc.pcsoft.fr/?2034010

Cette question aussi
https://forum.pcsoft.fr/fr-FR/pcsoft.fr.windev/96051-select-sur-source-donnees/read.awp

Moi moi rien n'y fait :(
J'ai simplifié mes requetes, mais voilà la structure

HDécritConnexion("MaConnection1" ...
HDécritConnexion("MaConnection2" ...

REQ1 est une Source dede Données
sRequete = "SELECT TASK_SEQ
FROM TABLE"
HExécuteRequêteSQL(REQ1,"MaConnection1",hRequêteSansCorrection,sRequete)

REQ2 est une Source dede Données
sRequete = "SELECT tache_id FROM planning_taches"
HExécuteRequêteSQL(REQ2,"MaConnection2",hRequêteSansCorrection,sRequete)


sMonCodeSql est une chaîne
sdMaRequêteSql est une Source dede Données

sMonCodeSql = ChaîneConstruit([
SELECT %1.TASK_SEQ
FROM %1
Left OUTER JOIN %2 ON (%1.TASK_SEQ=%2.tache_id)
where %2.tache_id is Null
],REQ1..,REQ2..Nom)



Mais rien n'y fait, la requête basée sur les 2 premières me retourne une erreur

Si je veux faire ça, c'est pour améliorer les temps de réponse et utiliser du SQL au lieu de code séquentiel pour parcourir ligne à ligne pour vérifier ce que je fais déjà.

Merci beaucoup
Membre enregistré
496 messages
Posté le 08 juillet 2024 - 19:13
Bonjour,

Peut-être s'agit-il du réglage du nommage de source de données (cf. l'onglet compilation dans la description du projet) : https://doc.pcsoft.fr/?9500218&verdisp=160

Cela étant dit, je ne suis pas bien sûr que cela soit bien plus rapide que de passer par de la lecture séquentielle à la main, puisque WinDev devra d'abord charger en mémoire tous les résultats de chaque table avant d'en faire la lecture et la jointure.
Posté le 09 juillet 2024 - 08:32
Bonjour

Merci pour cette piste non encore explorée, cool du nouveau :)
Je vais regarder cette histoire de description ... je croise les doigts

Pour la rapidité, quand je vois déjà la rapidité des 2 première requêtes, j'ai espoir que quand j'arrive à exécuter la 3ème avec la jointure, cela continue dans ce sens.

Je reviens apres mes tests
Posté le 09 juillet 2024 - 11:01
Bon, c''était une nouvelle piste, mais ça ne change rien

L'erreur sur le dernière requete c'est :




La table indiquée n'est pas celle de la requête que je vous ai mis dans ma question, j'avais simplifié, la requête c'est SELECT TASK_SEQ From FP_OPERA_PLANNING et pas SELECT TASK_SEQ From FP_OPERA_PLANNING

Mais je mets l'erreur si ça parle plus ...
Membre enregistré
4 308 messages
Posté le 09 juillet 2024 - 15:05
Bonjour,
As tu tenté de passer par une requête paramétrée dont le paramètre est le string_agg de la première requête ?
Principe à la volée :
REQ_1
SELECT STRING_AGG (TASK_SEQ,",") AS Liste
FROM TABLE


REQ_2
SELECT tache_id
FROM planning_taches
WHERE tache_id IN ({pListe)}


Il suffit alors de passer (après exécution) REQ_1.Liste en paramètre.

Attention, dans certains cas, Windev demande un séparateur ";" à la place d'une "," il suffit de faire la modif dans le string_agg

--
Il y a peut être plus simple, mais, ça tourne
Message modifié, 09 juillet 2024 - 15:46
Posté le 10 juillet 2024 - 09:25
Bonjour

Merci pour cette idée.

J'avoue je ne connaissais pas STRING_AGG, mais après recherche c'est démentiel !

J'ai appris quelque chose de trop pratique (et l'équivalent en MySQL car une de mes bases est en MySQL).

Je pense que je touche au but.
J'ai testé l'imbrication de REQ_1.Liste en paramètre et ça fonctionne.
A cause du problème que je vais décrire ci-dessous, J'ai fait une requête basique en REQ1 qui me donne 1 enregistrement, pour valider l'imbrication et ça passe.

MAIS mon problème a été déporté.
Alors que la requête avec le STRING_AGG passe dans l'éditeur de requête de l'ERP
Elle ne passe pas depuis mon appli avec le connecteur ODBC






C'est frustrant, je n'ai jamais été si proche.
J'ai MAJ le pilote ODBC pour PostgreSQL, je vais chercher d'autres pistes techniques
Membre enregistré
4 308 messages
Posté le 10 juillet 2024 - 10:37
Qu'est ce que cela donne avec les connecteurs natifs ?

--
Il y a peut être plus simple, mais, ça tourne
Membre enregistré
496 messages
Posté le 10 juillet 2024 - 12:43
L'erreur ne provient pas spécifiquement du pilote ODBC.

STRING_AGG() est une fonction d'agrégation. Comme en HFSQL (et dans tous les autres SGBD quasiment), elle requiert que toutes les autres colonnes non-agrégées soit spécifiées dans la clause GROUP BY.

Ici apparemment, la colonne demandée fp_opera_planning.ctid n'est ni agrégée, ni dans le GROUP BY.
Posté le 10 juillet 2024 - 15:28
Alors pour répondre à tous, déjà merci !

@bchanudet, pour le STRING_AGG et l'erreur dans le GROUP BY, ce n'est pas une erreur de syntaxe.
La requete passe telle quelle dans l'outil de requetage de l'ERP, d'où mon hypothèse du ODBC

ET, ce qui répondre aussi à @Voroltinquo, la requete passe aussi telle quelle en natif avec les commandes SQLExec
Car en effet, entre temps je me suis demandé si ne je pouvais pas changer de connecteur

HOURRA

Donc je fais ma requete sur ma base Postgres avec STRING_AGG via SQLExec
Et le résultat je le passe dans ma requete sur la base MySQL avec un IN ()

ET là je gagne ... 20 minutes de temps de traitement !!!