6 montre combien il est facile de construire une instruction SQL à la volée et de l’exécuter dans un programme RPG. En premier lieu, l’instruction SQL est construite dans une chaîne, et la clause spécifie la clé de tri (A en figure 6). Après quoi vous pouvez préparer cette instruction et ouvrir un curseur (en B). Enfin, vous pouvez atteindre les enregistrements provenant du fichier dans la matrice afin de pouvoir les charger dans le sous-fichier (en C).
Cette méthode ne fonctionnerait pas bien avec un sous-fichier que les utilisateurs peuvent modifier. Si les utilisateurs peuvent entrer les données dans le sous-fichier, toutes les données doivent être resauvegardées sur disque avant de les trier avec SQL, au détriment de la performance.

De plus, IBM doit encore faire le nécessaire pour que le SQL imbriqué fonctionne en RPG en format libre. Comme vous devez sortir du format libre avant de pouvoir coder l’instruction SQL, puis redémarrer le format libre, le coding se complique quelque peu. Dans cet exemple, j’ai résolu ce problème en codant toute la sous-procédure en format fixe.
Cependant c’est un inconvénient indiscutable de l’utilisation du SQL imbriqué.

Cela mis à part, le SQL imbriqué a bien fonctionné dans mes tests. Il a été facile à coder et s’est bien comporté, particulièrement lorsqu’on sait qu’il a dû revenir au disque pour lire les données !
Si vous devez charger les données à partir du disque quand vous les triez, songez à utiliser le SQL imbriqué dans vos programmes. Si les données sont déjà en mémoire, QSORT et SORTA sont préférables.