SQL dans RPGLE : erreur de données décimales

[Lisogane]

Bonjour
J'ai besoin de l'aide.
voici mon code:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
D grn s 15 0 
C *Entry plist 
C parm usrname 8 
C parm ntrf£ 9 0
C parm whs£ 4 
C/EXEC SQL 
C+ DECLARE C1 CURSOR FOR 
C+ SELECT max(t1grn£) 
C+ FROM MABIB/MONFICH WHERE t1trf£= :ntrf£ 
C/END-EXEC 
 
C/EXEC SQL 
C+ OPEN C1 
C/END-EXEC 
 
C if SQLSTT='00000' 
 
C/EXEC SQL 
C+ FETCH C1 
C+ INTO :grn 
C/END-EXEC 
 
C endif

...................................
L'execution m'envoie le message d'erreur suivant: ERREUR DE DONNEES DECIMALES

[m4k-Hurrican]

As tu déboguer ta variable ntrf£ ?
A tous les coups elle est mal passée.

[K2R400]

Et puis il y a aucun intérêt à utiliser un curseur quand on ne renvoie qu'une seule ligne. Faire plutôt :

Code :

1
2
Exec SQL SELECT max(t1grn£) INTO :grn 
         FROM MABIB/MONFICH WHERE t1trf£= :ntrf£

Le DECLARE cursor, l'OPEN et le CLOSE deviennent inutiles

[POKOU]

Bonjour
penses à monitorer ta zone dans le FETCH avec un indicateur, pour qu'elle te renvoie 0 quand elle est à null.

Code :

1
2
3
4
5
6
7
8
9
D L_ResNull1      S              2B 0
...
     C/EXEC SQL
     C+ FETCH NEXT FROM C1 INTO :L_IDENCONC,:L_IDBENEFI:L_RESNULL1,
     C+                         :L_DTEVTREE
     C/END-EXEC      
...    
C                   IF        L_idbenefi = 0                               >2

à+

[Mercure]

Quitte à définir des variables binaires, autant le faire correctement. En RPG, le " B " n'a jamais défini vraiment correctement une zone binaire car elle se limite au nombre de chiffres déclarés.

Par exemple, si en RPG une variable est définie en "4B 0", elle ne pourra jamais contenir qu'un entier de 2 octets binaires qui ne peut contenir que 4 chiffres. Un entier binaire de 4 octets peut stocker des valeurs allant de -2147483648 à +2147483647.

Une zone "2B 0" en RPG est certes un entier binaire de 2 octets mais ne peut stocker que des valeurs allant de -9999 à +9999.

C'est pour cette raison que vous ne devriez plus du tout utiliser le type de donnée " B " en RPG IV. Le type de donnée correct pour une zone "BINARY(2)" est "5I 0" et le type de donnée correct pour une zone "BINARY(2) UNSIGNED" est "5U 0". Pour "BINARY(4)", déclarer alors respectivement "10I 0" et "10U 0".

Ah ! Et +1 avec K2R400.

[jump400]

Envoyé par Mercure

Quitte à définir des variables binaires, autant le faire correctement. En RPG, le " B " n'a jamais défini vraiment correctement une zone binaire car elle se limite au nombre de chiffres déclarés.

Par exemple, si en RPG une variable est définie en "4B 0", elle ne pourra jamais contenir qu'un entier de 2 octets binaires qui ne peut contenir que 4 chiffres. Un entier binaire de 4 octets peut stocker des valeurs allant de -2147483648 à +2147483647.

Une zone "2B 0" en RPG est certes un entier binaire de 2 octets mais ne peut stocker que des valeurs allant de -9999 à +9999.

Attention à ne pas confondre le nombre de chiffres (définition par la longueur des zones isolées et sous-zones) et le nombres d'octets (définition par position des sous-zones de DS). La déclaration en spec D permettant les deux (pour les sous-zones de DS), on peut facilement se perdre. Mais comme il est quand même préférable de définir les zones et sous-zones par leur longueur et non leur position, ton exemple est erronée, alors que l'explication du début est correcte ("car elle se limite au nombre de chiffres déclarés").
Une zone en 2B 0 ne peut stocker que des valeurs allant de -99 à +99 bien que le stockage soit sur 2 octets.
Pour les curieux, voici un petit prog rapide à faire pour tester ça.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
                                        
