> Tech > Trouver les erreurs des données numériques avec SQL

Trouver les erreurs des données numériques avec SQL

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

SQL permet d'identifier les données erronées avant que le système ne se crashe, et cela sans programmes personnalisés La présence de données erronées dans un fichier peut provoquer des problèmes quels que soient le programme, la requête ou l'instruction SQL tentant d'accéder aux données du champ. Lorsqu'un programme rencontre des données erronées, il génère le fameux message d'erreur “MCH1202 Erreur dans une donnée décimale” et parfois des messages différents (tels que CPF5035, RPG0907, QRY5053 ou encore SQL0802), selon le type de détection d'erreurs interne effectué. Les langages Query et SQL peuvent néanmoins afficher ou imprimer des caractères de substitution à  la place des données erronées, mais ils ne mettront pas à  jour ni n'inséreront d'enregistrementdans un fichier contenant des données erronées.

La présence de données erronées dans un champ numérique peut également influer sur les enregistrements contenant des données correctes. C'est le cas lorsqu'un champ contenant des données erronées fait partie d'une jointure avec un autre fichier et que le moteur de recherche doit créer un chemin d'accès. De plus, les enregistrements erronés sont souvent difficiles à  localiser, et il n'existe pas de méthode évidente pour les débusquer et vérifier qu'il n'en reste plus dans la base de données.

Fort heureusement, SQL propose des méthodes pour aider à  localiser les données erronées sans écrire de programmes personnalisés ni laisser le système les détecter en s'arrêtant brutalement. Ces méthodes bénéficient du fait que l'OS/400 ne considère les données numériques comme valides que lorsque certains octets occupent certaines positions dans un champ.

Trouver les erreurs des données numériques avec SQL

Avant tout, intéressez-vous aux champs décimaux “condensés” (ou “ packés ”), qui
compriment deux chiffres dans chaque octet. On se souviendra qu’un octet, qui
contient huit bits et peut représenter un nombre entre 0 et 255, est représenté
en hexadécimal par deux chiffres hexadécimaux, pouvant correspondre chacun à  un
caractère entre 0 et 9 ou A et F. Les champs décimaux condensés stockent un chiffre
décimal dans l’emplacement correspondant à  chaque chiffre hexadécimal. Par exemple,
lorsqu’il est stocké dans un champ en (7,0) au format décimal condensé, le nombre
123 apparaît comme

00 00 12 3F

Notez que le nombre n’utilise que quatre octets car il y a deux chiffres par octet.
Dans le dernier octet, le chiffre de droite contient une valeur qui représente
le signe du nombre. A, C, E ou F à  cet endroit indiquent que le nombre est positif
; B ou D indiquent qu’il est négatif (dans notre cas, 123 représentant une valeur
positive, on trouve F). Tous les nombres décimaux condensés valides respectent
ce schéma : une lettre de A à  F dans le demi-octet à  l’extrême droite, et les
chiffres de 0 à  9 pour tous les autres emplacements.

La fonction SQL HEX permet d’identifier les enregistrements contenant des données
qui ne respectent pas ce schéma. HEX renvoie une chaîne de caractères contenant
la représentation hexadécimale d’un opérande (l’opérande peut représenter un champ,
un nombre, une chaîne de caractères ou une expression.) Cette chaîne de caractères
est toujours composée de 16 chiffres hexadécimaux, à  l’exclusion de tout autre
caractère. Une fois que l’on obtient cette chaîne de caractères hexadécimale,
on peut utiliser les fonctionnalités de conversion et de vérification de chaînes
de SQL pour garantir que la chaîne répond aux normes des données condensées valides.

TRANSLATE permet de spécifier une série de caractères devant être remplacés
par d’autres

La figure 1 présente une requête testant le champ Field1 du fichier File1
à  la recherche de données erronées, affichant aussi bien la valeur hexadécimale
des données erronées que le rang relatif d’enregistrement de l’enregistrement
qui les contient. Voyons comment fonctionne cette recherche.

La fonction SQL TRANSLATE permet de spécifier une série de caractères devant être
remplacés par d’autres caractères. Chaque nombre (entre 0 et 9) peut correspondre
à  un caractère de substitution et chaque lettre (entre A et F) à  un autre. Dans
la figure 1, la fonction TRANSLATE traduit chaque chiffre en # et chaque caractère
en @.

Le prédicat SQL LIKE est semblable au prédicat EQUAL (=), sauf qu’il permet de
comparer une valeur (dans le cas présent, le résultat de la fonction TRANSLATE)
à  un jeu de caractères qui ont une signification spéciale dans une chaîne de caractères.
Le signe % représente tout ensemble de zéro ou plus de caractères, et un souligné
(_) représente n’importe quel caractère autre. Par exemple, si un champ caractères
(STR) contient la chaîne de caractères ‘ABCD’, alors l’instruction STR LIKE ‘%D’
est vrai. De la même façon, STR LIKE ‘%ABCD’ est également vrai car % peut même
représenter zéro caractères. En revanche, STR LIKE ‘A%Z’ est faux car STR ne contient
aucun Z. STR LIKE A_BCD’ est également
faux car le _ remplace exactement un caractère.

Etant donné que le seul caractère non numérique devant apparaître dans la chaîne
de caractères hexadécimale d’un nombre condensé est une lettre entre A et F sur
la droite, toute autre instance de @ dans la chaîne de caractères traduite dans
figure 1 indique que la chaîne de caractères contient des données erronées. C’est
pour cela que deux tests sont indispensables dans la clause WHERE : le premier
teste la présence d’un caractère entre A et F à  la fin, et le second vérifie que
c’est bien le seul endroit dans la chaîne où une lettre apparaît.

Téléchargez gratuitement cette ressource

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Tech - Par iTPro.fr - Publié le 24 juin 2010