Résultat différent en SQL et SQLRPG.

Version imprimable

29/10/2009, 22h56
L6N2000

Résultat différent en SQL et SQLRPG.

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
30/10/2009, 08h45
K2R400

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

Code:

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

30/10/2009, 09h20
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 ?
30/10/2009, 09h28
L6N2000

M6PGAMl1 est un fichier Logique avec DDS et ROUTNG est un fichier physique indexé
30/10/2009, 09h40
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:

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:

1 2 select qqval from qaqqini where qqparm = 'IGNORE_DERIVED_INDEX'
qu'as-tu comme valeur ?
30/10/2009, 09h48
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.
30/10/2009, 09h50
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.
30/10/2009, 10h23
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:

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'
Citation:

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
30/10/2009, 10h42
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 ?
30/10/2009, 11h45
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.
30/10/2009, 12h51
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.
30/10/2009, 13h28
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:

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 !!!!
30/10/2009, 13h46
Mercure
Citation:

Envoyé par k2r400

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).

Citation:

Envoyé par L6N200

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:

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:

1 2 IF I_ITNBR < 0; // La colonne ITNBR vaut NULL ...
Chaque indicateur doit être défini comme suit :

Code:

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.
30/10/2009, 14h55
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.
30/10/2009, 15h57
L6N2000

Merci pour cette explication très claire