Synchronisation du schéma de la base

Owned by Bertrand Littel
Last updated: 03/10/2024 by Bertrand Littel
7 min read

Installation (IBM DB2)

Consultez le tableau des versions maintenues dans l’espace produit pour vérifier la compatibilité de la version Harmony et de la compatibilité IBM DB2

Attention, sous IBM DB2 uniquement, la synchronisation nécessite l'exécution préalable par l'administrateur du System i de la commande :
ADDRPYLE SEQNBR(5555) MSGID(CPA32B2) RPY('I') (attention lettre grand i derrière RPY)
Ceci a pour conséquence de changer la liste des réponses automatiques du système. En effet, lors d'une commande de suppression (par exemple d'un champ), le système demande une confirmation. Comme l'utilisateur n'a pas la main, ce sont les réponses automatiques du système qui sont utilisées.
Remarque : Cette commande n'est à exécuter qu'une seule fois pour un serveur (et non à chaque synchronisation).
Pour les autres moteurs de base de données, il n'y a aucune manipulation particulière à effectuer.

Description
La synchronisation du schéma de la base est un nouveau choix (à partir de la version 6.3 d'Harmony) de l'utilitaire Xpsql.dhop, qui gère la création des tables Harmony dans une base de données. XPSQL affiche la liste des fichiers pouvant être gérés dans la base SQL. La synchronisation concerne tous les fichiers dont la fiche paramètre est « valide » et dont le numéro de version est renseigné. L'utilitaire permet également de migrer une version de l'ERP à une autre.
L'utilitaire compare le schéma des fichiers « valides » existants avec celui d'un nouveau dictionnaire.
Les différences repérées sont :

  • Fichier :

    • Création

    • Suppression (1)

 

  • Table :

    • Création

    • Suppression (1)

    • Déplacement d'une table vers un autre fichier

 

  • Champ :

    • Création

    • Suppression (4)

    • Changement de nature (2)

    • Changement de taille (2)

    • Attribut « Masqué dans SQL » (2)

    • Changement du nombre de dimensions d'un champ tableau

    • Changement du nombre d'éléments des dimensions d'un champ tableau

 

  • Index :

    • Ajout

    • Suppression

    • Changement de type (3)

    • Changement de lettre clé

    • Changement de code condition, de condition et de la valeur de la condition

    • Ajout de champ

    • Suppression de champ.


Une modification d'un index entraîne sa suppression et sa recréation.

Les nouveaux champs dont l'attribut « Valeur Initiale Moulinette » du dictionnaire est renseigné seront initialisés avec cette valeur dans la base de données.
La détection de nouvelles applications ou d'applications supprimées est également gérée :

  • Pour les nouveaux applications, il suffit d'indiquer sur les fiches des produits que ces dernières sont valides et avoir le dictionnaire correspondant dans le répertoire des nouveaux dictionnaires.

  • Pour les applications supprimées, les fiches des produits doivent également être marquées comme « valides » mais dans le répertoire des nouveaux dictionnaires, le dictionnaire de cette application ne doit pas y figurer. Les fiches des produits seront alors automatiquement retirées du fichier paramètre FHSQL.dhfi.


Notes :
(1) Les tables supprimées ainsi que celles d'un fichier supprimé ne sont pas réellement supprimées dans la base : en réalité, elle sont renommées en <nom>_old . Par contre, les index, triggers et tables liées sont effectivement supprimées.
(2) Si le champ est utilisé dans un index, cet index sera supprimé et recréé.
(3) Le changement de type d'un index est vu comme une suppression et une création.
(4) Les champs supprimés d'une table sont conservés (avec les données) dans une table <nom_de_la_table>_oldcolumns.
Attention :

  • Le changement de nom n'est pas détecté en tant que tel : il sera vu comme une suppression de l'élément portant l'ancien nom et d'une création de l'élément portant le nouveau nom.

  • Si un changement de nature d'un champ intervient et si le nouveau type est incompatible avec l'ancien, les données sont perdues (par exemple, lorsqu'un champ alphanumérique devient numérique). Cependant, les données sont toujours présentes dans la table <nom>_old.



Mise en oeuvre

Avant de lancer le traitement de synchronisation, il faut :

  • Avoir correctement configuré la connexion à la base dans XPSQL (base de données, type de base). Ceci est normalement le cas puisque la synchronisation concerne des bases existantes.

  • Déconnecter tous les utilisateurs. En effet le traitement ouvre les fichiers concernés par la synchronisation en mode « réservé ».

  • Avoir fait une sauvegarde complète de la base de données. En effet, s'il se produit une erreur ou une interruption au cours de la synchronisation, il y a un risque d'incohérence entre le dictionnaire de données et le schéma de la base. L'ensemble des tables ne sera probablement pas au même niveau de mise à jour.

Le bouton « Synchroniser le schéma SQL » (ainsi que le sous-menu « Schéma SQL » du menu « Synchronisation ») permet de lancer l'utilitaire de synchronisation du schéma SQL existant avec une nouvelle version de ce schéma. L'utilitaire demande le chemin du ou des nouveaux dictionnaires. Seuls les fichiers marqués comme « valides » dans XPSQL seront traités.
Le traitement commence par mettre à jour le fichier paramètres FHSQL.dhfi en ajoutant les nouveaux fichiers à partir du modèle (FhsqlDivalto.dhfi).
On peut choisir de voir au préalable les changements détectés durant l'analyse des dictionnaires, avant de confirmer la mise à jour de la base de données (choix par défaut).

Chaque ligne représente une action. On y trouve le dictionnaire concerné, le type d'action (suppression, modification, création), le type d'objet concerné (fichier, table, champ, index) et le détail :

  • Pour le fichier, le détail se résume au nom du fichier.

  • Pour une table, on a <nom du fichier>, <nom de la table>.

  • Pour un champ, on a <nom du fichier>, <nom de la table>, < nom du champ>.

  • Pour un index, on a <nom du fichier>, <nom de la table>, <nom de l'index> (<type d'index>).

Les actions sont classées par dictionnaire et par ordre d'exécution.
Note :
Les actions nécessitant plusieurs traitements sont résumées en une seule ligne dans le tableau. Par exemple, pour une modification du type d'un champ utilisé dans un index, on verra l'action « Modification – Champ – <fichier>, <table>, <champ> » mais pas les actions de suppression, de recréation de l'index concerné et de garnissage de l'index.
Pendant la mise à jour de la base SQL, il n'y a aucun moyen d'arrêter la progression. Si une erreur se produit durant l'analyse des dictionnaires, une fenêtre vous en avertira. Pour avoir des précisions sur l'erreur, il faut regarder dans le journal d'erreurs.
Après une synchronisation réussie :

  • Les versions des fichiers sont mises à jour dans la liste.

  • Si un fichier a été supprimé, il est retiré de la liste.

  • Les anciens dictionnaires de données sont archivés dans le sous-répertoire /divalto/ « nom de base sql » /back.

  • Les nouveaux dictionnaires de données sont copiés dans le répertoire /divalto/ « nom de base sql ».

Une fois la synchronisation terminée, le cache des dictionnaires du serveur est automatiquement vidé.
Il y a trois types d'échec :

  • La synchronisation n'a pas pu démarrer car au moins des fichiers concerné n'a pu être réservé. Pour ce type d'erreur :

    • La mise à niveau n'est pas effectuée ;

    • Le programme de synchronisation affiche un message.

    • Avant de relancer la synchronisation, il faudra déconnecter tous les utilisateurs.

  • Une erreur fatale au niveau du serveur SQL. Pour ce deuxième type d'erreur :

    • La mise à niveau est stoppée ;

    • L'erreur est journalisée dans le fichier ferror.log, consultable à partir de la console d'administration ;

    • Avant de relancer la synchronisation, il faudra restaurer la base.

  • Une erreur SQL au moment du transfert des données existantes vers les nouvelles tables (lors de la modification d'un champ, par exemple). Pour ce troisième type d'erreur :

    • La mise à niveau n'est pas stoppée ;

    • Les tables concernées sont vides ou partiellement garnies;

    • Le schéma est cohérent avec le dictionnaire ;

    • Un récapitulatif des tables concernées est affiché :





Exécution de la synchronisation par programme

Pour exécuter une synchronisation, le programme xpsqlsynchro.dhop peut être appelé en-dehors de l'utilitaire xpsql.dhop. Il faut simplement lui envoyer par "ping" les paramètres suivants :

  • « TypeAction » : indique le type d'action à effectuer. Trois valeurs sont possibles :

  •  

    • « SYNCHRO » : Pour une synchronisation.

    • « SCRIPT » : Pour l'exécution d'un script SQL

    • « MAJINDEXCONDITIONNEL» : Pour lancer la migration des index conditionnels au nouveau format. Pour une exécution de script : Cf. livre Exécution de scripts.

  • « CheminDico » : chemin où se trouvent les dictionnaires actuels, typiquement /divalto/« nom de base sql »/.

  • « CheminNouveauDico » : chemin où se trouvent les nouveaux dictionnaires. Exemple : /divalto/erp63/.

  • « RequiertValidation » : permet de visualiser ou non la liste des différences repérées entre les deux versions des dictionnaires : 1 pour les visualiser, 0 pour une exécution directe. Il est conseillé de mettre cette valeur à 1.

  • « ModeAudit » : permet de faire un audit des requêtes SQL (0 ou 1). 1 demande de générer toutes les requêtes SQL mais sans les exécuter. Elles sont journalisées dans le fichier DhOdbcConfigSql.log, qui se trouve dans /divalto/DivaltoLog/. Sinon, les requêtes ne sont pas journalisées mais sont exécutées.

  • « ActualiserFHSQL » : permet de mettre à jour le fichier FHSQL.dhfi de la base (0 ou 1).

  • « CheminNouveauFHSQL » : permet de définir quel sera le fichier FHSQL qui servira de modèle pour la mise à jour de celui de la base. Par défaut, c'est le fichier fhsqldivalto.dhfi du répertoire divalto/sys qui est utilisé.

  • « NomServeur » : Nom du serveur où se situe la base de données.

  • « NomBase » : Nom de la base de données à synchroniser.


A la fin de l'exécution de l'utilitaire xpsqlsynchro.dhop, deux variables sont renvoyées par "pong" :

  • « CodeRetour » : compte-rendu. Les valeurs rendues sont :

    • 0 : pas d'erreur ;

    • 1 : erreur quelconque. Voir le fichier ferror.log pour les détails ;

    • 2 : l'utilisateur a quitté, via F9 ou via le bouton « Abandonner » ;

    • 3 : erreur SQL ;

    • 4 : erreur déjà signalée par MessageBox.

  • « FichiersSupprimes » : chaîne au format hmp regroupant les fichiers supprimés.

  • Utilisée pour la mise à jour du fichier FHSQL.dhfi. Chaîne de la forme : <fichier>nom<fichier>nom.