Avant d’entrer dans le vif du sujet, je rappelle qu’il est possible d’insérer une colonne dans une table existante au moyen d’un ALTER TABLE… ADD COLUMN….
Par défaut, la colonne ajoutée via cette technique sera toujours placée à la fin de la liste des colonnes de la table altérée, sauf si l’on précise explicitement que l’on souhaite ajouter la nouvelle colonne AVANT une autre colonne au moyen du mot clé BEFORE, ce qui nous donne ceci :
ALTER TABLE my_table ADD COLUMN new_column … BEFORE old_column ;
J’écrivais en introduction qu’il n’existe pas sur DB2 for i de possibilité de renommer une colonne, mais on peut détourner la technique ci-dessus pour effectuer ce renommage.
La technique consiste à procéder en 3 temps :
- insérer la colonne avec le nouveau nom avant la colonne qui va être supprimée
- copier les données de l’ancienne colonne vers la nouvelle colonne
- supprimer l’ancienne colonne
En SQL, cela donne ceci :
ALTER TABLE my_table ADD COLUMN new_name … BEFORE old_name ;
UPDATE my_table SET new_name = old_name;
ALTER TABLE my_table DROP COLUMN old_name;
Il y a néanmoins un effet de bord avec le DROP COLUMN, car cette instruction déclenche un message système CPA32B2 nécessitant une intervention. Ce message d’interruption apparaît automatiquement quand on travaille en mode 5250 (via STRSQL), il est alors facile d’y répondre (en l’occurrence il faut répondre I pour Ignore car le message indique que des données vont être perdues, ce qui est en l’occurrence normal).
Par contre, il est impossible de répondre manuellement à ce type de message à partir d’un client SQL en mode graphique (comme System i Navigator ou SquirrelSQL). Heureusement, il existe une solution de contournement que je décris ci-dessous :
- il faut tout d’abord qu’une réponse système automatique soit définie sur l’IBMi via la commande WRKRPYLE, pour le message CPA32B2
- ensuite, et avant l’exécution de l’ALTER TABLE, il faut exécuter la commande SQL suivante :
call qcmdexc (‘CHGJOB INQMSGRPY(*SYSRPYL)’, 26) ;
La documentation pour la valeur *SYSRPYL indique ceci :
» Le système vérifie, dans la liste des réponses système, si un poste existe pour tout message d’interrogation émis par ce travail. Si c’est le cas, il utilise la réponse de ce poste. Sinon, une réponse est obligatoire. »
On rappelle que le message renvoyé par l’ALTER TABLE.. DROP COLUMN.. est le CPA32B2. Si ce message a une réponse automatique définie sur l’IBM i, alors la commande CHGJOB permet d’en bénéficier au sein du travail relatif au code SQL en cours d’exécution.
Pour de plus amples informations sur le paramétrage de réponses systèmes automatiques, je vous conseille de vous reporter à l’article de Serge Gomez : ici
