Discussion :

[L6N2000]

Bonjour,

J'ai réalisé une requête SQL avec un LEFT OUTER JOIN, lorsque je l'éxécute suite à un strsql, je n'obtient pas le même résultat que lorsque je l'éxécute dans le SQLRPG.

Quelques détails :
J'obtiens le même nombre d'enregistrements dans les 2 cas.
Le résultat attendu est en SQL : 3 enregistrements issus du fichier maître qui n'ont pas de correspondance dans le fichier JOIN et un enregistrement qui a des données des 2 fichiers
Suite à l'exécution du SQLRPG : J'ai 3 fois le même enregistrement issu du fichier maître qui n'a pas de correspondance dans le fichier JOIN et l'enregistrement qui a des données dans les 2 fichiers.

Est-ce que quelqu'un saurait me dire dans quelle direction chercher ?
d'avance merci

[K2R400]

Hum, hummm, bizarre, bizarre.
Peux-tu poster l'ordre SQL ?
Quelle version OS ?

[L6N2000]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
SELECT                                            
  M6PGAML1.RTOOL, routng.ITNBR,                                 
  m6pgamL1.WKCTR,M6PGAML1.STPGM, M6PGAML1.USPGM                 
FROM M6PGAML1                                                   
LEFT OUTER JOIN   routng                                        
on                                                              
      M6PGAML1.RTOOL = routng.RTOOL  and m6pgaml1.wkctr=        
        routng.wkctr                                            
WHERE                                                           
  M6PGAML1.RTOOL='1515'

en V5R3

[K2R400]

que sont M6PGAML1 et routng ?
Des Logiques, des vues , des tables ?

Avec L1 derrière, j'ai la vague impression que c'est un LF fait en DDS non ?

[L6N2000]

M6PGAMl1 est un fichier Logique avec DDS et ROUTNG est un fichier physique indexé

[K2R400]

OK, première règle, jamais de requêtes SQL sur des LF (excepté des vues SQL). En faisant une requête sur un LF tu utilises le vieux moteur CQE !!!!

Donc tu modifies déjà ta requête en donnant le fichier physique.
Attention si ton LF possède des Select/omit, il va falloir enrichir ta clause WHERE.

Maintenant fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WRKOBJ OBJ(*ALL/QAQQINI) OBJTYPE(*FILE)

dis moi combien as-tu de fichiers QAQQINI dans ton système, et dans quelles bibliothèques ?
Si tu en trouve un dans QUSRSYS, sous STRSQL fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
select qqval from qaqqini             
where qqparm = 'IGNORE_DERIVED_INDEX'

qu'as-tu comme valeur ?

[L6N2000]

J'ai 2 fichiers QAQQINI, l'un dans QSYS et l'autre dans QUSRSYS.

après avoir exécuté la requête demandée, je n'ai aucune donnée dans chacun des 2 fichiers.

[L6N2000]

OK, j'ai relancé le SQL uniquement sur les fichiers physique et le logique n'avait pas de sélection, omission.

J'ai 2 fichiers QAQQINI, l'un dans QSYS et l'autre dans QUSRSYS.

après avoir exécuté la requête demandée, je n'ai aucune donnée dans chacun des 2 fichiers.

[K2R400]

OK, normal pour le IGNORE_DERIVED_INDEX j'avais oublié tu étais en V5R3.
As-tu toujours une différence entre STRSQL et ton RPG ?

Au fait, fais de la correlation de noms tu gagneras du temps à écrire tes requêtes. Ex :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT a.RTOOL, b.ITNBR, a.WKCTR,a.STPGM, a.USPGM 
FROM M6PGAMP a LEFT OUTER JOIN routng b
on  a.RTOOL = b.RTOOL 
and a.wkctr= b.wkctr 
WHERE a.RTOOL='1515'

Le résultat attendu est en SQL : 3 enregistrements issus du fichier maître qui n'ont pas de correspondance dans le fichier JOIN et un enregistrement qui a des données des 2 fichiers

Le LEFT OUTER JOIN ne te ramènera que les enregistrements du fichier de gauche n'ayant pas de correspondance dans le fichier de droite.
Donc le b.ITNBR me paraît inutile il aura tout le temps la valeur NULL

[L6N2000]

