Portabilité extrême

celui de la conversion des algorithmes
de gestion des erreurs. En V4R5, les nouvelles instructions décrites ci-dessous
améliorent considérablement les fonctions de gestions des erreurs du SPL (et
des UDF SQL) :

· Signal et ReSignal
· Get Diagnostics
· Return

Signal et ReSignal facilitent le traitement des messages de violation
des règles de gestion (par exemple, un numéro de client invalide passé comme
paramètre d’entrée) dans un mode semblable au SQL standard. A l’instar d’une
erreur SQL normale (par exemple, « row not found »), les informations sur l’erreur
précisées par ces instructions se trouvent dans la SQLCA (SQL Communications
Area) de l’application invoquant la procédure cataloguée. Voici comment utiliser
l’instruction Signal pour retourner une erreur correspondant à  un numéro de
client invalide :

If CustNum > 9999 Or CustNum < 0 Then
Signal SqlState ‘NM999’
Set Message_Text =
‘Invalid Customer Number specified’;
End If;

On ne peut spécifier ReSignal que dans un handler SPL car son principal objectif
est de transmettre des informations sur l’erreur ayant provoqué en premier l’appel
du handler . C’est pourquoi, la valeur de l’état ainsi que le texte du message
d’erreur sont facultatifs pour une instruction ReSignal. Pour le reste, la syntaxe
est identique à  celle de l’instruction Signal.
Get Diagnostics est utile car les structures de données ne peuvent pas
être déclarées dans une procédure (ou fonction) SPL. Cela implique que le contenu
de la SQLCA ne peut être accédé directement à  partir d’une procédure cataloguée
SQL. Get Diagnostics dispose d’options permettant de retourner les informations
de type SQLCA suivantes :

· le nombre de lignes affectées (par exemple, SqlErrD(3)) en RPG IV et sqlerrd[2]
en C/C++)
· les informations sur le message d’erreur (par exemple, SqlErL et SqlErM en
RPG IV et Sqlerrmc en C/C++)
Le nombre de lignes affectées permet de déterminer combien de lignes ont été
insérées, mises à  jour ou supprimées par une instruction SQL donnée. La figure
4 montre comment on peut utiliser Get Diagnostics pour vérifier si on peut par
exemple s’octroyer une augmentation de 50%.
Si votre salaire est mis à  jour avec succès, la première instruction Get Diagnostics
renverra 1 et attribuera cette valeur à  la variable locale spécifiée (UpdatedRows).
Dans le cas contraire, elle renverra 0. Si la variable UpdatedRows est égale
à  0, la mise à  jour de votre salaire a échoué. La seconde instruction Get Diagnostics
recherche pourquoi l’instruction Update a échoué. Si le gestionnaire de la base
de données a interdit la mise à  jour, la variable contenant le texte du message
(MsgTxt) est affectée au texte du message de deuxième niveau pour le message
OS/400 associé. Par exemple, si une erreur de typographie dans le numéro de
l’employé n’a pas permis de retrouver le dossier, la variable contenant le texte
du message se voit assigner la valeur du texte du message de deuxième niveau
pour le message SQL0100 : « Row not found for UPDATE ».
Return a été autorisé dans les UDF SQL depuis la V4R4, mais pas dans
les procédures cataloguées SQL. L’instruction Return est habituellement utilisée
dans une procédure cataloguée pour renvoyer un état représenté par un nombre
entier (en d’autres termes, il ne renverra pas un résultat tel qu’une fonction).
La valeur de l’état indique si l’appel a été exécuté avec succès. En règle générale,
une valeur positive indique un succès et une valeur négative indique un échec.
L’appelant accède à  cette valeur en examinant le champ SqlErrD(1) dans la SQLCA
(ou sqlerrd[0] en C/C++) ou en utilisant un pilote ODBC ou JDBC qui accepte
la syntaxe « ? =Call ProcedureName ».
On ne peut utiliser ces nouvelles instructions qu’à  l’intérieur de procédures
et fonctions SQL ; On ne peut pas les intégrer dans un langage évolué. Les nouvelles
instructions sont également disponibles pour les procédures cataloguées SQL
dans les récents groupes de PTF V4R4 consacrés aux bases de données.

IBM a également considérablement amélioré l’interface CLI (Call
Level Interface) SQL de l’AS/400 pour augmenter sa compatibilité avec le standard
ODBC

IBM a également considérablement amélioré l’interface CLI (Call
Level Interface) SQL de l’AS/400 pour augmenter sa compatibilité avec le standard
ODBC. Les applications peuvent par exemple maintenant extraire des données numériques
et les enregistrer dans des variables de type caractères et utiliser ces dernières
pour renseigner des colonnes numériques. Ces améliorations liées à  la compatibilité
facilitent le portage des applications en utilisant des appels ODBC standards
sur l’AS/400. Pour aider davantage les programmeurs qui portent des applications
à  base de CLI entre serveurs DB2 UDB, la page Web IBM sur http://www.ibm.com/as400/developer/porting/cli2.html
compare le support du CLI AS/400 aux autres produits DB2 UDB.
Les autres nouveautés SQL qui améliorent la portabilité des applications incluent
un nouveau type BigInt (Big Integer) pour les nombres entiers composés de 8
octets, les expressions Insert (par exemple, Insert Into X Values(AbsVal(:HostVar),333))
et de nombreuses nouvelles fonctions scalaires SQL. On peut désormais utiliser
Round, Ceiling, Truncate et Sign pour le traitement des valeurs numériques et
Soundex et Difference pour le traitement des chaînes de caractères. Pour de
plus amples informations sur le SPL, consulter l’article « Inside an SQL Stored
Procedure », NEWS/400, juillet 1999.