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
|
Téléchargez cette ressource
Guide inmac wstore pour l’équipement IT de l’entreprise
Découvrez les dernières tendances et solutions IT autour des univers de Poste de travail, Affichage et Collaboration, Impression et Infrastructure, et notre dossier Green IT sur les actions engagés par inmac wstore pour réduire son impact environnemental