transactions qui entrent dans le système
sans passer par le filtre du processus de
validation d’application normal. De ce
point de vue, on peut utiliser les contraintes de la même manière que des
règles de clés en double: il incombe au
programmeur de vérifier que les enregistrements
ajoutés à  un fichier ne produisent
pas de clés en double. Mais si tout le
reste échoue, la base de données empêchera
la création de clés en double et génèrera
un message d’erreur système.
C’est une bonne utilisation des
contraintes et, comme celles-ci sont très
efficaces, la pénalité de performances subie
par une double vérification de la
même condition (en supposant que le
code applicatif vérifie correctement la
condition de contrainte) est probablement
acceptable. Toutefois, cette utilisation
des contraintes ne fait rien pour
améliorer l’architecture applicative. La
deuxième difficulté en matière de
contraintes concerne la manière dont les
erreurs de contrainte sont signalées aux
applications en langage évolué (HLL,
high level language). Pour bénéficier pleinement
des contraintes, les applications
qui mettent à  jour la base de données
doivent traiter les erreurs de contraintes.
Malheureusement, il n’est pas toujours
facile de déterminer quelle contrainte a
été violée par une certaine transaction et
de signaler cette information à  l’utilisateur.

Ainsi, si plus d’une contrainte est associée
à  un fichier particulier, l’ordre
dans lequel les contraintes sont vérifiées
est déterminé par le type de contrainte et
son ordre assigné, qui peut être complètement
arbitraire. De plus, dès qu’une erreur
de contrainte survient, le traitement
des autres contraintes s’arrête. Par conséquent,
il est difficile d’écrire un modèle
d’application iSeries standard qui présente
toutes les erreurs à  la fois à  l’utilisateur.
En outre, alors qu’un programme
ILE RPG peut distinguer une erreur de
contrainte d’autres types d’erreurs de fichier
(pas d’enregistrement trouvé, par
exemple) d’après le champ *STATUS
dans l’INFDS (information data structure),
il peut être difficile de savoir quelle
contrainte a causé une erreur et un appel
d’API est nécessaire pour obtenir des informations
détaillées sur l’erreur.

Cette complexité explique pourquoi la plupart des développeurs iSeries continuent
à  utiliser les contraintes strictement
comme un mécanisme fail-safe
pour améliorer le code d’interception
d’erreurs existant. Mais, face à  un projet
de modernisation d’applications d’envergure,
il vaut mieux investir dans la création
d’une suite de programmes de service
qui traitent les erreurs de
contraintes. Une fois cette infrastructure
créée, il est facile de l’adapter pour couvrir
les fichiers et contraintes supplémentaires.

Les contraintes appliquent le plus
haut niveau de partitionnement des applications
– les règles de gestion imposées
directement par la base de données.
Malheureusement, les techniques de traitement
des erreurs requises pour traiter
les erreurs détectées pendant l’imposition
des contraintes limitent les avantages
de celles-ci.