Avec la généralisation du développement multi-plateformes, de plus en plus d’applications utilisent des bases de données DB2/UDB sur l’iSeries (pour l’intégralité ou une partie de chaque application).

L’iSeries implémente la notion de base de données de façon relativement originale : il n’y a qu’une seule réelle base de données pour l’OS/400 ; la notion de collection correspond uniquement à une vue sélective (par schéma = bibliothèque) de celle-ci.
Ainsi, l’OS a pu concilier la notion de fichier DDS physique (PF), logique (LF) et les rendre également disponibles dans la base de données, en même temps que toutes les tables, vues, etc.

Le méta-langage SQL de description de base de données pour DB2/UDB peut être :
- saisi intégralement sous STRSQL,
- enregistré dans des membres sources et exécuté par RUNSQLSTM,
- constitué avec l’aide de iSeries Navigator,
- récupéré/exécuté depuis des outils de modélisation de base de données,
- …

Il permer de définir les « fichiers » par des types de données, tables, index, vues.
Afin de placer le maximum de règles de gestion au niveau de la base de données, on y définit également :
- des contraintes de clé, de vérification et les contraintes référentielles entre tables,
- des déclencheurs sur les actions d’ajout, modification, suppression (et même lecture) pour les enregistrements de tables (ou au niveau zone),
- des procédures stockées et des fonctions utilisateurs (traitements appelables depuis SQL),
- …

Une particularité de l’iSeries est de permettre que des déclencheurs « systèmes » délèguent leur traitement à des programmes non SQL (RPG, COBOL, etc.). De même, les procédures stockées et les fonctions peuvent aussi servir de protocole d’appel à des programmes natifs (ou des procédures ILE).

L’accès aux données en SQL encapsulé à l’intérieur de programmes natifs (RPG, COBOL, …) est devenu une alternative à l’utilisation des ordres spécifiques à chacun de ces langages pour les accès aux fichiers (fichiers classiques PF-LF ou Tables, vues).
Ceci permet notamment d’utiliser une méthode unique d’accès aux fichiers, partagée par tous les développeurs (qu’ils soient issus de l’AS/400 ou des nouvelles technologies).

SQL est un langage standard. Mais toutefois, il comporte des spécificités pour chaque type de bases de données, qu’il faut éviter d’utiliser si l’on souhaite une portabilité complète vers d’autres plateformes.

Pour les applications comportant du SQL embarqué et/ou des bases de données en DB2/UDB, ARCAD-Skipper permet de :

Fournir des références croisées
- pour les utilisations de fichiers (et leurs zones) par SQL depuis le SQLRPG(LE), SQLCBL(LE), mais aussi depuis des sources IFS (Java, VB, Delphi, …) lorsque ceux-ci accèdent aux bases de données sur l’iSeries via JDBC, ODBC, …
- depuis les déclencheurs de type « système » vers les programmes L3G appelés,
- depuis les procédures stockées ou fonctions « système » vers les programmes L3G appelés,
- entre les tables possédant des contraintes référentielles,
- entre les sources SQL des tables, procédures stockées, fonctions vers les fichiers utilisés ou les procédures stockées/fonctions appelées (**).

Apporter la méthodologie pour la maintenance d’une base de données en version
Sans outil, il est bien plus facile de livrer la première fois une base de données complète que, plus tard, de livrer des ajouts/modifications/suppressions de tables, vues, procédures, … sur une base de données existante.

Pour cela, ARCAD a choisi de gérer des composants (source + objet) de type :
- TABLE (avec ses zones, ses clés, ses contraintes et ses déclencheurs),
- INDEX,
- VIEW,
- SQLUDT (types de données),
- SQLPRC (procédures stockées) (*),
- SQLUDF (fonctions utilisateurs) (*),
- SQLSEQ (séquences = compteurs) (**),

Chaque source permet de créer/recréer l’objet, par une compilation. Tous ces sources peuvent être récupérés depuis les objets d’une base de données existant déjà.
Dans une version, on peut choisir de modifier juste quelques composants DB2, ou bien d’effectuer des modifications importantes sur une base de données.
Ces modifications peuvent être effectuées sur les sources ou directement sur les objets. (sous contrôle d’ARCAD ou non).

Dans les deux cas, ARCAD détecte ensuite le delta des ajouts/modifications/suppressions et les incorpore à la version (en comparant les objets de référence à ceux éventuellement modifiés).
Le contrôle global de la version s’assure de la cohérence source/objet.

Pour transporter ces composants modifiés lors de mise en test, production ou distribution sur des sites/clients, on peut choisir :
- de transporter les sources puis de recompiler,
- ou de transporter directement tous les objets nécessaires.
A l’installation :
- les données existantes sont préservées,
- les contraintes vers une table livrée sont aussi préservées.

Pour les compilations, une étude des sources détermine automatiquement le bon ordre de compilation, en cas de dépendance entre tables, entre vues.
Le système de Rollback ARCAD prend en compte tous ces types d’objets.
Des déclencheurs de substitutions gérés par ARCAD permettent de faciliter la maintenance et les surtout les tests (dans une version) de programmes L3G, quand ils sont appelés depuis des déclencheurs systèmes posés sur des tables, sans nécessiter de modifier la table.

(*) avec un objet « virtuel » si procédure stockée ou fonction « système »
(**) disponible dans la prochaine version d’ARCAD (V 8.05.A).