D bin2            s              2B 0   
D bin3            s              3B 0   
D bin4            s              4B 0   
D bin5            s              5B 0   
D bin8            s              8B 0   
                                        
 /free                                  
     *inlr = *on;                       
     For Bin2 = 0 to 9999;            
     endfor;                            
                            
 /End-Free

Quand le prog plantera (si, si, il va planter !) faites un dump pour voir ou la boucle s'est arrétée et la définition des différentes déclaration binaires :

Code :

1
2
3
4
5
6
7
NAME                  ATTRIBUTES           VALUE                        
BIN2                  BIN(2,0)             99.              '0063'X     
BIN3                  BIN(3,0)             000.             '0000'X     
BIN4                  BIN(4,0)             0000.            '0000'X     
BIN5                  BIN(5,0)             00000.           '00000000'X 
BIN8                  BIN(8,0)             00000000.        '00000000'X

On voit bien que Bin2 s'est limité à 99 alors qu'il est construit sur 2 octets ('0063'X).
On remarque au passage, que le Bin(5,0) provoque le passage à 4 octets pour pouvoir stocker des valeurs supérieures à 32767 et inférieures à -32768.

Envoyé par Mercure

C'est pour cette raison que vous ne devriez plus du tout utiliser le type de donnée " B " en RPG IV.

+1 ! il y a 2 ou 3 ans de cela IBM a diffusé des résultats de tests de perfs entre le binaire et l'integer : résultat, le binaire est 100 000 fois plus lent !!!

Envoyé par Mercure

Le type de donnée correct pour une zone "BINARY(2)" est "5I 0" et le type de donnée correct pour une zone "BINARY(2) UNSIGNED" est "5U 0". Pour "BINARY(4)", déclarer alors respectivement "10I 0" et "10U 0".

Les définitions en I ou U contiennent un gros piège. Comme tu l'expliques, le 5U 0 est construit sur 2 octets, mais cela ne veux pas dire que l'on pourra stocker la valeur 99999 !
Il faut se rappeler les cours de CE1 de l'informaticien : 1 octets permet de stocker 256 valeurs différentes, 2 octets permettent de stocker 65536 valeurs différentes (256*256), etc...
Donc un 5U0 est limité aux valeurs allant de 0 à +65535. et le 5I 0 aux valeurs -32768 à +32767 ("perte" d'un bit pour le signe).
Note : Cela fait une grosse incohérence par rapport au Binaire qui gère automatiquement le nombre d'octets utilisés en fonction de la longueur déclarée.
Voici un extrait de la doc IBM sur les valeurs possibles pour les Integer :

Code :

1
2
3
4
5
6
Field length Range of Allowed Values 
3-digit integer -128 to 127 
5-digit integer -32768 to 32767 
10-digit integer -2147483648 to 2147483647 
20-digit integer -9223372036854775808 to 9223372036854775807

et pour les Unsigned integer :

Code :

1
2
3
4
5
Field length Range of Allowed Values 
3-digit unsigned 0 to 255 
5-digit unsigned 0 to 65535 
10-digit unsigned 0 to 4294967295 
20-digit unsigned 0 to 18446744073709551615

Envoyé par Mercure

Ah ! Et +1 avec K2R400.

+1 itou

[Mercure]

Envoyé par Mercure

Une zone "2B 0" en RPG est certes un entier binaire de 2 octets mais ne peut stocker que des valeurs allant de -9999 à +9999.

Dans le but d'illustrer ce que je venais d'écrire au paragraphe précédent, je voulais bien entendu parler d'une zone de "4B 0" et non "2B 0". Désolé pour cette erreur bien involontaire et merci de l'avoir relevée. Je ne suis malheureusement pas à l'abri de l'erreur.