> Tech > Quelques canevas SQL pour programmeurs RPG

Quelques canevas SQL pour programmeurs RPG

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

par Paul Conte
Voici quatre techniques pour répondre simplement à  la plupart des exigences des applications de gestion oilà  plusieurs années qu'IBM a rejoint le reste du secteur informatique en adoptant SQL comme langage stratégique pour accéder à  la base de données. SQL est intéressant à  double titre pour les applications AS/400 : il garantit une plus grande fonctionnalité et davantage de portabilité. Si on utilise Java et JDBC (Java Database Connectivity) pour les applications Web ou pour Windows, et ODBC pour les applications PC clientes, on n'a pas le choix : JDBC et ODBC exigent tous deux SQL comme langage d'accès base de données. Pour les programmeurs RPG souhaitant utiliser SQL, l'une des premières choses à  apprendre est la technique de codage SQL équivalant aux opérations RPG communes. Ils trouveront dans cet article des canevas pour les quatre techniques SQL les plus fréquemment utilisées.

Quelques canevas SQL pour programmeurs RPG

En RPG, il faut coder une carte F indiquant un accès par clé, puis utiliser un
code opération Chain spécifiant une valeur de clé unique ou une KList pour une
clé comprenant une ou plusieurs zones. La figure 1a montre des exemples d’instructions
pour déclarer un fichier et sa structure de données associée, ouvrir le fichier,
lire un enregistrement et fermer le fichier. (En RPG il n’est pas indispensable
d’ouvrir explicitement un fichier, mais cela permet de mieux contrôler le traitement
des erreurs). Cette figure montre aussi comment contrôler l’état des opérations
Open, Chain et Close avec les fonctions intégrées de RPG IV.

Avant d’exécuter l’opération Chain, le programme doit donner à  la/aux zone(s)
de KList (dans notre exemple, la zone unique SlcMasterId field) la/les valeur(s)
de clés désirées. (Dans cet exemple et dans les suivants, j’ai simplifié le code
pour des raisons liées à  la publication, en n’employant pas de sous-programmes
ou de procédures pour chaque opération d’I/O, pratique que je recommande pour
le code de production). SQL offre le choix entre deux techniques pour lire un
enregistrement spécifique : une instruction Select Into ou un curseurSQL offre
le choix entre deux techniques pour lire un enregistrement spécifique (une ligne
en langage SQL) : une instruction Select Into ou un curseur. La figure 1b montre
une instruction Select Into et le code de vérification d’état associé. J’ai utilisé
une extension SQL/400 qui permet de spécifier la structure d’un enregistrement
hôte (c’est-à -dire, MasterRcd) comme cible de l’instruction Select Into. En SQL
standard, il faut définir une liste de variables hôtes (au lieu d’une structure
d’enregistrement) à  la suite du mot-clé Into. (Pour en savoir plus sur l’utilisation
des structures d’enregistrements hôtes, voir l’article  » Une approche pas à  pas
des structures hôtes de SQL/400 « , NEWSMAGAZINE, octobre 1997.)

Avec cette technique il est essentiel de spécifier la condition de recherche de
la clause Where, pour qu’elle ne renvoie que l’enregistrement dont la zone de
clé primaire (c’est-à -dire, MasterId) a une valeur correspondant à  la valeur spécifiée
dans la variable hôte SlcMasterId. Avant d’exécuter l’instruction Select Into,
il faudra attribuer la valeur de clé désirée à  SlcMasterId avec Eval ou un autre
code opération RPG. Comme on peut le remarquer, SlcMasterId est une zone RPG ordinaire,
mais il faut la faire précéder du préfixe deux points (:), lorsqu’on l’utilise
comme variable hôte dans une instruction SQL. Il ne faut pas oublier que cette
technique s’utilise seulement pour l’extraction d’un enregistrement par clé unique.
SQL renvoie une erreur si la condition de la clause Where d’une instruction Select
Into est satisfaite par plus d’un enregistrement.

Lorsqu’on utilise une instruction Select Into, SQL ouvre automatiquement le fichier
(la table en terminologie SQL). Il n’y a pas d’opérations Open (ou Close) explicites
à  coder. SQL gère l’ODP (open data path) du fichier de manière transparente, de
sorte que l’exécution répétée d’une instruction Select Into avec différentes valeurs
de clés primaires repositionne le pointeur d’enregistrement interne de l’ODP,
au lieu de rouvrir et de fermer le fichier à  chaque exécution de l’instruction.
(Pour en savoir plus sur les performances de Select Into et d’autres opérations
SQL et RPG, voir l’article  » Tirez la quintessence de votre base de données grâce
à  RPG & SQL ! « , dans ce même dossier).

Il faut toujours vérifier l’état d’achèvement de chaque instruction SQL exécutéeIl
faut toujours vérifier l’état d’achèvement de chaque instruction SQL exécutée,
comme je l’ai fait sur la figure 1b. Je préconise d’utiliser la variable SqlStt
générée par le système pour contrôler la valeur de l’état SQL. Les valeurs renvoyées
dans ce code de cinq octets sont standards pour tous les systèmes SQL (contrairement
à  celles renvoyées pour la variable SqlCod générée par le système) et donnent
une indication détaillée de ce qui s’est passé lors de l’exécution de l’instruction
SQL. J’ai utilisé un test très basique de trois conditions : succès, aucun enregistrement
trouvé ou autre état (qui est traité comme une erreur). Mais il peut y avoir d’autres
avertissements et erreurs individuels à  traiter spécifiquement en testant d’autres
codes. Les codes sont listés dans l’Appendice D du manuel DB2 for AS/400 SQL Programming,
V4R4 (SC41- 5611).

