Par Paul Conte - Mis en ligne le 17/09/2003
1àˆRE PARTIE : PRINCIPES DE BASE
Un guide essentiel pour blinder le coding du langage de procédure SQLLe langage de procédure SQL (SPL,
SQL Procedural Language) est un langage
IBM et standard permettant
d'écrire des procédures stockées, des
UDF (user-defined functions) et des
triggers. Pour écrire du code SQL dans
le but d'accéder à la base de données
iSeries, SPL est généralement plus
simple que les HLL (high-level languages).
De plus, SPL bénéficie de
fonctions très intéressantes pour des
procédures stockées, des UDF et des
triggers qui ne contiennent pas de
code base de données. En revanche, un
HLL, comme RPG ILE, est souvent préférable
lorsque la procédure stockée,
l'UDF ou le trigger est vaste ou complexe.
Avant la V5R2, SPL souffrait, entre
autres, d'un mécanisme de traitement
d'erreurs peu maniable. Avant la V5R2,
écrire du code SPL sûr était si compliqué
que la plupart des développeurs se
contentaient d'une protection partielle
pour leurs routines et… croisaient les
doigts. Avec la V5R2, IBM permet des
instructions composées imbriquées
qui permettent enfin de protéger entièrement
les routines SPL.
Cependant, les règles de traitement
d'erreurs SPL restent baroques et il est
presque impossible de les déchiffrer
sans beaucoup d'expérimentation par
essais et erreurs successifs. Ou sans un
guide, comme cette série de deux articles.
Dans cette première partie, j'explique
comment fonctionne le traitement
d'erreurs SPL et je suggère
plusieurs « meilleures pratiques » pour
coder un SPL bien protégé. Dans la seconde
partie, je présenterai un
exemple complet d'une procédure
stockée SPL qui illustre un traitement
d'erreurs efficace. Cette série suppose
Traitement des erreurs spl V5R2
Une routine SPL est constituée d’une
suite d’instructions SQL. Ce peut être
des instructions de définition de données
et de manipulation de données
SQL, comme Create Table ou Update.
Une routine SPL peut aussi inclure
certaines des instructions de contrôle
listées figure 1. La plupart de ces
instructions fournissent la faculté de
« programmation » de SPL. L’instruction
Set, par exemple, permet d’attribuer
des valeurs à des variables et des
paramètres ; les instructions If et Case
gèrent le branchement conditionnel ;
et les instructions For, Loop, Repeat et
While gèrent les boucles d’exécution.
Quant à Get Diagnostics, Resignal et
Signal, ce sont les instructions de traitement
d’erreurs SQL que je couvre
dans cet article.
Une instruction composée SPL
permet de placer des instructions multiples
entre des délimiteurs Begin et
End. En V5R1 et avant, une instruction
composée ne pouvait pas en contenir
une autre. Un handler (expliqué ci-dessous)
ne pouvait pas non plus contenir
une instruction composée. En V5R2,
ces restrictions n’existent plus et on
peut désormais coder des instructions
composées imbriquées, même dans
un handler. C’est cette possibilité qui
permet un traitement d’erreurs SPL efficace.
Outre des instructions SQL multiples,
une instruction composée peut
contenir plusieurs types de déclarations,
comme on le voit figure 2. On
peut déclarer des variables à utiliser
dans des calculs et des instructions
conditionnelles à l’intérieur d’une routine
SPL, de la même manière qu’on
déclare et utilise des variables de programme
HLL. Les déclarations de curseur
sont semblables aux déclarations
de curseur SQL imbriquées dans les
HLL et elles permettent un accès ligne
à ligne aux tables de base de données
en utilisant une instruction Fetch ou
une forme de boucle For propre à SPL.
Les déclarations de conditions et de
handler sont deux éléments supplémentaires
qui jouent un rôle important
dans le traitement d’erreurs SPL,
comme je l’explique ci-après.
Il faut bien comprendre que toute
déclaration, quel que soit son type,
n’est visible que dans la même instruction
composée qui contient la déclaration
et toutes les instructions composées
imbriquées dans l’instruction
composée contenante. La plupart des
HLL structurés par blocs traitent
d’ailleurs la visibilité de cette même façon.
En raison de cette similarité, j’utilise
le terme « bloc » comme raccourci
de « instruction composée » pour la
plupart des explications de la suite de
cet article.
Téléchargez cette ressource

Sécuriser votre système d’impression
Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- L’Intelligence Artificielle, le nouveau copilote du CRM : une révolution incontournable
- Optimiser la gestion de la relation client dans le secteur des sciences de la vie
- 2025, un « âge de raison » pour l’écosystème de la technologie ?
- 59 % des entreprises françaises victimes de ransomwares ont stoppé leurs opérations !
- KeeeX accélère son développement en Europe en 2025 !
