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
Substitution de fichier automatique dans une requête SQL
Bonjour,
nous avons un soucis avec une requête SQL sur AS/400 : nous faisons la requête sur un fichier physique (avec une clause where), or c'est un fichier logique qui est lu !
Comment empêcher cela et l'obliger à effectuer la requête sur le fichier qu'on lui demande ?
NB : nous avons essayé de faire la requête en mettant un nom de fichier logique , même pb : il va chercher un autre logique selon lui plus adapté à la requête !
Merci de votre aide
Bonjour,
A ma connaissance c'est le système qui choisit le logique qu'il va utiliser. Mais en quoi cela pose-t-il un problème ? Le logique pointe sur les mêmes données que le physique.
En fait cela nous pose un problème car du coup on ne lit pas le bon fichier !
on veut lire le logique1 et on se retrouve à lire le logique2, cela n'a pas de sens.
Nous nous sommes rendu compte du problème sous windev, quand on exécute la requête sql il ne trouve aucun enregistrement (alors que normalement il devrait en trouver), nous avons regardé quels fichiers étaient ouverts au moment de la requête et nous avons constaté qu'il ne pointait pas sur le bon fichier.
Nous avons alors lancé la commande sql directement sur l'as/400 et idem, il ne prend pas le bon fichier ! (par contre sur l'AS/400 il nous affiche 1 enregistrement)
Je pense que le souci vient du fait que les zones du fichier qu'il lit ont été renommées et qu'il ne s'y retrouve pas .... et j'aimerai faire en sorte qu'il prenne en compte le fichier que moi je veux lire et pas un autre ... (si je voulais lire le logique2 je suis assez grande pour l'utiliser directement dans ma requête !)
Nous avons ponctuellement résolu notre problème en supprimant la clause where dans la requête et en la remplaçant par un test dans le programme, mais cela serait beaucoup plus "propre" si on pouvait utiliser la clause where dans la requête sans que cela nous modifie le fichier lu ! (et sans prévenir en plus!)
Comment être sûr du résultat d'une requête SQL si le fichier lu n'est pas celui qu'on veut lire ?
Peut-on modifier ce comportement de SQL ?
Comme l'écrit Darkzinus le moteur SQL choisit le logique qui paraît le plus approprié par rapport à la clause where afin d'optimiser. Qu'il utilise le logique 1 ou le logique 2 n'a aucune importance sauf si un des 2 a des OMIT.Mais dans ce cas je suppose que SQL ne le choisit pas.
Sur AS400 faites la commande DSPBDR nom_fichier et vous verrez tous les logiques qui pointent sur le physique. Ensuite que ce soit le logique 1, 2 ou n ce sont les données du physique qui sont lues donc c'est toujours le même fichier.
Vous pouvez essayer de faire la requête SQL en utilisant le logique 1 par contre de mémoire il me semble que malgré tout les données sont lues dans l'ordre du physique et qu'il vous faudra donc avoir une clause ORDER BY si vous voulez des données triées.
Si côté WinDev cela ne donne pas le bon résultat, c'est peut être la construction de la requête qui a un problème ou bien le driver.
Cela ne sert à rien d'optimiser quelque chose qui ne fonctionne pas.
Mon site : www.emmella.fr
Je recherche le manuel de l'Olivetti Logos 80B.
Bonjour,
Les logiques ont les champs redéfinis ? Et du coup plusieurs logiques sur le même physique ont des champs identiques avec des noms différents ?
Un héritage du 36 ?
Normalement, à part un gros bug dans SQL, je ne vois pas comment le résultat pourrait être différent, en changeant de logique.
La seule différence est dans la vitesse d'exécution, l'optimiseur étant chargé de prendre le chemin à priori le plus rapide (et çà n'est pas toujours le cas, comme je l'ai expérimenté il y a encore peu de temps).
A mon avis il y a un hic dans votre requête SQL.
En plus si vous n'avez pas le même résultat sous Windev et avec STRSQL, il faut se poser des questions. Problème avec le connecteur Easycom ?
On pourrait voir la fameuse requête déjà ?
Bonjour,
Comme le signale m4k-Hurrican, le résultat d'une requête SQL doit être identique quelle que soit l'interface utilisée.
Les différences peuvent généralement s'expliquer par :
- convention de nommage distincte (*SQL / *SYS gère différemment la recherche des tables non qualifiées)
- liste de bibliothèques différentes (cf JOBD attachée au profil ou connectionString)
- des substitutions de fichiers
- l'utilisation d'un fichier QAQQINI différent :ne doit pas provoquer un résultat différent, mais conduire le moteur SQL à utiliser un plan d’exécution différent (cf https://www.ibm.com/support/knowledg...jq/qryoptf.htm)
Dans certains cas plus spécifiques en fonction de l'utilisateur connecté ... (RCAC par exemple).
Il serait intéressant de voir la requête, et si possible son plan dans Visual Explain dans chacune des deux situations
Nathanaël
le seul moyen pour lire un logique et qu'il te donne le mauvais résultat est une copie hasardeuse et qu'il pointe toujours sur l'ancien fichier ...
sinon, comme indiqué le moteur va prendre le plus adapter ou le créer si nécessaire (mais de manière temporaire, prochain IPL il sera supprimer) tu peu aussi le voir dans iseries navigator.
la vie n'est pas cirrhose des foies ...
Avant de poster un message Rechercher n'est pas qu'une option.
FAQ Web - Tuto Web
Ma requête est basique, du style :
SELECT * FROM monfichier WHERE condition1 AND (condition2 OR condition3)
Les zones utilisées dans condition2 et condition3 font partie de la clé de logique2, c'est pourquoi le système le choisi. Mais cela ne me convient pas car logique2 à des zones renommées et je pense que c'est ça qui "perturbe" le HLitPremier de windev.
Il n'est pas question ici de savoir si oui ou non le résultat est différent en prenant tel ou tel logique (dans mon cas la réponse est oui !), mais si c'est possible d'éviter que le système choisisse un autre fichier et comment faire ?
As-tu essayé de faire la requête sur le logique 1 ?
Cela ne sert à rien d'optimiser quelque chose qui ne fonctionne pas.
Mon site : www.emmella.fr
Je recherche le manuel de l'Olivetti Logos 80B.
> Quand tu dis que les résultat son différent. Ce qui t'est retourné par ta requête est bien présent dans ton fichier de destination ou non ??Il n'est pas question ici de savoir si oui ou non le résultat est différent en prenant tel ou tel logique (dans mon cas la réponse est oui !), mais si c'est possible d'éviter que le système choisisse un autre fichier et comment faire ?
> Au lieu d'indiquer le nom de ton fichier dans la requête as tu essayer d'appeler le logique que tu souhaites utiliser directement?
la vie n'est pas cirrhose des foies ...
Avant de poster un message Rechercher n'est pas qu'une option.
FAQ Web - Tuto Web
Tu ne te poses pas la bonne question. Il y a un seul fichier "réel" le fichier physique sur lequel se basent sur les différents logiques. La question est donc pourquoi ton autre logique ne pointe pas sur le bon physique ce qui constitue une situation anormale.Envoyé par SoumaoroKante
C'est pas ça mon problème. Les fichiers logiques pointes sur le même physique, ma requête donne un résultat (cf les posts précédents), le souci c'est que le HLitPremier dans Windev ne le "voit" pas. (NB : le POUR TOUT en revanche trouve bien 1 enregistrement).
Comme je l'ai dit plus haut : en enlevant les condition2 et condition3 de la requete et en les remplacant par un test dans le code cela fonctionne (car il n'utilise plus ce fameux logique2!). Ce qui me fait dire que c'est à cause du renommage des zones du logique...
Donc, avant d'être obligée de reprendre tous les programmes windev faisant appel à des requetes sql (et on en a un paquet !) , j'essaye de trouver une meilleure solution... d'où ma question ...
Oui, il prend systématiquement le logique2
La requête est bonne puisqu'elle donne un résultat, le fichier de destination contient bien un enregistrement lisible via POUR TOUT mais pas via HLitPremier (or dans nos programmes on utilise majotitairement HLitPremier... :/ ) .
Nous n'avons pas de logique qui corresponde à la requête, c'est pourquoi on s'appuie sur le physique. C'est le système qui lit logigue2 car il trouve que certaines zones utilisées dans les conditions font partie de sa clé.
Je ne connais pas Windev, mais je viens de lire que POUR TOUT équivaut à une boucle avec hLitPremier et hLitSuivant. Ce serait pas plutôt le code qui aurait une problème ?
Cela ne sert à rien d'optimiser quelque chose qui ne fonctionne pas.
Mon site : www.emmella.fr
Je recherche le manuel de l'Olivetti Logos 80B.
Si le code avait un pb le POUR TOUT ne fonctionnerait pas non plus ... :/
et si ce n'était lié "qu'au logique" aucun développement ne marcherait étant donné que c'est la base du fonctionnement d'un AS400 sauf si les base sont passé en SQL et non plus en fichier.
Par contre, question bête. En quoi consiste tes tests 2 et 3 qui semble induire des problème sur le logique 2? et quel est le type des champs que tu test ainsi que la valeur?
la vie n'est pas cirrhose des foies ...
Avant de poster un message Rechercher n'est pas qu'une option.
FAQ Web - Tuto Web
Bonjour,
nous avons un soucis avec une requête SQL sur AS/400 : nous faisons la requête sur un fichier physique (avec une clause where), or c'est un fichier logique qui est lu !
Comment empêcher cela et l'obliger à effectuer la requête sur le fichier qu'on lui demande ?
NB : nous avons essayé de faire la requête en mettant un nom de fichier logique , même pb : il va chercher un autre logique selon lui plus adapté à la requête !
Merci de votre aide
Substitution Fichier
Oui il est possible de changer lecture de fichier sur As400 a condition de lancer la commande OVRDBF et les champs a remplir .
pour le cas d'une requête SQL je vous donne un exemple a suivre :
Ceci est un paragraphe d'un CLP .
READ1:
SNDRCVF RCDFMT(FMLE) -----------------------------------------------> Nom de Format a Afficher
CHGVAR VAR(&RMLE) VALUE(&XMLE) -----------------------------------> 1er variable a récupérer
CHGVAR VAR(&RECH) VALUE('MLE = ' *CAT &RMLE) ------------------> 2eme variable a récupérer
SNDPGMMSG MSG('LA VALEUR DE RCHE : ' *CAT &RECH) ------------------> j'affiche la valeur du critère de recherche
OVRDBF FILE(PERSONN) SHARE(*YES) ----------------------------> l'ordre de substitution de fichier suivi de l'option *yes
OPNQRYF FILE((HKAAB1/PERSONN)) QRYSLT(&RECH) +
KEYFLD((MLE)) UNIQUEKEY(1) ----------------------------------> lancement de ma requête conditionné par mon critère de recherche
CALL PGM(HKAAB1/EDT001) ----------------------------------> lancement de mon Prog qui va lire la requête
DLTOVR FILE(PERSONN) ---------------------------------> Suppression de la substitution du fichier
CLOF OPNID(PERSONN) ---------------------------------> la clôture du fichier
GOTO CMDLBL(DEBUT) ---------------------------------> branchement au paragraphe de debut.
j’espère vous avoir donner quelque chose de nouveau .
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager