Discussion :

[m4k-Hurrican]

Bonjour,
Me voilà confronté à un bug étrange, et que je n'arrive pas à isoler ni contourner.

Nous avons une table dans laquelle certains champs, pour des raisons d'échanges avec notre site web, sont codés en UTF-8 (CCSID 1208).
Nous ne rencontrons aucun souci au quotidien, sauf avec une requête SQL qui m'arrache les cheveux (ou ce qu'il en reste).
Lorsque nous effectuons une recherche utilisant "Like" et que celle-ci concerne un champ en UTF-8, nous obtenons dans certains cas une erreur SQL0802, avec une erreur de type 7 (division par 0)
Bien entendu, nous n'avons pas de champ numérique, et aucune division dans la requête.

La requête SQL est un peu lourde, donc je la simplifie (elle bugue même simplifiée comme çà) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
With TblOut as (
Select AGREFE as refArt, AGDESI as desArt, AWDESIGN as desArtDoc 
From BiblioGrp.ARTIGR 
Inner join BiblioSoc.ARTICL on ARREFE = AGREFE 
Inner join BiblioGrp.ARTWEB on AWSOCCOD = 'O' and AWREFINT = AGREFE 
) 
Select * From TblOut 
Where 
(RefArt Like '%RADIO%' or upper(DesArt) Like '%RADIO%' or upper(DesArtDoc) Like '%RADIO%') and 
(RefArt Like '%SANS%' or upper(DesArt) Like '%SANS%' or upper(DesArtDoc) Like '%SANS%' )  
Order by RefArt

C'est le champ desArtDoc qui pose souci. Défini CHAR(80) CCSID(1208), il est parfois vide (mais non null).

Quelqu'un a t-il déjà rencontré un cas identique ou proche ? Et si oui, une solution a t'elle été trouvée ?

Je précise de suite, nous n'avons plus de maintenance logicielle, car nous avions prévu un remplacement de la machine au cours du premier semestre. Mais la crise du covid a tout changé, la prochaine machine n'est pas pour demain, et on économise sur tout ce qu'on peut. De toute manière si c'est bel et bien un bug au niveau d'IBM, avant qu'ils ne le fixent et qu'un correctif soit disponible, de l'eau aura coulé.


Edit : Histoire de rajouter dans le bizarre, si je modifie la requête, en retirant un test, par exemple sur DesArt, ou si j'en rajoute un, le plantage ne se fait pas sur le même enregistrement. Un enregistrement parfaitement valide à la requête précédente, devient invalide. C'est à se taper la tête contre les murs.

[larry57]

Bonjour,

Pour les null, il y a une fonction qui utilise COALESCE en SQL :

https://www.ibm.com/support/knowledg..._coalesce.html

Je l'utilise assez souvent.

Larry57.

[m4k-Hurrican]

Bonjour,

Pour les null, il y a une fonction qui utilise COALESCE en SQL :

https://www.ibm.com/support/knowledg..._coalesce.html

Je l'utilise assez souvent.

Larry57.

Perso j'utilise IFNULL qui est identique sauf qu'on ne peut pas avoir une liste de valeurs contrairement à COALESCE.
Sauf que le souci n'est pas là (et j'ai testé avec des IFNULL partout d'ailleurs), nos champs n'autorisant pas les NULL, et on est avec de l'Inner Join, donc pas d'enregs non correspondants.
A priori c'est les Like avec le champ en UTF-8. Si je remplace le champ UTF-8 par n'importe quel autre champ défini en CCSID fichier (1147), çà fonctionne.
J'ai même créé une copie du fichier avec un champ identique mais en CCSID 1147 au lieu de 1208, et çà fonctionne alors. C'est donc bien le CCSID 1208 qui fout la pagaille. Mais comment contourner ce bug, j'ai pas trouvé.

[m4k-Hurrican]

Bon, une bonne nouvelle, j'ai résolu mon problème.
En fait, le champ UTF-8 de certains enregistrements contient des caractères incorrects. Et les fonctions Upper ou Like n'apprécient pas.
Il a fallu que je ruse pour lister tous les enregistrements qui coinçaient (heureusement une petite dizaine seulement), puis que je les corrige.

Reste à savoir comment ces caractères ont pu entrer, même si je pense que c'est à la suite d'un import de catalogue produits (sous format Excel) via l'outil d'import d'iSeries Access.