...

Installation (IBM DB2)

Info
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.

Ancre
Top_of_Description_htm Top_of_Description_htm

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 :

...

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>_oldchampoldcolumns.
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 :

...

• 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é :

Image Added

Ancre
Top_of_Execution_de_la_synchroni Top_of_Execution_de_la_synchroni

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.

...