le forum IBM i

Bonjour,

Est ce que quelqu'un peut m'aider sur le problème suivant :



Stockage du résultat d'un count(*) dans un programme de service avec le prototype et les variables suivantes

DRtvLigneBP pi 4 0
D pNoBP 8a

D àLigneTotal s 4 0

select
count(*) into :àLigneTotal
from
bpdetl1
where
bdbon = :pNoBP ;


Je rencontre une erreur lorque la fonction retourne la valeur au programme appelant où la variable est décrite :

D àNbrLTotn s 4 0

idem si dec( count(*), 4, 0) est utilisé

Merci d'avance pour votre solution

Christophe

merci d'indiquer le code erreur. SQL ou RPG ?

quel est le pgm qui "plante" , l'appelant ou la fonction appelée ?



merci de ces quelques infos en plus.

La problématique a changé, j'ai résolu mon problème en passant toutes les variables du programme appelant et de la fonction en Condensé.

Le programme appelant étant en fait une procédure cataloguée, je me heurte maintenant (et depuis le début) au fait que le contenu de la colonne Résultat obtenue dans le requêteur SQL est systématiquement 0.

Sauf si je viens forcer ce contenu avec une constante numérique !

J'y perds tout ce qu'il me reste de latin !

Alors ca veut dire que le SELECT SQL n'a pas marché ( rappel SQL dans le RPG ne plante JAMAIS !!!, il renseigne SQLCODE).


plusieurs pistes :

1/ debug (avec WDS Client et les points d'entrée de service c'est un plaisir)

2/ mettre SQLcode dans la zone résultat pour affichage (peut être *LIBL n'est pas correct, ou bien absence de droits, etc...)



bon courage...

une dernière précision :

Je vois en debug sur le programme RPG les variables de la DS alimentées ! et pas sur Squirrel, ni sur Navigator...

SOLUTION (après ces échanges + 1 téléphone )

C'était forcément ENORME !

Ainsi va la vie et les changements dans nos environnements de travail, où en 5250 on a toujours une liste de bibliothèques valide pour tester ou debugger...

Dans un contexte requêteur (Squirrel, Navigator) si on omet de qualifier un fichier avec sa bibliothèque (à cause d'un environnement multi-société par exemple), le select en erreur n'interrompt pas la fonction et
ON-NE-VOIT-RIEN

(sans compter sur notre propension toute naturelle à focaliser sur un problème qui n'en est pas un !)

D'ou la super idée de Christian de stocker la valeur de SQLCODE dans un paramètre à retourner au programme appelant, ce qui doit permettre de tracer ce type d'anomalie d'une manière ou d'une autre (message à QSYSOPR, retourner la valeur dans une colonne résultat de la procédure cataloguée = tout ce qui est différent de 0).

Un grand Merci donc à Christian et un poil de rigolade pour ceux qui auront la patience de lire cet épisode du forum jusqu'au bout ...

Et puis, également, toujours initaliser le compteur AVANT chaque requête de comptage et gérer le code statut (SQLCOD ou mieux encore SQLSTT) en retour APRES exécution de la requête SQL. On évite ainsi les plantages consécutifs à ce genre de pb.