Oui, j'ai toujours une différence : le résultat du SQL est celui que j'attends, en revanche, le résultat du SQLRPG n'est pas le même et n'est pas celui que j'attends.

Pourquoi ?

[K2R400]

Tu dois surement avoir un OVRDBF quelque part ou une LIBL différente. Tu ne pointes pas sur le même fichier.
Vérifie ce point avant tout.

[L6N2000]

Merci pour tes conseils, j'ai trouvé la solution :

SELECT a.RTOOL, value(b.ITNBR,' '), a.WKCTR,a.STPGM, a.USPGM

FROM M6PGAMp a

LEFT OUTER JOIN routng b on a.RTOOL = b.RTOOL and a.wkctr= b.wkctr

WHERE a.RTOOL='1515'

Il fallait mettre un "value" pour initialiser les zones quand elles n'existent pas dans le 2nd fichier.

cela fonctionne sur SQL et de la même manière en SQLRPG.

[K2R400]

Comme je te l'ai déjà dis, VALUE ou pas (ou ses synonyes IFNULL et COALESCE), le champ b.ITNBR sera toujours NULL car il s'agit d'un LEFT OUTER JOIN.
Donc cette requête fonctionnera pareil :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT a.RTOOL, ' ', a.WKCTR,a.STPGM, a.USPGM 
FROM M6PGAMp a 
LEFT OUTER JOIN routng b on a.RTOOL = b.RTOOL and a.wkctr= b.wkctr 
WHERE a.RTOOL='1515'

Pourquoi compliquer les choses !!!!

[Mercure]

Le LEFT OUTER JOIN ne te ramènera que les enregistrements du fichier de gauche n'ayant pas de correspondance dans le fichier de droite.
Donc le b.ITNBR me paraît inutile il aura tout le temps la valeur NULL

Non, je crois que tu te trompes. L'opérateur LEFT JOIN (ou LEFT OUTER JOIN) renvoie en effet les colonnes sélectionnées de la table de gauche (left) mais aussi les colonnes sélectionnées de la table de droite qui sont en correspondance sur le "JOIN". Les colonnes de la table de droite étant sans correspondance prendront le cas échéant la valeur "NULL" ( symbolisée par un tiret sur les écrans verts).

Il fallait mettre un "value" pour initialiser les zones quand elles n'existent pas dans le 2nd fichier.

Ce n'est pas pour cette raison que le nombre de lignes était différent. C'était différent parce que ton programme SQLRPG n'acceptait pas les "NULL". Cela marche maintenant parce que avec la fonction VALUE() tu as substitué un blanc à la place de NULL . Du coup, il n'y a plus de valeur NULL et ton programme fonctionne correctement.
Le compilateur RPG III est incapable de supporter les valeurs NULL. Donc, si ton programme est écrit en RPG III comme je le supposemalheureusement, employer la fonction VALUE() (ou mieux : COALESCE() car portable sur d'autres OS et fonction ANSI) est en effet la solution. Si en revanche c'est du RPG IV, tu peux laisser les valeurs NULL dans ta requête mais ajouter un indicateur sur chaque zone "fetchée" susceptible d'avoir la valeur NULL.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

EXEC SQL FETCH C1 INTO   :RTOOL, :ITNBR :I_ITNBR, :WKCTR, ...

Dans cet exemple tiré de ta requête, la colonne ITNBR peut contenir la valeur NULL. Le cas échéant, la variable "indicateur" (que j'ai appelée ici I_ITNBR) prendra la valeur -1. Si la colonne ITNBR n'est pas nulle, la valeur de l'indicateur sera égale à zéro. Du coup, on peut tester si la colonne récupérée est NULL ou pas en testant l'indicateur dans le programme.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
IF I_ITNBR < 0;   // La colonne ITNBR vaut NULL
  ...

Chaque indicateur doit être défini comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

d I_ITNBR         s              5i 0

NB. Tu noteras enfin que ITNBR et I_ITNBR ne sont PAS séparés par une virgule. Cette méthode d'écriture permet à SQL de faire l'association colonne-indicateur.

[K2R400]

Philippe,

depuis le début j'ai en tête un LEFT EXCEPTION JOIN pour te dire si je plane complet un vendredi. Au temps pour moi.

[L6N2000]

Merci pour cette explication très claire