Notation
Les numéros de version doivent être notés dans le fichier de description de la manière la plus concise possible (sans 0 terminal, excepté pour les numéros de version entiers). Le séparateur décimal est le point.
Une notation erronée entraînera une erreur de recherche (message "Erreur dans la séquence de mise à jour").
Exemple :
1.0 |
=> ok |
1.1 |
=> ok |
1 |
=> erreur (1.0) |
1.10 |
=> erreur (1.1) |
01.00 |
=> erreur (1.0) |
Réentrance et reprise sur erreur
Pour faire en sorte qu'une erreur ne provoque pas de corruption de la base de données lors d'une séquence de mise à jour, procéder comme suit :
Utiliser des scripts génériques de création de tables.
Les scripts de la section [PDM/Generic] sont réentrants. De facto, ils peuvent être exécutés plusieurs fois sans altérer la base de données.Laisser l'outil gérer implicitement les transactions.
Les scripts de la section [Data/*] sont exécutés en transaction. Si une erreur se produit, et à moins que la transaction n'ait été explicitement validée à un point donné (\commit), le script complet est annulé ; ceci permet de repartir d'un "état stable" de la base de données."Terminer" proprement les boucles de la séquence de mise à jour c'est-à-dire insérer un numéro de version à la fin de la séquence Data.
Ceci permettra à l'utilitaire de repartir du point le plus proche de l'erreur en cas d'incident (après que des mesures correctives ont été prises).Sur AS/400, travailler en mode journalisé avec une ou plusieurs collection(s) SQL. Dans le cas contraire, les scripts Data seront exécutés en AUTOCOMMIT et ne seront pas réentrant.
Note : si vous ne travaillez pas avec une collection, les nouvelles tables créées ne seront pas journalisées par défaut et une erreur surviendra si vous essayez d'exécuter les scripts Data en mode journalisé (option-logged).