La figure 1c montre l’autre technique SQL utilisée pour lire un enregistrement
sur clé. Cette approche consiste à  déclarer un curseur, c’est-à -dire à  peu près
l’équivalent d’une carte F RPG utilisée conjointement avec une commande OpnQryF
(Open Query File). Pour chaque enregistrement à  extraire, il faut ouvrir le curseur,
exécuter une instruction Fetch pour lire l’enregistrement, et fermer le curseur.
Comme pour l’instruction Select Into, le runtime SQL n’ouvre pas et ne ferme pas
réellement le fichier pour chaque paire d’instructions SQL Open et Close, mais
se contente de repositionner le pointeur de fichier de l’ODP.

Le curseur SQL utilise une clause Where identique à  celle utilisée avec une instruction
Select Into. A chaque ouverture du curseur, la clause Where est évaluée pour déterminer
les enregistrements (dans ce cas, un seul enregistrement) accessibles par le biais
du curseur. Il vaut toujours mieux spécifier la clause For Fetch Only lorsqu’il
s’agit seulement de lire des enregistrements grâce à  un curseur. Cela permet une
optimisation maximale de l’instruction et évite d’inutiles verrous d’enregistrements.

Figure 1a Code RPG IV pour lire un enregistrement
sur clé

* File declaration

FMaster IF E K DISK InfDs( MstInfDs )
F UsrOpn

* File information data structure

D MstInfDs DS
D MstFileName *File
D MstOpcode *Opcode
D MstRrn 397 400I 0

* Field that contains desired integer key value

D SlcMasterId S 9B 0
.
.
.
* Open file and check status

C Open (E) Master

C If %Error
C ExSr MasterIOErr
C EndIf
.
.
.
* Key list

C SlcKey KList
C KFld SlcMasterId
.
.
.
* Chain to the record and check status

C SlcKey Chain (E) Master

C Select
C When %Error
C ExSr MasterIOErr
C When Not %Found( Master )
C ExSr MasterNotFound
C Other
C ExSr MasterFound
C EndSl
.
.
.
* Close file and check status

C Close (E) Master

C If %Error
C ExSr MasterIOErr
C EndIf

Figure 1b Code SQL/400 pour lire un enregistrement sur clé code via une
instruction Select Into

* Mnemonics for SQL status values

D SqlStateOk C Const( '00000' )
D SqlStateNoRow C Const( '02000' )

* Host variable that contains desired integer key value

D SlcMasterId S 9B 0

* Host record structure declaration

D MasterRcd E DS ExtName( Master )
.
.
.
* Retrieve the record and check status

C/Exec SQL
C+ Select *
C+ Into :MasterRcd
C+ From Master
C+ Where MasterId = :SlcMasterId
C/End-Exec

C Select
C When SqlStt = SqlStateOk
C ExSr MasterFound
C When SqlStt = SqlStateNoRow
C ExSr MasterNotFound
C Other
C ExSr MasterSqlErr
C EndSl

Figure 1c Code SQL/400 pour lire un enregistrement sur clé code avec un
curseur

* Mnemonics for logical variables

D True C Const( '1' )
D False C Const( '0' )

* Mnemonics for SQL status values

D SqlStateOk C Const( '00000' )
D SqlStateNoRow C Const( '02000' )

* Host variable that contains desired integer key value

D SlcMasterId S 9B 0

* Field used to indicate whether cursor is open

D MasterOpen S 1A Inz( False )

* Host record structure declaration

D MasterRcd E DS ExtName( Master )
.
.
.
* Declare the cursor (this statement is not executable)

C/Exec SQL
C+
C+ Declare MasterTable Cursor
C+ For Select *
C+ From Master
C+ Where MasterId = :SlcMasterId
C+ For Fetch Only
C/End-Exec
.
.
.
* == The following statements are repeated for each ==
* == record that's retrieved. ==

* Open the cursor and check status

C/Exec SQL
C+ Open MasterTable
C/End-Exec
C If SqlStt = SqlStateOk
C Eval MasterOpen = True
C Else
C Eval MasterOpen = False
C ExSr MasterSqlErr
C EndIf

* Retrieve the record and check status

C If MasterOpen = True
C/Exec SQL
C+ Fetch Next
C+ From MasterTable
C+ Into :MasterRcd
C/End-Exec
C Select
C When SqlStt = SqlStateOk
C ExSr MasterFound
C When SqlStt = SqlStateNoRow
C ExSr MasterNotFound
C Other
C ExSr MasterSqlErr
C EndSl
C EndIf

* Close the cursor and check status
* Set cursor open status to False even if error on Close

C If MasterOpen = True
C Eval MasterOpen = False
C/Exec SQL
C+ Close MasterTable
C/End-Exec
C If SqlStt <> SqlStateOk
C ExSr MasterSqlErr
C EndIf
C EndIf

Téléchargez gratuitement cette ressource

Comment sécuriser la Digital Workplace ?

Comment sécuriser la Digital Workplace ?

Avec le recours généralisé au télétravail, les entreprises ont ouvert davantage leur SI. En dépit des précautions prises, elles ont mécaniquement élargi leur surface d’exposition aux risques. Découvrez 5 axes à ne pas négliger dans ce Top 5 Sécurité du Télétravail.

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