Une condition peut survenir de deux manières : • Le SqlState runtime crée la condition pour une instruction SQL (par exemple, une table n'est pas trouvée quand une instruction Update s'exécute). Votre routine crée intentionnellement la condition en exécutant une instruction Signal ou Resignal. Dans le prochain article, j'expliquerai plus
Instructions Signal et Resignal

en détail quand il faut utiliser
Signal et Resignal. Pour l’instant, je me
cantonne à quelques règles de base
concernant ces instructions.
Une instruction Signal ou Resignal
provoque une condition spécifique
c’est-à -dire, un SqlState particulier).
Signal ne doit être exécuté qu’à l’extérieur
d’un handler. (Il faut utiliser
Resignal à l’intérieur d’un handler
parce que cette façon de faire préserve
une « pile » d’informations de diagnostic
concernant les conditions.) L’effet
d’une instruction Signal est essentiellement
le même que si la condition spécifique
s’était manifestée sur tout autre
type d’instruction. Ainsi, l’instruction
Signal SqlState ‘42704’
met SqlState à « 42704 » (table non
trouvée), tout comme le ferait l’instruction
suivante si la table Customxr
n’existait pas :
Update Customxr
Set Name = ‘Ajax’
Where CustId = 123456;
Bien que l’instruction Signal vous
permette d’indiquer un littéral pour le
SqlState (comme on le voit dans
l’exemple précédent), je vous conseille
de toujours utiliser un nom de condition
et d’inclure la clause Set de l’instruction
Signal avec un mnémonique
que vous aurez déclaré pour un texte
de message associé, comme en figure
4. A noter que Message_Text est un
mot-clé SPL et que la chaîne que vous
attribuez à Message_Text est placée
dans le champ SQLERRMC de la structure
SQLCA (SQL Communications
Area), laquelle peut être extraite par un
appelant de routine. Cette chaîne peut contenir un maximum de 70 caractères.
Une instruction Resignal doit toujours
être utilisée uniquement dans un
handler. (Bien que l’actuelle release de
SQL/400 vous permette d’exécuter un
Resignal hors d’un handler, cela pourrait
changer dans les futures releases.)
Je vous conseille d’utiliser Resignal
pour créer uniquement des conditions
exception. (Utiliser Resignal pour
créer des avertissements (warnings)
internes à une routine est plus complexe
et moins fonctionnel que de se limiter
à utiliser des indicateurs ou à
créer des exceptions pour contrôler le
débit interne. De plus, une instruction
Resignal dans un handler ne peut pas
servir à définir un SqlState warning ou
not found pour un appelant de routine.
Il n’y a donc pas de bonne raison
d’utiliser Resignal pour créer une
condition warning.)
Une instruction Resignal dans un
handler peut soit indiquer une nouvelle
condition spécifique à créer :
Resignal SqlStateNoSalesCondition
Set Message_Text = SqlStateNoSalesText;
soit resignaler simplement la même
condition qui a causé l’invocation du
handler :
Resignal;
Les deux formes de Resignal sont
utiles dans diverses situations de traitement
d’erreurs.
Téléchargez cette ressource

Rapport Forrester sur les solutions de sécurité des charges de travail cloud (CWS)
Dans cette évaluation, basée sur 21 critères, Forrester Consulting étudie, analyse et note les fournisseurs de solutions de sécurité des charges de travail cloud (CWS). Ce rapport détaille le positionnement de chacun de ces fournisseurs pour aider les professionnels de la sécurité et de la gestion des risques (S&R) à adopter les solutions adaptées à leurs besoins.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- De la 5G à la 6G : la France se positionne pour dominer les réseaux du futur
- Datanexions, acteur clé de la transformation numérique data-centric
- Les PME attendent un meilleur accès aux données d’émissions de la part des fournisseurs
- Fraude & IA : Dr Jekyll vs. Mr Hyde, qui l’emporte ?
- Gestion du cycle de vie des outils de cyberdéfense : un levier de performance pour les entreprises
