Introduction
Les applications développées avec HARMONY peuvent accéder aux données stockées dans des bases de données relationnelles.
L'accès à l'information s'effectue suivant le modèle client-serveur. Le produit XLANSQL Serveur doit être installé sur le serveur. Sur chaque poste client on paramètrera le client XLAN.
XLANSQL accède en temps réel aux dictionnaires décrivant les fichiers de l'application. Ils doivent être installés sur le serveur et correspondre effectivement à la description des fichiers. Ce sont impérativement des dictionnaires avec l'extension .dhsd.
L'utilitaire XPSQL.dhop permet le transfert et la gestion des données dans la base SQL.
Pour une application donnée, on pourra choisir quels fichiers doivent être transférés dans la base SQL.
XLANSQL Serveur gère à la fois :
L'accès aux données stockées dans la base SQL.
L'accès aux fichiers HARMONY stockés sur le serveur (comme XLAN SERVEUR).
Les licences d'utilisation des produits (comme XLAN SERVEUR).
...
Microsoft SQL Server
Oracle
IBM DB2
...
L'installation de la base de données.
La création d'une base de données utilisateur pour le stockage des tables de l'application.
La création des utilisateurs dans la base.
La configuration de la source pour l'accès à la base par ODBC.
L'installation du runtime d'harmony sur le serveur.
L'installation de XLANSQL sur le serveur.
La configuration de la base SQL dans la table des serveurs.
L'installation des fichiers de l'application sur le serveur.
L'installation des dictionnaires de données de l'application sur le serveur.
La création des utilisateurs par DIVALTO ou par XLOG1.
La configuration d'un XLAN Client sur le serveur.
La création et la copie des fichiers de l'application dans la base SQL.
...
Insérez le CD dans le lecteur.
Le menu d'installation est affiché. Cliquez sur la ligne affichant le choix XLANSQL SERVEUR.
Suivez les instructions d'installation.
...
Nom de l'ordinateur : C'est le nom de la base SQL. Par exemple ERPDivalto. Ce nom servira de chemin pour accéder au serveur SQL depuis le poste client. (Voir Chemins implicites). Pour Oracle il correspond au nom du schéma propriétaire des tables.
Adresse : C'est le nom de la base de donnée du serveur SQL. Il prend la même valeur que le paramètre Nom de l'ordinateur.
Chemin SQL : (facultatif) Chemin Harmony ou se trouve le répertoire contenant les dictionnaires ainsi le fichier paramètres FHSQL.dhfi de la base. Exemple : /divalto/bases/erpdivalto. Si non renseigné, le chemin est /divalto/"nom de la base".
Type : doit être positionné à la valeur Base SQL.
Système d'exploitation : Windows
...
Choix du type de serveur SQL.
Le bouton « Serveur SQL » permet de choisir entre «SQL server» de Microsoft, IBM DB2 et «Oracle». Ce choix permet également de visualiser (voire de modifier) la chaîne de connexion ODBC à la base de données.
Choix de la base SQL.
Le bouton « Base SQL » permet de choisir la base SQL. Il est grisé lorsqu'une seule base a été configurée dans la table des serveurs.
Fichier par fichier.
Le choix du transfert des informations dans la base SQL se fait fichier harmony par fichier harmony. Par exemple pour une application comme "Divalto Comptabilité", on peut décider de ne transférer que le fichier des statistiques, et de conserver les autres fichiers sous HARMONY. Dans cet exemple toutes les tables du fichier CCFTSC.dhfi seront transférées dans la base SQL.
Paramètres d'un fichier Harmony
A chaque fichier harmony que l'on souhaite transférer et gérer dans la base SQL est associé un enregistrement paramètre.
Application
Dans la fiche paramètres, on précisera l'application à laquelle appartient le fichier Harmony. Cette information permet de regrouper tous les fichiers d'une application. Les boutons d'action " par application " de l'utilitaire XPSQL permettent d'effectuer les opérations pour une application complète et non plus fichier par fichier. Dans ce cas le paramètre " Valide " de la fiche paramètres indique si ce fichier doit être pris en compte ou non.
Création des tables et copie des données.
L'utilitaire XPSQL permet d'effectuer la création des tables et le transfert des données dans la base. Pour le paramétrage de nouveaux fichiers et le fonctionnement détaillé de cet utilitaire reportez-vous au chapitre XPSQL.
Pour une application donnée, sélectionnez les fichiers que vous souhaitez transférer en activant le paramètre "Valide". Ce paramètre de chaque fiche indique si le fichier doit être pris en compte ou non.
Le choix " Création Tables " de la barre de boutons " par application " permet d'effectuer la création des tables et le transfert des fichiers. Avant d'activer ce choix, assurez-vous que vous utilisez un code d'utilisateur connu dans XLOG. Pour Microsoft SQL, l'utilisateur doit de plus être membre du rôle " sysadmin ". Pour Oracle cette opération doit être effectuée avec l'utilisateur correspondant au schéma de la base (Par exemple «ERPDivalto »).
Connexion au serveur.
La plupart des actions de XLANSQL nécessitent une connexion avec le serveur SQL. Lors de sa première connexion au serveur, XPSQL stocke les paramètres de connexion dans le fichier FHSQL.
Voir également : Connexion au serveur.
Erreurs de transfert.
Les erreurs lors de la création des tables ou du transfert des informations sont affichées dans la zone de texte enrichie de la fiche en cours. Vous trouverez les explications des erreurs les plus couramment rencontrées dans le chapitre concernant XPSQL.
Voir également : Les erreurs.
Remarques pour Microsoft SQL server.
Après le transfert, les tables ne sont pas forcément tout de suite visibles dans l'outil d'administration de SQL.
Après le transfert, le premier accès à une table peut être long.
...
Assure la gestion des données dans la base DB2.
Assure la gestion des fichiers Harmony dans l'IFS du serveur i. Ces fichiers sont au format Harmony. Ils sont strictement compatibles avec les fichiers sous Windows. L'utilitaire Xtools permet de copier ces fichiers depuis ou vers un système de fichiers de Windows.
Assure la gestion des licences.
...
L'installation de XLAN sur le serveur IBM i.
La modification des paramètres du serveur.
Le démarrage du serveur.
La création des schémas et des utilisateurs dans la base DB2.
L'activation des licences du serveur IBM i.
La configuration de la source pour l'accès à la base par ODBC.
La configuration d'un client XLAN.
La configuration de la base SQL dans la table des serveurs.
L'installation des fichiers de l'application sur le serveur.
L'installation des dictionnaires de données de l'application sur le serveur.
La création des utilisateurs par DIVALTO ou par XLOG1.
Le paramétrage de la chaîne de connexion CLI.
La création et la copie des fichiers de l'application dans la base DB2.
...
Ouvrir une session dans System i Navigator avec le profil QSECOFR ou un profil disposant du droit spécial *ALLOBJ.
Choisir "Exécution d'un script SQL" dans System i Navigator et ouvrir le script InstallationXLAN.sql
Exécuter les 3 commandes de l'étape 1.
Pour l'étape 2 FTP suivre les instructions du paragraphe "3.Transfert des fichiers vers l'IBM i par FTP" .
Exécuter les commandes de l'étape 3.
...
utiliser l'action "Arrêter le serveur" de l'utilitaire xconsole.dhop
ou utiliser la commande XLAN/ENDXLAN
ou, par le System i Navigator, par le choix "Arrêt/Suppression" option "Arrêt contrôlé" du travail XLAN.
...
Un profil utilisateur (qui sera utilisé par XLAN pour se connecter à la base DB2)
Un schéma (qui servira à stocker les descriptions des tables et autres objets de la base)
Pour que le schéma ait les bons droits d'accès, on le créera en étant connecté avec le profil utilisateur correspondant.
Création du ou des profils utilisateur
Créer autant de schémas et de profils utilisateur que de bases DIVALTO for i :
Exemple 1 : pour la base ERPDivalto
CRTUSRPRF USRPRF(ERPDIVALTO) PASSWORD() CCSID(1147)
Exemple 2 : pour une base spécifique pour la Paie.
CRTUSRPRF USRPRF(PAIE) PASSWORD() CCSID(1147)
Nb : le CCSID 1147 correspond au jeu de caractères pour une installation française.
Création du ou des schémas
Se connecter au serveur avec le profil correspondant au schéma que l'on souhaite créer.
Créer le schéma soit :
par System i Navigator dans l'arbre Bases de données-> schémas, clic droit puis nouveau.
par la commande SQL create collection
...
Nom de l'ordinateur : Nom du serveur.
Adresse : Indiquer l'adresse IP du serveur SQL. Cette adresse est facultative si le poste client sait résoudre l'adresse à partir du nom du serveur.
Type : Serveur Xlan
Système d'exploitation : IBM iSeries
Numéro de port : 1235 par défaut ou la valeur de "NuméroService" du fichier config du serveur.
...
Dans la table des serveurs du serveur IBM i. Ce paramètre sera utilisé par XLAN.
Dans la table des serveurs du poste client servant à l'installation. Ce paramètre servira à l'utilitaire de paramétrage XPSQL qui s'exécute sur le poste client.
Dans la table des serveurs du serveur IBM i.
Sur le serveur, pour que XLAN puisse accéder à la base SQL, on crée une entrée de type « BaseSQL » dans la table des serveurs par le choix "Serveurs" du menu "Paramétrage" de Harmony.dhop. Il convient de sélectionner le serveur par le bouton "Choix du serveur".
On garnira les champs suivants :
Nom de l'ordinateur: C'est le nom de la base SQL. Par exemple ERPDivalto. Ce nom servira de chemin pour accéder au serveur SQL depuis le poste client. (Voir Chemins implicites).
Adresse: C'est le nom de la base de donnée du serveur SQL. Il prend la même valeur que le paramètre Nom de l'ordinateur.
Chemin SQL : (facultatif) Chemin Harmony ou se trouve le répertoire contenant les dictionnaires ainsi le fichier paramètres FHSQL.dhfi de la base. Exemple : /divalto/bases/erpdivalto. Si non renseigné, le chemin est /divalto/"nom de la base".
Type: doit être positionné à la valeur Base SQL.
Système d'exploitation: Unix ou IBM iSeries
...
DSN : le nom de la source de données. Il correspond généralement au nom du serveur IBM i. Attention ce nom est dépendant de la casse, il est généralement en majuscule.
UID : le nom du profil pour la connexion à la base. Le jocker %1% est remplacé par le profil (schéma) correspondant à la base de données paramétrée dans la table des serveurs (par exemple ERPDivalto). Elle doit également correspondre à un code utilisateur d'Harmony créé dans le fichier des utilisateurs avec son mot de passe.
PWD : le mot de passe de l'utilisateur UID. Le jocker %2% est remplacé par le mot de passe de l'utilisateur correspondant à la base. Il provient du fichier des utilisateurs d'Harmony.
...
Choix de la base SQL. Le bouton « Base SQL » permet de choisir la base SQL et le serveur IBM i. Il est grisé lorsqu'une seule base et un seul serveur ont été configurés dans la table des serveurs. Dans la liste des serveurs, ne sont proposés que les serveurs dont le système d'exploitation est IBM iSeries.
Choix du type de serveur SQL. Le bouton « Serveur SQL » permet de choisir le type de base de données. On positionnera ce choix à « IBM DB2». Ce choix permet également de visualiser (voire de modifier) la chaîne de connexion ODBC à la base de données, ainsi que la chaîne de connexion CLI.
Fichier par fichier. Le choix du transfert des informations dans la base SQL se fait fichier Harmony par fichier Harmony. Par exemple, pour une application comme "Divalto Comptabilité", on peut décider de ne transférer que le fichier des statistiques, et de conserver les autres fichiers sous HARMONY. Dans cet exemple, toutes les tables du fichier CCFTSC.dhfi seront transférées dans la base SQL.
Paramètres d'un fichier Harmony. A chaque fichier Harmony que l'on souhaite transférer et gérer dans la base SQL, est associé un enregistrement paramètre.
Application. Dans la fiche paramètres, on précisera l'application à laquelle appartient le fichier Harmony. Cette information permet de regrouper tous les fichiers d'une application. Les boutons d'action "par application" de l'utilitaire XPSQL permettent d'effectuer les opérations pour une application complète et non plus fichier par fichier. Dans ce cas, le paramètre "Valide" de la fiche paramètres indique si ce fichier doit être ou non pris en compte.
Création des tables et copie des données. L'utilitaire XPSQL permet d'effectuer la création des tables et le transfert des données dans la base. Pour le paramétrage de nouveaux fichiers et le fonctionnement détaillé de cet utilitaire, reportez-vous au chapitre XPSQL. Pour une application donnée, sélectionnez les fichiers que vous souhaitez transférer en activant le paramètre "Valide". Ce paramètre de chaque fiche indique si le fichier doit être ou non pris en compte. Le choix "Création Tables" de la barre de boutons "par application" permet d'effectuer la création des tables et le transfert des fichiers. Avant d'activer ce choix, assurez-vous que vous utilisez le code d'utilisateur correspondant au schéma de la base (par exemple « ERPDivalto »).
Connexion au serveur. La plupart des actions de XPSQL nécessitent une connexion avec le serveur SQL. Lors de sa première connexion au serveur, XPSQL stocke les paramètres de connexion dans le fichier FHSQL. Voir également : Connexion au serveur.
Erreurs de transfert. Les erreurs lors de la création des tables ou lors du transfert des informations sont affichées dans la zone de texte enrichi de la fiche en cours. Vous trouverez les explications des erreurs les plus couramment rencontrées dans le chapitre concernant XPSQL. Voir également : Les erreurs.
...
Nom de l'ordinateur : Nom Harmony du serveur. Il est conseillé de prendre ici son nom NetBios (nom qui apparaît dans le voisinage réseau).
Adresse : Indiquer l'adresse IP du serveur SQL. Dans le cas particulier de la configuration d'un poste client sur le serveur, indiquer 127.0.0.1 qui correspond toujours à l'adresse du serveur lui-même (localhost). De même pour les éditions Terminal Server de Windows (TSE), lorsque le serveur d'applications est aussi le serveur de données.
Type : Serveur Xlan
Système d'exploitation : en fonction du serveur.
Numéro de port : 1235 par défaut ou la valeur de "NuméroService" de Divalto.ini du serveur.
...
ServeurSQL représente le nom du serveur dans la table des serveurs du poste client.
ERPDivalto représente le nom de la base de données configuré dans la table des serveurs du serveur SQL. Contrairement au paramétrage classique des chemins implicites pour des serveurs Harmony, on n'indique pas ici un chemin, mais bien le nom d'une base de données de la table des serveurs du serveur SQL.
...
Obligatoirement le fichier paramètre Fhsql.dhfi des fichiers sous SQL
Les dictionnaires de données des fichiers à transférer sous SQL. (sauf dans le cas où un chemin absolu a été défini dans les paramètres des fichiers).
Les originaux des fichiers à transférer sous SQL.
...
Les paramètres généraux de XPSQL.
Tous les paramètres concernant un fichier.
Le regroupement des fichiers par application.
Les actions que permet de réaliser XPSQL soit pour un fichier en particulier, soit pour une application complète :
L'audit pour tester la connexion au serveur SQL et vérifier la cohérence du dictionnaire de données.
La création des tables dans SQL.
La copie des données vers SQL.
L'extraction des données depuis SQL vers un fichier Harmony.
...
Obligatoirement le fichier paramètre Fhsql.dhfi des fichiers sous SQL. S'il n'existe pas, ce fichier est crée automatiquement à partir du fichier modèle FhsqlDivalto.dhfi.
Les dictionnaires de données des fichiers à transférer sous SQL. (sauf dans le cas où un chemin absolu a été défini dans les paramètres des fichiers).
Les originaux des fichiers à transférer sous SQL.
...
Le nom du dictionnaire où se trouve la description du fichier. Par défaut, le dictionnaire est cherché dans le répertoire /Divalto/ « nom de base sql ».
Le nom du fichier dans le dictionnaire.
L'application à laquelle appartient le fichier.
La version des tables dans la base SQL. Celle-ci correspond au numéro de version pris dans le dictionnaire de données au moment de la création des tables.
L'indicateur de validité de la fiche paramètres.
...
Les actions que permet d'exécuter XPSQL sont matérialisées par deux barres de boutons situées sur la droite de l'écran. La barre de boutons du haut porte sur le fichier ou les fichiers sélectionnés. La barre de boutons du bas porte sur tous les fichiers " Valides " de l'application de la fiche sélectionnée.
Lorsqu'une action est en cours, on trouve dans la fiche affichée à l'écran, le libellé de l'action.
Dans la fiche, une zone de texte enrichie contient l'état d'avancement de l'action ainsi que les erreurs éventuellement détectées.
XPSQL écrit également les résultats et les erreurs survenues dans le fichier DHOdbcConfigSQL.LOG.
...
La chaîne de connexion ODBC (comme décrite ci-dessus), utilisée par l'utilitaire XPSQL pour la création des tables.
La chaîne de connexion CLI, utilisée par le travail XLAN sur le serveur i. En effet, le travail XLAN qui s'exécute sur le serveur, n'utilise pas l'interface ODBC pour dialoguer avec la base DB2, mais l'interface CLI propre au système i. On trouvera donc dans la boîte de dialogue des paramètres de la base, les deux chaînes de connexion.
...
...
Le chemin du fichier d'origine.
Le chemin du fichier de destination. Rappelons qu'il s'agit d'un chemin correspondant au serveur SQL. Les accès à la base sont toujours effectués en mode client-serveur, même à partir du serveur.
L'option avec ou sans effacement du contenu des tables existantes.
...
La copie des données vérifie le numéro de version du fichier .dhfd. Si le numéro de version du fichier .dhfd ne correspond pas à celui renseigné dans xpsql, une erreur est affichée. Si vous êtes en possession d'un fichier sans version, il est possible de la renseigner via l'utilitaire xtools.dhop
Si le fichier est comprimé (.dhzi), l'utilitaire effectue la décompression.
Voir également :
...
Le chemin de la base SQL.
Le chemin du fichier Harmony de destination.
L'option avec ou sans effacement du contenu des tables existantes.
S'il faut comprimer les fichiers
Lorsque la copie est lancée " par application " le mode " pas à pas " permet d'intervenir dans le déroulement du transfert fichier par fichier.
Remarques :
Avant la version 2018-403 d'Harmony, l'extraction d'un fichier contenant un champ de type Blob n'est pas possible. Maintenant, l'extraction va générer un fichier .blob qui contient les champs de type Blob. Ce fichier sera utilisé lors de la copie des données.
La version du fichier est maintenant renseignée dans les attributs du fichier .dhfd. Cette version est contrôlée lors de la copie des données vers SQL. Si vous êtes en possession d'un fichier .dhfd sans version, il est possible de la renseigner via l'utilitaire xtools.dhop
Si l'option "Compression des donneés" est activée, le fichier .dhfd est comprimé en .dhzi. Le .dhfd est supprimé. La copie des données détecte si le fichier est comprimé et effectue la décompression.
Voir également :
...
« Harmony » : Nom du fichier Harmony à copier / extraire
« SQL » : Nom du fichier SQL à copier / extraire
« Mode » : Facultatif. S'il vaut 'C', alors la copie / extraction se fera en mode sans effacement
...
Un code d'état (SQLSTATE) normalisé par X/OPEN et SQL CAE spécification (1992). Par exemple S0001 signifie " Base, table ou vue déjà existante ".
Un message d'erreur en clair de la forme :
[Microsoft][ODBC SQL Server Driver][SQL Server] message en clair.
Le message en clair peut être par exemple :
Echec à la connexion de l'utilisateur 'demo'
Il existe déjà un objet nommé 'désir' dans la base de données.
La documentation en ligne de la base utilisée peut être consultée pour des explications complémentaires.
L'erreur 0B17.
Lors du transfert d'un fichier dans une base SQL, si le fichier comporte plusieurs types d'enregistrements différents, ils doivent impérativement être identifiés par un identifiant. A l'écriture dans la base, XLANSQL doit reconnaître l'enregistrement grâce à cet identifiant. Si l'enregistrement ne correspond à aucun enregistrement décrit dans le dictionnaire de données, XLANSQL renvoie une erreur 0B17. L'utilitaire XPSQL affiche l'erreur avec le rang de l'enregistrement dans le fichier des données. Il convient alors de vérifier soit :
La description des enregistrements du dictionnaire.
La valeur de l'identifiant pour l'enregistrement concerné dans le fichier d'origine.
...
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.
...
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.
...
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.
...
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é :
...
« 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.
...
« 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.
...
« TypeAction » : indique le type d'action à effectuer. Deux valeurs sont possibles : « SYNCHRO » et « SCRIPT ». Pour l'exécution d'un script, il faut utiliser « SCRIPT ».
« CheminDico » : chemin où se trouvent les dictionnaires actuels, typiquement /divalto/« nom de base sql ».
« CheminFichierScript » : chemin complet du script SQL à exécuter.
« SupprimerTableSauvegarde » : permet de supprimer ou non les tables de sauvegarde des champs supprimés suite à une synchronisation (tables suffixées par « _oldColumns »). Pour les supprimer, doit valoir 1.
« NomServeur » : Nom du serveur où se situe la base de données.
« NomBase » : Nom de la base de données à synchroniser.
« RequiertValidation » : Demande à l'utilisateur de valider la fenêtre de compte-rendu (0 ou 1). Si 0, les erreurs d'exécution sont affichés via MessageBox.
...
Microsoft SQL Server La première instruction, « USE <BASESQL> ; » est obligatoire et doit rester inchangée. « <BASESQL> » sera automatiquement remplacé par le nom de la base. Le reste est du Transact-SQL standard (http://msdn.microsoft.com/fr-fr/library/ms189826%28v=SQL.90%29.aspx).
Oracle. Pour Oracle, c'est PL/SQL qu'il faut utiliser (http://www.oracle.com/technology/tech/pl_sql/index.html).
IBM DB2. Pour ce moteur de base de données, toutes les requêtes doivent se trouver dans des procédures. De plus, la balise « <execute> » est obligatoire après chaque création, exécution et suppression de procédure. Attention : la procédure DOIT porter le nom « proc_migration ». Pour le reste, la syntaxe reste assez proche de celle du PL/SQL d'Oracle (http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/index.jsp?topic=/sqlp/rbafykickoff.htm).
...
L'index permettant d'accéder aux tiers (c'est à dire à la table des clients, la table des fournisseurs, la table des prospects …) est simulé par la création d'une table des tiers, dans laquelle, pour chaque tiers l'on précisera s'il s'agit d'un client, d'un fournisseur ou d'un prospect.
La table des statistiques de ventes comporte plusieurs codes représentant. On décrira autant index utilisant la même lettre que de codes représentant. Pour SQL, la table intermédiaire des statistiques par représentant permet de simuler le fonctionnement de ces index.
La table des écritures comptables comporte des écritures lettrées et des écritures non lettrées. Harmony permet de définir un index conditionnel ne portant que sur les écritures non lettrées. Les écritures non lettrées forment un sous-ensemble de la table des écritures. Pour SQL, la table intermédiaire des écritures non lettrées fera office d'index conditionnel sur l'ensemble des écritures.
Rappels terminologiques
L'identifiant d'une table est un code d'un caractère qui distingue chaque table d'un fichier Harmony. Il est obligatoire pour les fichiers comportant des tables différentes.
Le code condition est un code d'un caractère déterminant si une entrée doit être générée dans l'index d'une table pour une ligne particulière. Dans la description de l'index soumis à une condition on indique le nom du champ servant de code condition ainsi que l'opérateur de la condition et sa valeur. Le code condition peut être un des champs qui compose l'index ou non. Il peut correspondre à l'identifiant de la table ou non.
...
...
La condition correspond strictement à l'identifiant de la table. Dans ce cas elle est ignorée dans l'index, puisque toutes les lignes de la table correspondent obligatoirement à la condition.
La condition définit un sous-ensemble de la table courante et l'opérateur de la condition est l'égalité. Dans ce cas, le code condition est ajouté en majeur dans les champs qui composent l'index. La lecture par cet index ne retient que les lignes pour lesquels la condition est remplie. Remarque : Si le sous-ensemble correspondant aux lignes répondant à la condition est peu important, il peut être plus judicieux de définir cet index de type conditionnel pour accélérer les écritures et réduire l'espace disque.
La condition définit un sous-ensemble de la table courante mais l'opérateur de comparaison n'est pas l'égalité. Dans ce cas, l'index ne peut pas être défini de type normal, mais doit impérativement être de type conditionnel.
...
L'identifiant de la table est un des champs de l'index. On peut envisager de déclarer l'index de type avec identifiant.
La composition des différents index avec la même lettre clé ne comporte pas les mêmes champs selon les tables auxquels elle permet d'accéder. Ce cas n'est pas pris en compte par XLANSQL. Il s'agit d'une incompatibilité totale et il convient de modifier l'application.
La composition des différents index est la même quelle que soit la table. Dans ce cas, XLANSQL gère une table intermédiaire avec les champs de l'index. Chaque ligne de la table intermédiaire pointe sur la ligne correspondante dans la table cible.
...
Contrairement à l'index de type multi-tables, l'index avec identifiant n'a pas besoin de table intermédiaire. Chaque index de chaque table devient alors un simple index de la table SQL.
De plus chaque index peut avoir une description différente. Toutefois, pour une lettre clé donnée, la taille totale des champs des l'index doit être identique pour tous les index. Si pour un index cette taille est plus courte, il convient d'ajouter un filler dans la description de l'index.
...
L'identifiant de la table doit impérativement être positionné dans la clé avant tout accès en lecture. En effet c'est la valeur de l'identifiant dans la donnée tdf.key qui permet de savoir à quelle table s'adresse la requête. Une tentative d'accès sans une valeur de l'identifiant correcte dans la clé provoque une erreur fatale spécifique lors de l'accès à une base SQL, alors qu'elle n'en génère pas lors d'un accès à un fichier Harmony.
Lors d'une lecture séquentielle d'une table SQL pour un code identifiant donné, une tentative de lecture après la dernière ligne de la table renvoie un code de détection de fin de fichier (H_EOF), alors que la lecture d'une table Harmony renvoie la première ligne de la table avec l'identifiant suivant.
...
Celles dues à la base de données.
Celles dues à Harmony.
Les incompatibilités totales.
La gestion des réservations.
...
Contrairement aux fichiers d'HARMONY, les données d'une table de la base sont typées et le moteur de base de données vérifie la concordance des données écrites avec leur description dans la base. Ceci implique qu'une donnée non numérique dans un champ numérique ou bien une date incorrecte sont détectées lors de l'écriture dans la base alors qu'aucune erreur n'était signalée par HARMONY. De la même manière, une recherche sur un index comprenant une date incorrecte par exemple n'aboutira pas alors qu'elle rendait un résultat sous HARMONY.
Les champs de type L (long) sont signés et permettent de stocker des valeurs comprises entre –2.147.483.648 et 2.147.483.647. Sous HARMONY, les champs de type L ne sont pas signés et autorisent des valeurs comprises entre 0 et 4.294.967.295
La redéfinition ou le découpage de données n'existent pas dans une base de données. Dans le dictionnaire de données d'HARMONY, au niveau de chaque donnée, une option permet d'indiquer si la donnée doit être masquée ou non dans SQL.
Le zoom d'HARMONY affiche un ascenseur permettant de connaître environ la position relative de l'enregistrement courant dans le fichier et de se positionner approximativement ailleurs. La gestion de fichier d'HARMONY fournit deux fonctions permettant de réaliser ces opérations. Il n'existe pas d'équivalent dans une base de données, l'ascenseur du zoom n'est donc pas opérationnel.
...
La taille maximale d'un enregistrement est de 8Ko.
Les champs de type date permettent de stocker des dates comprises entre le 1/1/1753 et le 31/12/9999. Une date en dehors de cette période est considérée comme erronée. Si votre application doit stocker des dates antérieures au premier janvier 1753, il faudra déclarer le champ de type alphanumérique dans le dictionnaire. Une date à espace (valeur non renseignée) sera remplacée par le 1/1/1753 à l'écriture et de nouveau convertie en espaces lors de la lecture par l'application.
Le nombre maximum de champs composant un index est limité à 16. Sous HARMONY une clé peut comporter jusqu'à 16 zones disjointes ( jusqu'à 5 pour les versions antérieures à 5). De plus XLANSQL ajoute pour sa gestion un ou deux champs à l'index, ce qui limite à 14 ou 15 champs les données d'un index.
Voir également : La structure des index.
L'entreprise manager permet de définir pour une base de données l'ordre de classement des index par le paramètre "Nom du classement". Il est impératif de modifier la valeur par défaut de ce paramètre par "Latin1_General_Bin" qui correspond à l'ordre des caractères du jeux ascii avec une distinction entre les caractères majuscules et minuscules.
...
Lorsqu'un fichier comporte plusieurs types de tables différentes, chaque table doit obligatoirement comporter un identifiant. Si cette contrainte n'est pas respectée, le fichier ne peut pas être géré par XLANSQL.
Les index multi-tables avec des descriptions différentes qui ne contiennent pas l'identifiant de la table ne sont pas gérés par XLANSQL.
...
Les clés avec des données packées ne sont pas gérées.
Les index avec des valeurs à espace sont générés dans la base alors que les clés à espace ne sont pas générées avec HARMONY. Cette incompatibilité devrait être mineure.
Les index comportant des données numériques signées tiennent compte du signe. L'ordre de tri ne sera pas le même qu'avec HARMONY. Cette incompatibilité devrait être mineure.
Les données numériques à espaces sont remplacées par 0. Cette incompatibilité devrait être mineure.
Les dates à espace prennent la valeur 1/1/1753 dans la base de données. Cette incompatibilité devrait être mineure.
La gestion des protections globales de fichier d'HARMONY en lecture, écriture ou effacement (R,W,E) n'est pas assurée. Cette incompatibilité devrait être mineure.
Pour les données numériques avec un nombre de décimales variables (Numerique,D) celui-ci doit être déterminé à la création des tables et ne peut pas être modifié dynamiquement. Cette incompatibilité devrait être mineure.
Harmony permet de définir pour les clés conditionnelles l'opérateur ET LOGIQUE (&). Cette fonctionnalité n'est pas gérée.
Le mode de fonctionnement des accès par un index de type avec identifiant sous SQL n'est pas strictement identique à celui sous Harmony. (voir Index avec identifiant)
La gestion de fichiers Hamony, lors d'une lecture séquentielle, délivre les clés homonymes strictes (tous les champs de la clé contiennent la même valeur) en respectant l'ordre dans lequel les enregistrements ont été créés (du plus ancien au plus récent). Dans le cas d'index de type multi-tables lorsque des tables différentes comportent des homonymes, cette chronologie n'est pas respectée.
...
Définir une lettre clé différente pour chaque type d'enregistrement d'un fichier.
Définir chaque lettre clé d'un fichier avec une description unique.
Ne pas utiliser de zones packées. La gestion des données packées est prise en compte par XLANSQL pour la compatibilité des applications existantes, dans le cas d'une nouvelle application, il est préférable d'éviter l'utilisation de zones packées.
Ne pas découper une donnée en sous-données. En effet dans une base de données, il n'existe pas de redéfinition ou de découpage de données. Dans le dictionnaire de données d'HARMONY, pour la compatibilité des applications existantes, au niveau de chaque donnée, une option permet d'indiquer si la donnée doit être masquée ou non dans SQL. Le choix " audit " de l'utilitaire XPSQL vérifie la cohérence du dictionnaire et notamment détecte les champs qui se recouvrent.
Ne pas utiliser de tableaux. En effet la structure tableau n'existe pas dans les bases de données. Si un tableau est présent dans un enregistrement du dictionnaire, XPSQL créera autant de champs qu'il y a de cellules dans le tableau. Chaque nom de champ est suffixé par son ou ses indices dans le tableau. Par exemple le champ MT(12) donnera 12 champs MT_0001, MT_0002, … ,MT_0012.
Ne pas utiliser de donnée de type X ou de type L dans les enregistrements.
...
Type alphanumérique.
Type numérique.
Type numérique avec décimales variables : Il n'existe pas de type de données équivalent dans SQL SERVER. Le nombre de décimales de chaque classe est un paramètre global pour toutes les tables stockées dans SQL. (voir Décimales Variables).
Type date : Dans SQL SERVER le format date permet de stocker des dates comprises entre le 1/1/1753 et le 31/12/9999. Les dates à espaces seront remplacées par le 1/1/1753 dans la base SQL.
Type date sur 6 caractères : Ce format est traduit par une chaîne alphanumérique de 6 caractères.
Type date mensuelle : Ce format est traduit par une chaîne alphanumérique de 6 caractères.
Type date et heure : Ce format est traduit par une chaîne alphanumérique de 14 caractères.
Type heure : Ce format est traduit par une chaîne alphanumérique de 6 caractères.
Type B.
Type X : Ce type devient un INT dans la base. Il est déconseillé.
Type L : Ce type devient un INT dans la base. Les INT sont signés et prennent de valeurs comprise entre –2 Go et +2 Go alors que le type L n'est pas signé est prend des valeurs comprise entre 0 et 4 Go. Il est déconseillé.
...
Une donnée appelée table_id, où table est le nom de la table, est ajoutée à chaque table. Cette donnée permet d'identifier de manière unique chaque ligne de la table. Dans SQL SERVER, elle a la propriété IDENTIFY. Sous Oracle, sa valeur est obtenu par une « séquence ».
La redéfinition et les sous-découpages des données n'existent pas dans les bases de données. Un indicateur " masquée dans SQL " du dictionnaire de données pour chaque donnée permet d'indiquer si la donnée doit être ou non dans la base SQL. Par exemple, le découpage des dates en sous-données ou le regroupement des données élémentaires d'une adresse dans un champ adresse complète seront masqués de cette manière.
Les tableaux n'existent pas dans les bases de données. Chaque élément du tableau devient une donnée élémentaire suffixée par son indice dans le tableau.
...