Erreur dans une donnée décimale (ENORME)

RPG (3 et 4, free), CL, SQL, etc...
Répondre
cimmelé
Messages : 34
Enregistré le : mer. 28 mars 2007, 21:57:59
Localisation : Rennes(35)
Contact :

Erreur dans une donnée décimale (ENORME)

Message par cimmelé »

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
Modifié en dernier par cimmelé le lun. 06 avr. 2009, 17:58:03, modifié 1 fois.

cmasse
Site Admin
Messages : 813
Enregistré le : mer. 14 févr. 2007, 18:00:03
Localisation : Nantes
Contact :

plus d'infos, SVP.

Message par cmasse »

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.
Christian Massé (Volubis.fr)

cimmelé
Messages : 34
Enregistré le : mer. 28 mars 2007, 21:57:59
Localisation : Rennes(35)
Contact :

(sans texte)

Message par cimmelé »

:?

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 !

cmasse
Site Admin
Messages : 813
Enregistré le : mer. 14 févr. 2007, 18:00:03
Localisation : Nantes
Contact :

réponse à zéro

Message par cmasse »

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...
Christian Massé (Volubis.fr)

cimmelé
Messages : 34
Enregistré le : mer. 28 mars 2007, 21:57:59
Localisation : Rennes(35)
Contact :

(sans texte)

Message par cimmelé »

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

cimmelé
Messages : 34
Enregistré le : mer. 28 mars 2007, 21:57:59
Localisation : Rennes(35)
Contact :

(sans texte)

Message par cimmelé »

:oops:

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

Philippe
Messages : 4
Enregistré le : jeu. 26 mars 2009, 11:39:17
Localisation : Région parisienne
Contact :

(sans texte)

Message par Philippe »

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.

Répondre