Aller directement à la fin des métadonnées
Aller au début des métadonnées

Vous regardez une version antérieure (v. /wiki/spaces/PAI/pages/10557752458/Xlan+SQL) de cette page.

afficher les différences afficher l'historique de la page

Vous regardez la version actuelle de cette page. (v. 1) Actuel »

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


Gestion de plusieurs bases avec SQL Server
XlanSql sait gérer plusieurs bases sur le serveur SQL. Ceci permet d'avoir sur le même serveur une base d'exploitation et par exemple une base de test pour la formation des nouveaux utilisateurs.
Remarque :
Voir également : le chapitre Restrictions pour le détail des contraintes que doit respecter l'application.
Bases supportées :

  • Microsoft SQL Server

  • Oracle

  • IBM DB2


Installation et mise en oeuvre sur un serveur Windows
L'installation sur le serveur s'effectue en plusieurs étapes :

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

Voir également :
Base de données
Création d'une base HARMONY.
Création des utilisateurs de la base SQL.
Configuration de la source ODBC (DSN).
Installation du runtime.
Installation de XLANSQL.
Configuration de la base SQL dans la table des serveurs.
Création des utilisateurs d'Harmony.
Installation des fichiers de l'application.
Installation des dictionnaires de l'application.
Installation et configuration d'un client XLAN sur le serveur.
Création des tables SQL et copie des données.

Base de données
Si la base de données SQL n'est pas encore installée, il convient de l'installer et de la mettre en route.
Pour Oracle
Le paramètre d'administration OPEN_CURSORS permet de définir le nombre de curseurs ouverts simultanément lors d'une session d'accès au serveur. Pour des applications ouvrant un grand nombre de tables simultanément, il convient éventuellement d'ajuster ce paramètre afin d'augmenter sa valeur par défaut.

Création d'une base Divalto
Pour Microsoft SQL Server
Avec l'Entreprise Manager de SQL SERVER il faut créer une base de données pour stocker les tables à transférer. Si l'on ne crée qu'une seule base de données, on la nommera de préférence ERPDIVALTO (Le nom DIVALTO est réservé au chemin d'Harmony sur un poste). La création d'une base permet de choisir notamment l'emplacement et la taille des fichiers de la base.
Attention : Le nom de la base est dépendant de la casse. Il faut créer la base en MAJUSCULES.
On positionnera également les droits d'accès des utilisateurs.
Cette base doit être la base par défaut des utilisateurs d'Harmony si l'on ne gère qu'une seule base. Sinon, on précisera dans la chaîne de connexion au serveur le nom de la base SQL.
TRES IMPORTANT
Le paramètre "Nom du classement" permet de choisir l'ordre de tri pour les index. 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.
Pour Oracle
On créera un schéma pour chaque base du même serveur. Le schéma doit porter le nom de la base SQL configuré pour l'accès à la base dans la table des serveurs. Le nom DIVALTO est réservé au chemin d'Harmony sur un poste.
On vérifiera que le paramètre NLS_CHARACTERSET est positionné à WE8MSWIN1252

Création des utilisateurs de la base SQL
Pour Microsoft SQL Server
L'application se connecte à la base de données avec le code d'utilisateur d'HARMONY (cf XLOG) et le mot de passe de celui-ci sur le serveur.
Il convient donc, grâce à l'outil d'administration de la base, de créer les utilisateurs dans la base avec les droits d'accès appropriés. La copie initiale des fichiers de l'application dans la base doit être faite avec un utilisateur du rôle " sysadmin ". En effet cet utilisateur doit avoir le droit d'effacer les tables ( requête TRUNCATE TABLE ). Pour cela on créera donc un utilisateur particulier ( par exemple ROOT) et on l'inclura dans le rôle " sysadmin ".
On précisera que la base par défaut de l'utilisateur est par exemple ERPDIVALTO.
Pour Oracle
Pour chaque base, on créera un utilisateur «Nom de la Base SQL » dans la base ORACLE. Cet utilisateur sera le propriétaire de tous les objets créés dans la base par Harmony (tables, index, procédures,…).
Le service XLANSQL se connecte à la base Oracle avec l'utilisateur correspondant au schéma de la base Oracle ainsi créé, quelque soit le code de l'utilisateur Harmony. On créera donc dans Divalto un utilisateur pour chaque schéma dans la base Oracle avec son mot de passe.
La création des tables par l'utilitaire Xpsql.dhop se fera avec le compte correspondant au schéma de la base ORACLE.

Configuration de la source ODBC (DSN)
XLANSQL utilise l'interface standard ODBC pour l'accès à la base SQL. L'accès par ODBC nécessite la configuration d'une source de données. L'icône "Sources de données ODBC" du panneau de configuration permet d'administrer les sources de données. Sélectionner la source correspondant à la base de données dans l'onglet " DSN Système ". Configurer la source grâce au bouton Configurer.
Pour Microsoft SQL Server
L'installation de SQL SERVER crée une source système appelée "LocalServer ". Il convient de configurer cette source en complétant les informations manquantes pour accéder à la base.
Pour Oracle
Il convient d'ajouter une source de données dans les sources système à partir du panneau de configuration.

Installation du runtime
Pour l'installation du runtime d'HARMONY FORTISSIMO consultez le manuel de référence d'HARMONY.
Le runtime d'HARMONY est nécessaire sur le serveur pour la création et la copie des fichiers dans SQL (utilitaire XPSQL.dhop), ainsi que pour d'éventuels travaux de maintenance.

Installation de XLANSQL

  1. Insérez le CD dans le lecteur.

  2. Le menu d'installation est affiché. Cliquez sur la ligne affichant le choix XLANSQL SERVEUR.

  3. Suivez les instructions d'installation.


XLANSQL est un service du serveur Windows. Il sera actif après le démarrage de l'ordinateur. XLANSQL utilise le protocole TCP/IP pour dialoguer avec le client. Il est à l'écoute des connexions TCP/IP sur le port 1235 par défaut. L'entrée " NumeroService " du chapitre [system] de Divalto.ini permet de changer le port en cas de conflit.
FHSQLDIVALTO
L'installation de XLANSQL copie le fichier paramètre FHSQLDIVALTO.dhfi dans le répertoire /Divalto/sys. Ce fichier contient la liste des fichiers de l'ERP Divalto susceptibles d'être exploités dans une base SQL. Il est copié par l'utilitaire XPSQL.dhop dans le répertoire /Divalto/ « nom de base SQL » sous le nom FHSQL.dhfi.
Mise à jour
Le fichier FHSQLDIVALTO.dhfi contient la liste actualisée des fichiers susceptibles d'être exploités dans une base SQL. . Le bouton « Mettre à jour la liste des fichiers » permet d'ajouter les nouveaux fichiers dans les paramètres des fichiers FHSQL.dhfi. Ce choix ne modifie pas les fichiers existants.

Configuration de la base SQL dans la table des serveurs
Sur le serveur, pour que XLANSQL 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.
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). 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

Remarque : Même sur le serveur l'accès à la base SQL par Harmony n'est possible qu'en mode client-serveur, il convient donc de configurer un client sur l'ordinateur du serveur pour accéder à la base de données par l'application ou l'utilitaire XPSQL.
Voir également : la configuration sur le poste client.


Création des utilisateurs d'Harmony
Lors de l'ouverture d'une session par un poste client, le serveur XLANSQL contrôle que l'utilisateur d'Harmony existe dans le fichier XLOG.dhfi du serveur. Le menu DIVALTO ou l'utilitaire XLOG1.dhop permettent de créer les utilisateurs d'Harmony.
Pour Microsoft SQL Server
Ce code utilisateur et son mot de passe seront utilisés pour la connexion au serveur SQL.
Pour Oracle
Le code utilisateur Harmony est contrôlé lors de la connexion au serveur, par contre il n'est pas utilisé pour la connexion à la base. Pour la connexion à la base XLANSQL utilise la code utilisateur correspondant au schéma Oracle. Celui-ci doit exister dans la table des utilisateurs du serveur XLANSQL avec le mot de passe de connexion au serveur.

Installation des fichiers de l'application
Avant de copier les fichiers dans la base SQL, ils doivent être présents sur le disque du serveur au format HARMONY. Pour cela vous devez les copier dans le répertoire /Divalto/ « nom de la base sql » (ou dans le répertoire correspondant au chemin SQL renseigné dans la table des serveurs) (par exemple /Divalto/ERPDivalto).
S'il s'agit d'une nouvelle installation d'une application de DIVALTO, utilisez l'installateur d'applications et copiez uniquement les fichiers dans ce répertoire (par exemple /Divalto/ERPDivalto).
Cette opération installe également les dictionnaires de données correspondants. Ceux-ci doivent être installés dans le répertoire /Divalto/ « nom de la base sql » (ou dans le répertoire correspondant au chemin SQL renseigné dans la table des serveurs) (par exemple /Divalto/ERPDivalto).
Voir également : Installation des dictionnaires de l'application.

Installation des dictionnaires de l'application
Le service XLANSQL utilise la description des tables et des index en provenance du (ou des) dictionnaire(s) de l'application. Il est indispensable d'installer les dictionnaires de données à jour sur le serveur. Par défaut, le service XLANSQL cherche les dictionnaires dans le répertoire /Divalto/ « nom de la base sql » (ou dans le répertoire correspondant au chemin SQL renseigné dans la table des serveurs) (par exemple /Divalto/ERPDivalto).. Si l'on souhaite mettre les dictionnaires dans un autre répertoire, il est indispensable de préciser le chemin complet du dictionnaire dans le paramètre "Nom du dictionnaire" par l'utilitaire XPSQL.
Pour les applications de l'ERP Divalto, les dictionnaires de données sont installés en même temps que les fichiers de données et dans le même répertoire. On installera donc les fichiers et les dictionnaires dans le répertoire /Divalto/ « nom de la base sql » (ou dans le répertoire correspondant au chemin SQL renseigné dans la table des serveurs) (par exemple /Divalto/ERPDivalto).
Remarque
En cas de mise à jour de l'application, si la description des fichiers est changée, il convient de se référer à la documentation de la mise à jour pour la procédure à suivre.
Voir également : Installation des fichiers de l'application.

Configuration d'un client XLAN sur le serveur
L'accès à la base de données ne peut être réalisé qu'en mode client-serveur. On utilisera donc le serveur "LocalHost" qui est automatiquement configuré lors de l'installation d'Harmony et qui désigne le serveur lui-même.
Remarque
XPSQL proposera automatiquement le nom de serveur "Localhost" pour le transfert vers la base SQL.

Création des tables SQL et copie des données
Avant propos.
Dans ce paragraphe nous verrons la démarche à suivre pour transférer des fichiers dans la base SQL. Ce transfert s'effectue avec l'utilitaire XPSQL.dhop. Les paramètres pour le transfert des applications Divalto disponibles sous SQL sont fournis en standard.
Le chapitre XPSQL traite de manière détaillée les fonctionnalités de cet utilitaire. Il permet de créer les paramètres pour vos propres applications, de tester la cohérence de vos descriptions de données, de créer et de transférer les informations vers les tables SQL. Il est conseillé de lire le chapitre consacré à XPSQL avant l'utilisation du logiciel.

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



Installation et mise en oeuvre sur un serveur IBM i
Introduction
XLAN Server i est un travail (job) qui s'exécute sur le serveur IBM i. Il réalise les fonctions suivantes :

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

Le travail XLAN est un job multi-thread. Pour chaque connexion client, un thread s'exécute sur le serveur. Le client dialogue avec le thread du serveur.
Le thread de supervision de XLAN assure la gestion des priorités. Il baisse automatiquement la priorité des threads demandant beaucoup de ressources au serveur.
L'installation d'une application peut être faite dans l'IFS du serveur. Le répertoire /divalto de l'IFS du serveur correspond au chemin Divalto. Il est possible de créer d'autres chemins sur le serveur pour stocker des fichiers à un autre endroit dans l'IFS du serveur.
Pour chaque base de données que l'on souhaite héberger sur le serveur, on créera un schéma dans la base DB2.
Le nouveau bouton « Choix du serveur » des outils de paramétrage des serveurs et des chemins d'Harmony permet de modifier ces paramètres directement sur le serveur.
XDivaltoLicencesiSeries permet de gérer les licences du serveur.
Le poste client est un client lourd sous Windows ou un serveur d'application sous Windows Server (TSE ou Citrix).


Etapes de l'installation
L'installation sur le serveur s'effectue en plusieurs étapes :

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


Installation de XLAN sur le serveur IBM i
Attention
Avant d'effectuer l'installation, veuillez lire le document Readme.doc à la racine du CD de XLAN for i, afin de vérifier les prérequis matériel et logiciel. Assurez-vous que votre serveur est compatible avec le produit XLAN for i et que les PTF nécessaires au bon fonctionnement de XLAN soient bien installées sur le serveur.
Prérequis du poste client
L'installation de XLAN sur le serveur IBM i s'effectue à partir d'un poste client. Le logiciel « IBM System i Access for Windows » doit être installé sur ce poste client.
Attention : En cas de mise à jour du serveur, ne pas installer le répertoire /divalto/sys de l'IFS. Vous écraseriez vos fichiers de configuration.
Installation à partir d'un PC par System i Navigator
Toutes les commandes d'installation se trouvent dans le fichier InstallationXLAN.sql à la racine du CD.

  1. Ouvrir une session dans System i Navigator avec le profil QSECOFR ou un profil disposant du droit spécial *ALLOBJ.

  2. Choisir "Exécution d'un script SQL" dans System i Navigator et ouvrir le script InstallationXLAN.sql

  3. Exécuter les 3 commandes de l'étape 1.

  4. Pour l'étape 2 FTP suivre les instructions du paragraphe "3.Transfert des fichiers vers l'IBM i par FTP" .

  5. Exécuter les commandes de l'étape 3.

Installation par une session 5250
Ouvrir une session 5250 avec le profil QSECOFR ou un profil disposant du droit spécial *ALLOBJ.
1. Création du profil utilisateur XLAN pour l'application XLAN for i
Créer le profil utilisateur XLAN avec la commande suivante :
CRTUSRPRF USRPRF(XLAN) PASSWORD() CCSID(1147) SPCAUT(*SERVICE)
Nb : le CCSID 1147 correspond au jeu de caractères pour une installation française.
2. Création des fichiers de sauvegarde (SAVF)
Créer deux fichiers de sauvegarde XLAN et DIVALTOSYS dans la bibliothèque QGPL, en utilisant les commandes suivantes :
CRTSAVF QGPL/XLAN
CRTSAVF QGPL/DIVALTOSYS
3. Transfert des fichiers vers le serveur IBM i par FTP
Transférer, en utilisant FTP, les fichiers XLAN.SAVF et DIVALTOSYS.SAVF de votre PC vers les fichiers de sauvegarde QGPL/XLAN et QGPL/DIVALTOSYS. Attention de ne pas oublier l'option bin.
Exemple :
C:\>FTP STN523P2
Connected to STN523P2.
220-QTCP at STN523P2.
220 Connection will close if idle more than 5 minutes.
User (STN523P2:(none)): qsecofr
331 Enter password.
Password:
230 QSECOFR logged on.
ftp> bin
200 Representation type is binary IMAGE.
FTP>cd QGPL
250 "QGPL" is current library
ftp> put xlan.savf xlan
200 PORT subcommand request successful.
150 Sending file to member XLAN in file XLAN in library QGPL.
226 File transfer completed successfully.
ftp: 11670912 bytes sent in 12,02Seconds 971,36Kbytes/sec.
ftp> put divaltosys.savf divaltosys
200 PORT subcommand request successful.
150 Sending file to member DIVALTOSYS in file DIVALTOSYS in library QGPL.
226 File transfer completed successfully.
ftp: 413952 bytes sent in 1,13Seconds 367,96Kbytes/sec.
ftp>quit
4. Restauration de la bibliothèque XLAN
Restaurer la bibliothèque XLAN à partir du fichier de sauvegarde QGPL/XLAN, en utilisant la commande suivante :
RSTLIB SAVLIB(XLAN) DEV(*SAVF) SAVF(QGPL/XLAN)
5. Restauration du répertoire DIVALTO/SYS ( Attention : uniquement pour une première installation)
Restaurer le répertoire DIVALTO/SYS, en utilisant la commande suivante :
RST DEV('/QSYS.LIB/QGPL.LIB/DIVALTOSYS.FILE') OBJ(('/divalto')) CRTPRNDIR(*YES)
6. Changement des droits du répertoire DIVALTO
Donner toutes les autorisations à l'utilisateur XLAN sur le répertoire DIVALTO/SYS, en utilisant la commande suivante :
CHGAUT OBJ('/Divalto') USER(XLAN) DTAAUT(*RWX) OBJAUT(*ALL) SUBTREE(*ALL)


Modification des paramètres du serveur
Le fichier /divalto/sys/config contient des paramètres permettant de dimensionner les capacités de traitement du serveur XLAN. Ces paramètres influent directement sur la taille de la mémoire qui sera allouée par le travail XLAN.
La modification des paramètres s'effectue par un éditeur de texte.
Le choix "Compteurs" de la console d'administration Divalto permet d'afficher les valeurs instantanées ainsi que les valeurs maximales atteintes par ces paramètres.
Attention : Une modification de ces paramètres n'est pas immédiatement répercutée, il faut redémarrer le travail XLAN.
La plupart des paramètres sont facultatifs et ont des valeurs par défaut.
Numero de Service (clé NumeroService)
Valeur par défaut : 1235
Ce paramètre représente le numéro de port d'écoute TCP/IP du serveur Xlan. En cas de conflit avec un service existant, il faut changer ce numéro. Dans ce cas, il faudra également changer la valeur sur les postes client.
Nombre maximum de threads XLAN (clé NbTaches).
Valeur par défaut : 16
Ce paramètre est indicatif et permet d'ajuster automatiquement les nombres maximums de réservations d'entité et d'enregistrement.
Sa valeur maximale est 2000.
Nombre maximum de fichiers ouverts par XLAN (clé NbFichiersParProcess).
Valeur par défaut : 10 000
Indiquez ici le nombre maximal de fichiers que le job XLAN est susceptible d'ouvrir simultanément (tous threads confondus).
On ne modifiera ce paramètre que si la valeur 10 000 est insuffisante. La valeur maximale de ce paramètre est 65 000.
Nombre maximum de fichiers séquentiels-indexés (clé NbFichiersIndexes).
Valeur par défaut : 200
Indiquez ici le nombre maximal de fichiers séquentiels indexés différents susceptibles d'être ouverts simultanément. Ce paramètre concerne l'ensemble des threads de XLAN. Un même fichier ouvert simultanément par plusieurs threads compte pour une seule unité. Ce paramètre doit être supérieur à 10.
Attention : On comptabilisera aussi dans ce paramètre le nombre de fichiers d'Harmony gérés dans la base DB2.
Nombre maximum d'autres fichiers (clé NbFichiersDivers).
Valeur par défaut : 40
Indiquez ici le nombre maximal de fichiers (non séquentiels indexés) différents susceptibles d'être ouverts simultanément. Ce paramètre concerne l'ensemble des threads de XLAN. Un même fichier ouvert simultanément par plusieurs tâches compte pour une seule unité. Ce paramètre doit être supérieur à 10.
Nombre de réservations d'enregistrement (clé NbReservEnreg).
Valeur par défaut : 2000
Indiquez ici le nombre maximal de réservations d'enregistrement susceptibles d'être faites simultanément. Le langage DIVA n'impose aucune limite au nombre de réservations mais il convient de ne pas saturer la table "système" associée. Ce paramètre concerne l'ensemble des tâches Harmony. Il doit être supérieur à 5 fois le nombre de tâches. Si les programmes ne réservent que quelques enregistrements simultanément, prenez comme valeur 10 fois le nombre de tâches.
Nombre de réservations d'entité (clé NbReservEntites).
Valeur par défaut : 200
Indiquez ici le nombre maximal de réservations d'entité susceptibles d'être faites simultanément. Les entités sont réservées par la fonction FSHARE du langage Diva. Ce paramètre concerne l'ensemble des tâches Harmony. Il doit être supérieur à 5 fois le nombre de tâches.

Démarrage du serveur XLAN
Pour lancer le module de contrôle d'accès aux bases (XLAN), utiliser l'une des deux commandes suivantes :
XLAN/STRXLAN
ou
SBMJOB CMD(CALL PGM(XLAN/XLAN)) JOB(XLAN) JOBD(XLAN/XLAN) USER(*JOBD) RTGDTA(*JOBD) INLLIBL(*JOBD)
Le profil utilisateur qui lance XLAN doit disposer du droit *USE sur le profil XLAN.
Si le profil U1 lance XLAN la commande sera :
GRTOBJAUT OBJ(QSYS/XLAN) OBJTYPE(*USRPRF) USER(U1) AUT(*USE)
Un travail du nom de XLAN doit s'activer dans le sous-système QUSRWRK. Le profil en cours doit être XLAN.
Chaque client DIVALTO qui se connecte lance un thread dans le travail XLAN. Ce sont ces threads qui se connectent aux différentes bases de DIVALTO, avec un profil utilisateur du nom de la base, via les travaux QSQSRVR. Ces derniers tournent dans le sous-système QSYSWRK.
Arrêt du serveur XLAN
Pour arrêter le module de contrôle d'accès aux bases (XLAN), vous pouvez :

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

Attention :
Cette opération est exceptionnelle. Il vaut mieux s'assurer que tous les utilisateurs sont déconnectés (voir les actions de l'utilitaire xconsole.dhop). L'arrêt "brutal" du service XLAN provoquera la déconnexion des utilisateurs ayant encore une session ouverte avec le serveur. Une perte des informations en cours d'écriture sur le serveur est probable.
NB : Après un arrêt de XLAN, il faut attendre 2 minutes avant de relancer XLAN.

Création des schémas dans la base DB2 et des profils utilisateur

Pour chaque base Harmony, il convient des créer sur le serveur IBM i :

  • 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

Exemple pour la base ERPDivalto
Create collection ERPDivalto;

Activation des licences concurrentes Divalto
Cette opération est facultative si le serveur IBM i n'est pas un serveur de licences pour Divalto.
Elle nécessite la connexion d'un lecteur réseau permettant d'accéder au répertoire Divalto de l'IFS du serveur.
L'activation des licences s'effectue par la commande XDivaltoLicenseiSeries.exe.
Cette opération est similaire à l'activation des licences sur un serveur Windows (voir la rubrique "Mise en oeuvre du système de licences" du manuel de référence Harmony), à ceci près qu'elle commence par la sélection du chemin du répertoire Divalto/Sys de l'IFS du serveur IBM i :

Il faut spécifier ici le chemin Windows permettant d'accéder au répertoire /divalto/sys de l'IFS su serveur IBM i.

Désinstallation des licences Divalto
La commande XDivaltoLicenseiSeries.exe permet également de désinstaller les licences d'un serveur. Ce choix fournit une clé de désinstallation.



Configuration de la source pour l'accès à la base par ODBC
Le programme de paramétrage XPSQL.dhop utilise l'interface standard ODBC pour créer les tables dans la base DB2 du serveur i. L'accès par ODBC nécessite la configuration d'une source de données. L'icône "ODBC" du panneau de configuration permet d'administrer les sources de données. Il convient d'ajouter une source de données dans les sources de données système avec le pilote "iSeries Access ODBC Driver" (on pourra nommer la source du nom du serveur par exemple), puis de la configurer grâce au bouton Configurer.

Le serveur XLAN utilise l'interface CLI pour accéder à la base DB2.

Configuration d'un client XLAN
L'accès à la base de données n'est réalisé qu'en mode client-serveur. Il convient donc de créer un serveur dans la table des serveurs des postes client, par le choix "Serveurs" du menu "Paramétrage" d'Harmony.dhop.
On garnira les champs suivants :

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



Configuration de la base SQL dans la table des serveurs
Il convient de configurer la ou les bases SQL à deux endroits :

  • 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



A la fin du paramétrage, une fenêtre demande la confirmation de la prise en compte immédiate des modifications sur le serveur.
Ceci a pour effet de mettre à jour la table des serveurs dans la mémoire du serveur IBM i. En cas de réponse négative à cette question, il faudra redémarrer le travail XLAN pour que la modification soit prise en compte. (ou effectuer un nouveau passage en modification de la table des serveurs et répondre par l'affirmative à la question).

Dans la table des serveurs du poste client servant au paramétrage du serveur.
Le bouton "Local" de la fenêtre "Choix du serveur" permet de configurer la table des serveurs du poste local.
On créera une entrée identique à celle de la table des serveurs du serveur IBM i sur le poste local servant au paramétrage du serveur.



Installation des fichiers de l'application
Avant de copier les fichiers dans la base SQL, ils doivent être présents sur le disque du serveur au format HARMONY. Pour cela, vous devez les copier dans le répertoire /Divalto/ « nom de la base sql » du serveur (ou dans le répertoire correspondant au chemin SQL renseigné dans la table des serveurs) (par exemple //ServeurSQL/Divalto/ERPDivalto).
S'il s'agit d'une nouvelle installation d'une application de DIVALTO, utilisez l'installateur d'applications et copiez uniquement les fichiers dans ce répertoire (par exemple //ServeurSQL/Divalto/ERPDivalto).
Cette opération installe également les dictionnaires de données correspondants. Ceux-ci doivent être installés dans le répertoire /Divalto/ « nom de la base sql » du serveur (ou dans le répertoire correspondant au chemin SQL renseigné dans la table des serveurs) (par exemple //ServeurSQL/Divalto/ERPDivalto).

Installation des dictionnaires de données de l'application
Le travail XLAN utilise la description des tables et des index en provenance du (ou des) dictionnaire(s) de l'application. Il est indispensable d'installer les dictionnaires de données à jour sur le serveur. Le travail XLAN cherche les dictionnaires dans le répertoire /Divalto/ « nom de la base sql » (ou dans le répertoire correspondant au chemin SQL renseigné dans la table des serveurs) (par exemple /Divalto/ERPDivalto).
Pour les applications de l'ERP Divalto, les dictionnaires de données sont installés en même temps que les fichiers de données et dans le même répertoire. On installera donc les fichiers et les dictionnaires dans le répertoire /Divalto/ « nom de la base sql » du serveur (ou dans le répertoire correspondant au chemin SQL renseigné dans la table des serveurs) (par exemple //ServeurSQL/Divalto/ERPDivalto).
Remarque
En cas de mise à jour de l'application, si la description des fichiers a changé, il convient de se référer à la documentation de la mise à jour pour la procédure à suivre.

Création des utilisateurs Harmony
Lors de l'ouverture d'une session par un poste client, le serveur XLANSQL contrôle que l'utilisateur d'Harmony existe dans le fichier XLOG.dhfi du serveur. Le menu DIVALTO ou l'utilitaire XLOG1.dhop permettent de créer les utilisateurs d'Harmony.
Le bouton "Choix du serveur" de XLOG1 permet de sélectionner le serveur IBM i.
Pour une création des utilisateurs par le menu Divalto, il faudra avoir au préalable renseigné le paramètre "ServeurXlog" du chapitre [system] par xDivaltoMajini.
Utilisateur pour la connexion à la base
Pour la connexion à la base, XLAN utilise le code utilisateur correspondant au schéma DB2. Celui-ci doit exister dans la table des utilisateurs du serveur XLAN avec le mot de passe de connexion au serveur.
Voir : Création du schéma dans la base DB2

Paramétrage de la chaîne de connexion CLI
Le serveur XLAN utilise l'interface CLI (Call Level Interface) pour accéder à la base DB2.
Cette interface nécessite une connexion à la base. La chaîne de connexion à fournir lors de cette connexion est paramétrable.
Dans la chaîne de connexion les paramètres suivants désignent :

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

Voir : Création des utilisateurs Harmony et Création du schéma dans la base DB2


Création des tables SQL et copie des données
Avant propos.
Dans ce paragraphe, nous verrons la démarche à suivre pour transférer des fichiers dans la base SQL. Ce transfert s'effectue avec l'utilitaire XPSQL.dhop. Les paramètres pour le transfert des applications Divalto disponibles sous SQL sont fournis en standard.
Le chapitre XPSQL traite de manière détaillée les fonctionnalités de cet utilitaire. Il permet de créer les paramètres pour vos propres applications, de tester la cohérence de vos descriptions de données, de créer et de transférer les informations vers les tables SQL. Il est conseillé de lire le chapitre consacré à XPSQL avant l'utilisation du logiciel.

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



Synchronisation du schéma de la base
L'administrateur du System i doit préalablement exécuter la commande suivante :
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).

Installation et mise en oeuvre sur un poste client
Configuration du serveur SQL.
Chemins implicites de l'utilisateur

Configuration du serveur SQL
On crée un serveur dans la table des serveurs des postes client par le choix "serveurs" du menu "paramétrage" d'Harmony.dhop.
On garnira les champs suivants :

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

Voir également : la configuration sur le serveur.


Chemins implicites de l'utilisateur
Par XPATH.dhop, ajoutez un chemin implicite à tous les utilisateurs (ou dans le fichier des chemins implicites par défaut) vers le serveur SQL. Dans notre exemple //ServeurSql/ERPDivalto, où :

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


Voir également : la configuration sur le serveur.

XPSQL utilitaire
L'utilitaire XPSQL doit impérativement être exécuté sur le serveur où le service XLANSQL est actif et où se trouve le serveur de base de données SQL.
Il permet de créer, modifier ou supprimer la fiche paramètre des fichiers transférés dans une base de données SQL. Il permet en outre de tester la connexion au serveur SQL ainsi que la cohérence de vos descriptions de données dans le dictionnaire avant le transfert, de créer et de transférer les informations vers les tables SQL, d'extraire les informations des tables SQL vers un fichier Harmony.
Il permet également de définir le type de serveur SQL, le nom de la base de données, ainsi que le nombre de décimales variables pour chaque base.
Le fichier paramètre FHSQL.dhfi contient la liste des fichiers à gérer dans la base SQL.
Pour chaque base de données sous SQL, il y a sur le serveur un répertoire correspondant à la base de données sous le répertoire Harmony. Il porte impérativement le nom de la base de données. Il contient :

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


XPSQL est en fait un zoom sur le fichier FHSQL et permet donc de faire toutes les opérations du zoom sur un fichier (pour le fonctionnement détaillé du zoom voir la documentation en ligne du zoom dans XPSQL).
Dans la suite de ce chapitre nous verrons :

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


Voir également :
Paramètres généraux de XPSQL.
Paramètres d'un fichier.
Application.
Actions.
Connexion au serveur SQL
Audit.
Création des tables.
Copie des fichiers.
Extraction des fichiers.
Erreurs les plus courantes

Paramètres généraux de XPSQL
Choix du type de serveur
XLANSQL est prévu pour accéder à divers type de serveurs. Le bouton "Serveur SQL" permet de choisir le fournisseur du serveur. La version actuelle traite les bases Microsoft SQL SERVER et Oracle. Voir les documentations commerciales pour les versions supportées. Ce bouton permet aussi, le cas échéant, de mettre en oeuvre l'Option de connexion Mars.
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.
Pour chaque base de données, il faut sur le serveur sous le répertoire Harmony un répertoire portant le nom de la base de données avec :

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


Mettre à jour la liste des fichiers
Ce bouton de la barre des boutons permet d'ajouter les fichiers susceptibles d'être exploités sous SQL dans le Fhsql.dhfi à partir du modèle FhsqlDivalto.dhfi.. Ce choix ne modifie pas les fichiers existants.
Décimales variables.
Harmony permet de définir des nombres de décimales variables pour les valeurs numériques. Par exemple, dans certains pays les montants s'expriment avec trois décimales, en gestion les quantités peuvent s'exprimer avec 0, 1, 2 ou n décimales selon la nature de l'objet.
Diva peut gérer jusque 10 types de décimales variables. Cette définition s'effectue par classe (10 classes en tout). Pour chaque classe on indique le nombre de décimales pour les nombres de cette classe. Dans le dictionnaire de données, lors de la définition d'un champ de nature "Numérique,D" on indique à quelle classe il appartient.
Le bouton "Décimales" de XPSQL permet de paramétrer le nombre de décimales pour chacune des classes dans la base SQL. Ce paramètre est pris en compte lors de la création des tables dans la base SQL.
Attention
Contrairement au fonctionnement avec un fichier Harmony, le nombre de décimales d'une classe est fixe pour une colonne donnée d'une table et sa valeur doit être connue lors de la création des tables.


Paramètres d'un fichier
Le serveur XLANSQL, à l'ouverture d'un fichier sur le serveur SQL charge ses paramètres depuis le fichier FHSQL.dhfi du répertoire correspondant à la base SQL. S'ils n'existent pas ou si l'enregistrement paramètre n'est pas valide, XLANSQL renvoie un code erreur fichier absent.
Dans la fiche paramètre, XLANSQL trouve les informations suivantes :

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



Application
Dans la fiche paramètres d'un fichier, on indique l'application à laquelle il appartient. 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.
Pour les applications Divalto, les paramètres des fichiers de base sont fournis par application. Par défaut, les paramètres ne sont pas valides. Pour un transfert complet d'une application, on se positionnera sur un des fichiers de l'application et on l'activera avec le bouton "Validation/Invalidation". Si l'on décide de faire un transfert partiel des fichiers de l'application dans la base SQL, il suffit de valider les fiches paramètres des fichiers que l'on souhaite transférer.
En cas de mise à jour, le fichier paramètre FHSQL n'est pas copié sur le disque. L'installateur copie le fichier paramètres modèle (FhsqlDivalto) dans le répertoire /divalto/sys. Le bouton "Mettre à jour la liste des fichiers" effectue la mise à jour des fichiers à partir du modèle.

Actions

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


Option de connexion Mars
Microsoft Sql Server comporte une option de connexion, intitulée MARS (Multiple Active Result Sets) et permettant d'améliorer significativement les temps de parcours d'un curseur (lecture séquentielle).
Par contre, cette option ne permet pas d'utiliser un curseur dynamique, comme c'est le cas actuellement pour les lectures par le service XLAN. Elle risque donc d'engendrer des incompatibilités pour certains traitements. En effet, les nouvelles lignes créées, modifiées ou supprimées après la requête SQL restent visibles lors du parcours d'un curseur dynamique, alors qu'avec l'option MARS, elles ne le sont pas forcément.
Le mode de fonctionnement avec l'option MARS est toutefois identique à celui utilisé par un RecordSQL. Cette différence ne devrait donc pas poser de problème.
Par mesure de précaution, cette option n'est pas activée par défaut mais elle peut être mise en œuvre au cas par cas.
Pour cela, il faut ajouter "mars_connection=yes" à la chaîne de connexion au serveur SQL, de la manière suivante :
Après l'appel à XPSQL, cliquez sur le bouton "Serveur SQL" et modifiez le champ Source ODBC.
Par exemple :
DSN=ERP210;Description=ERP210;UID=;Trusted_Connection=Yes;WSID=PSXBDTL01;DATABASE=ERP210;mars_connection=yes
De plus, lorsque l'option est active, elle peut être ponctuellement désactivée pour les programmes pour lesquels elle générerait une incompatibilité.
Pour cela, spécifiez la liste des programmes pour lesquels l'option MARS ne doit pas être activée dans le fichier paramètre /divalto/sys/mars.txt.
Le fichier comporte une ligne par programme contenant son nom suivi de l'extension .dhop.
Par Exemple :
monProgram.dhop
Ce fichier paramètres est lu au démarrage du serveur Xlan.

Connexion au serveur SQL
La plupart des actions réalisées par XPSQL nécessitent une connexion avec le serveur SQL.
XLANSQL utilise l'interface standard ODBC pour l'accès à la base SQL, notamment pour la connexion à la base. Pour chaque session, XLANSQL utilise le code de l'utilisateur HARMONY et son mot de passe du fichier XLOG.dhfi du serveur. L'utilitaire XPSQL permet de simuler la connexion à la base SQL. Il stocke une chaîne de caractères génériques contenant les informations pour la connexion à la base SQL dans le fichier paramètre FHSQL.
Lors de la première connexion au serveur, XPSQL ouvre la boîte de dialogue permettant de choisir la source de données. On choisira la source correspondante à la base dans l'onglet " Source de données machine ".

Le choix " Je veux me connecter en appelant la boîte de dialogue SQL pour changer de source " permet de changer la source de données en cas d'erreur.
Rappel
La source de données doit être configurée au préalable. Voir Configuration de la source ODBC.
Attention pour SQL Server,
Lorsque l'on gère plusieurs bases, on vérifiera que la chaîne de connexion correspond bien à la base choisie.

Particularité pour DB2 sur un serveur i.
Pour la gestion d'une base DB2 sur un serveur i, il y a en fait deux chaînes de connexion différentes :

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


Voir aussi : Option de connexion Mars.

Audit
La fonction d'audit doit être utilisée principalement lors du paramétrage d'un nouveau fichier à transférer dans la base SQL. Cette fonction effectue de nombreuses opérations de test, notamment de connexion à la base et de cohérence de la description du fichier dans le dictionnaire. Elle n'effectue pas de mise à jour de la base de données. On exécutera ce choix fichier par fichier plutôt que pour une application complète.
Les tests effectués par l'audit :
La validation du choix de l'audit déroule les tests suivants, soit pour un seul fichier (choix conseillé), soit pour tous les fichiers d'une application.
Pour chaque enregistrement d'un fichier :
Test des chevauchements de données :
XPSQL vérifie dans le dictionnaire de données s'il y a des chevauchements de données (redéfinition ou découpage). Pour chaque donnée concernée, il indique quelle donnée est chevauchée.
Index :
XPSQL contrôle que la description des clés du dictionnaire correspond effectivement aux clés du fichier. Pour cela XPSQL compare la description des clés du dictionnaire avec les clés réelles du fichier sous Harmony. Le paramètre "Chemin du fichier de référence pour la comparaison des clés" permet d'indiquer le chemin où se trouve le fichier Harmony. Il est indispensable d'indiquer ce chemin.
Enregistrement et données :
XPSQL contrôle que les noms de données ne correspondent pas à des mots réservés du langage SQL.

Création des tables
Ce choix permet de créer les tables dans la base SQL. Il enchaîne à la copie des fichiers dans la base.
Lorsque l'opération s'applique à une sélection de fichiers, XPSQL valide automatiquement l'ensemble des fichiers sélectionnés.

Attention
Si les tables existent déjà dans SQL, elles sont supprimées et toutes les données existantes sont perdues.
.
Voir également :


Copie des fichiers
Ce choix permet de copier un fichier HARMONY dans la base SQL. Il demande :

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

Lorsque la copie est lancée " par application " le mode " pas à pas " permet d'intervenir dans le déroulement du transfert fichier par fichier.
Exemple :
Chemin d'origine : /Divalto/ERPDivalto
Chemin de destination //ServeurSQL/ERPDivalto


Filtrage des tables à l'import
Il est possible de ne pas transférer (et donc de ne pas effacer) des tables lors de la copie des données vers SQL.
Pour cela, il faut, dans le répertoire de la base, créer un fichier "excludeimport.txt" (excludeimportu.txt pour la plateforme cloud).
Dans ce fichier, il faut indiquer les couples dictionnaire / fichier / table pour chaque table à ignorer. Il y a un couple par ligne.
Exemple :
gtfdd.dhsd;gtfat.dhfi;art;
gtfdd.dhsd;gtfdos.dhfi;ets;
Note : les points-virgules sont obligatoires, même le dernier, celui après le nom de la table.
Dans la fenêtre de compte-rendu, le texte suivant s'affiche si une ou plusieurs tables ont été ignorées : "Des tables ont été exclues de la copie des données".


Remarques : - Avant la version 2018-403 d'Harmony, la copie d'un fichier contenant un champ de type Blob n'est pas possible. Maintenant, la copie avec l'option effacement requiert le fichier .blob correspond à la table. Ce fichier est créé lors de l'extraction des données.

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


Extraction des données depuis SQL
Ce choix permet d'extraire les tables depuis SQL vers un fichier Harmony. Il demande :

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


Contrôle d'intégrité des fichiers Harmony
Avant le transfert de fichiers Harmony existants vers une base de données, il est fortement recommandé d'effectuer un contrôle d'intégrité des fichiers. Le lancement du contrôle d'intégrité est disponible directement depuis l'utilitaire XPSQL. Le contrôle s'applique aux fichiers sélectionnés valides.

Pilotage des imports et des exports
Performance
Ces choix permettent d'accélérer sensiblement la copie de fichiers Harmony volumineux vers ou depuis une base de données. Pour cela, il faut que les fichiers Harmony et la base de données soient hébergés sur le même serveur. Dans ce cas, les utilitaires d'import et export ne font pas transiter les données copiées par le réseau local.
Ces choix sont donc particulièrement intéressants lors de la migration de fichiers volumineux vers une base de données.
Tout comme xpsql, ces utilitaires contrôles la version des fichiers, et prennent en compte l'exclusion de tables lors de la copie des données vers SQL.
Utilitaires
L'utilitaire XpsqlImport.dhop permet d'importer des fichiers Harmony vers une base SQL.
L'utilitaire XpsqlExport.dhop permet d'exporter une base SQL vers des fichiers Harmony.
Génération des fichiers de pilotage
Le bouton « Piloter Import/Export » permet de générer un fichier de pilotage des importations ou des exportations de fichiers Harmony.
La liste des fichiers à importer ou à exporter correspond à l'ensemble des fichiers sélectionnés valides.
Les fichiers de pilotage, respectivement pilimport.txt pour un import et pilexport.txt pour un export, sont générés dans le répertoire /divalto/« base sql ».
Exemple de pilotage généré
XsqlImport
\\LocalHost\divalto\erpdivalto\gtfoftrc.dhfd
\\LocalHost\erpdivalto\gtfoftrc.dhfi
Importation ou exportation des fichiers
Pour effectuer l'importation ou l'exportation des fichiers, il convient d'exécuter le fichier de commandes =pilimport.txt ou =pilexport.txt.
Les fichiers feventxpsql.log et ferrorxpsql.log contiennent respectivement les comptes-rendus des transferts et des erreurs.
Pilotage via ping
Ces deux utilitaires peuvent également être piloté via ping :

  • « 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

Exemple :
Ping (« Harmony », « \\LocalHost\divalto\erpdivalto\gtfoftrc.dhfi »)
Ping (« SQL », « \\Localhost\erpdivalto\gtfoftrc.dhfi »)
ProgramCall (« xsqlimport.dhoq », , CALL_WAIT)
Remarque : Lorsque le programme est piloté via ping, les fichiers générés sont comprimés en .dhzi.

Erreurs les plus courantes
Les erreurs renvoyées par la base SQL.
Les erreurs renvoyées par SQL comportent :

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


Type de données incorrect.
Les données de la base sont typées. Le moteur de base de données vérifie la cohérence des informations écrites dans la base. Les données numériques doivent être numériques et ne pas dépasser la capacité prévue, les dates doivent être correctes.
Avant d'écrire dans la base, XLANSQL effectue une affection numérique des données numériques (ce qui a pour effet d'éliminer les caractères non numériques) et contrôle les dates (une date erronée est remplacée par le 1/1/1753 sous SQL server). Dans le cas d'une date erronée, XLANSQL écrit un message d'erreur dans le journal des événements de Windows, mais laisse l'application poursuivre son déroulement normal. Il arrive néanmoins que les données écrites soient rejetées par le moteur de la base de données. Dans ce cas le message d'erreur sera celui renvoyé par la base de données.
Le journal des événements de Windows.
En cas d'erreur, XLANSQL renvoie un code d'erreur. Il écrit également un message en clair dans le journal des événements des applications de Windows. Pour les erreurs d'exécution des requêtes SQL, XLANSQL écrit le source de la requête dans ce journal, ainsi que le message d'erreur renvoyé par le moteur de la base de données.
Fichier log de XPSQL.
L'utilitaire XPSQL consigne dans le fichier DHOdbcConfigSQL.log le déroulement des actions d'une session. On y trouvera notamment les erreurs lors du transfert des fichiers HARMONY vers la base. Attention ce fichier est effacé à chaque session de XPSQL.

Synchronisation du schéma de la base

Installation (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>_oldchamp.
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.






Exécution de scripts


Description
Une autre fonctionnalité de l'utilitaire xpsqlsynchro.dhop est la possibilité d'exécuter des scripts SQL de migration ou de mise à jour.
L'utilitaire est accessible depuis le menu « Synchronisation », choix « Exécuter un script ».
L'exécution de scripts peut également être appelée en-dehors de l'utilitaire xpsql.dhop : il faut simplement appeler le programme « xpsqlsynchro.dhop » et lui envoyer par "ping" les paramètres suivants :

  • « 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.



Syntaxe du fichier
Le fichier passé DOIT commencer par « <execute> ».
A la fin du fichier, on trouve « <executeDropOldColumns> ».
Les instructions qui suivent permettent de supprimer les tables suffixées par « _oldcolumns »
Ces tables sont issues d'une synchronisation réussie avec des suppressions de champs. Elles ne sont exécutées quei si le paramètre « SupprimerTableSauvegarde » vaut 1 ou si la case « Supprimer les tables de sauvegarde des champs supprimés » est cochée (Cf. rubrique Description de la synchronisation du schéma de la base).
La syntaxe du fichier contenant le script dépend du moteur de base de données :

  1. 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).

  2. Oracle. Pour Oracle, c'est PL/SQL qu'il faut utiliser (http://www.oracle.com/technology/tech/pl_sql/index.html).

  3. 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).



Exemple de script SQL Microsoft
<execute>
USE <BASESQL> ;
/* Requête simple pour récupérer la valeur d'un ancien champ */
/* substring sert à tronquer la valeur car le nouveau champ est plus court que l'ancien */
update dbo.soc set chemincod = (select substring(o.winchn, 0, 20) from dbo.soc_oldcolumns o where o.soc_id = dbo.soc.soc_id);
/* Requête avec un test utilisant un curseur */
/* Déclaration des variables et des curseurs */
DECLARE @mres_id int;
DECLARE @n_ce4 char(1);
DECLARE @resqte numeric(12,3);
DECLARE c_mres CURSOR FOR
select mres_id, resqte from dbo.mres order by mres_id;
/* Mise à jour avec parcours d'un curseur */
open c_mres;
fetch next from c_mres into @mres_id, @resqte;
while @@fetch_status = 0
begin
/* positionne ce4 en fonction de resqte */
if @resqte != 0
set @n_ce4 = 1;
else
set @n_ce4 = 0;
update dbo.mres set ce4 = @n_ce4 where mres_id = @mres_id;
fetch next from c_mres into @mres_id, @resqte;
end
/* Suppression des tables suffixées par "_oldcolumns" */
<executeDropOldColumns>
DECLARE @table_name sysname;
DECLARE cur_table CURSOR FOR
SELECT name FROM sysobjects WHERE type='U' and lower(name) like '%_oldcolumns';
open cur_table;
fetch next from cur_table
into @table_name;
while @@fetch_status = 0
begin
exec('DROP TABLE dbo.' + @table_name);
fetch next from cur_table
into @table_name;
end
close cur_table;
deallocate cur_table;

Exemple de script ORACLE
<execute>
/* Déclaration des variables et des curseurs */
DECLARE
n_ce4 char(1);
mres_id int;
resqte int;
CURSOR c_mres IS select mres_id, resqte from <BASESQL>.mres ORDER BY mres_id;
BEGIN
/* Requête simple pour récupérer la valeur d'un ancien champ */
/* substr sert à tronquer la valeur car le nouveau champ est plus court que l'ancien */
/* pour le substr d'oracle, le <start_position> (2ème paramètre) commence à 1 */
UPDATE <BASESQL>.soc SET chemincod = (SELECT substr(o.winchn, 1, 20) FROM <BASESQL>.soc_oldcolumns o WHERE o.soc_id = <BASESQL>.soc.soc_id);
COMMIT;
/* Requête avec un test utilisant un curseur */
OPEN c_mres;
LOOP
FETCH c_mres INTO mres_id, resqte;
EXIT WHEN c_mres%NOTFOUND;
/* positionne ce4 en fonction de resqte */
IF resqte != 0 THEN
n_ce4 := 1;
ELSE
n_ce4 := 0;
END IF;
EXECUTE IMMEDIATE('update <BASESQL>.mres set ce4 = ' || n_ce4 || ' where mres_id = ' || mres_id);
END LOOP;
COMMIT;
CLOSE c_mres;
/* Suppression des tables suffixées par "_oldcolumns" */
<executeDropOldColumns>
DECLARE
table_name user_tables.table_name%TYPE;
CURSOR cur_table IS SELECT table_name FROM user_tables where lower(table_name) like '%_oldcolumns';
BEGIN
OPEN cur_table;
LOOP
FETCH cur_table INTO table_name;
EXIT WHEN cur_table%NOTFOUND;
EXECUTE IMMEDIATE('DROP TABLE <BASESQL>.' || table_name);
END LOOP;
COMMIT;
CLOSE cur_table;
END;

Exemple de script IBM DB2
<execute>
/* Requête simple pour récupérer la valeur d'un ancien champ */
/* substring sert à tronquer la valeur car le nouveau champ est plus court que l'ancien */
/* Création de la procédure */
CREATE PROCEDURE <BASESQL>.proc_migration
LANGUAGE SQL
BEGIN
UPDATE <BASESQL>.soc SET chemincod = (SELECT substring(o.winchn, 0, 20) FROM <BASESQL>.soc_oldcolumns o WHERE o.soc_id = <BASESQL>.soc.soc_id);
end
<execute>
/* Lancement de la procédure */
call <BASESQL>.proc_migration()
<execute>
/* Suppression de la procédure */
drop procedure <BASESQL>.proc_migration
<execute>
/* Création de la procédure avec parcours de curseur */
/* Requête avec un test */
CREATE PROCEDURE <BASESQL>.proc_migration
LANGUAGE SQL
BEGIN
declare mres_id integer;
declare resqte numeric(12,3);
declare n_ce4 char(1);
declare req_sql varchar(150); /* adapter la taille de la variable en fonction de la requête */
declare sqlcode integer default 0;
DECLARE c_mres CURSOR FOR
select mres_id, resqte from <BASESQL>.mres order by mres_id;
open c_mres;
fetch from c_mres into mres_id, resqte;
while (SQLCODE=0) DO
/* positionne ce4 en fonction de resqte */
if resqte != 0 then
set n_ce4 = 1;
else
set n_ce4 = 0;
end if;
set req_sql = 'update <BASESQL>.mres set ce4 = ' || n_ce4 || ' where mres_id = ' || mres_id;
EXECUTE IMMEDIATE req_sql;
fetch from c_mres
into mres_id, resqte;
end while;
close c_mres;
end
<execute>
call <BASESQL>.proc_migration()
<execute>
drop procedure <BASESQL>.proc_migration
<execute>
/* Suppression des tables suffixées par "_oldcolumns" */
<executeDropOldColumns>
CREATE PROCEDURE <BASESQL>.proc_migration
LANGUAGE SQL
BEGIN
DECLARE table_name varchar(128);
DECLARE sqlcode INTEGER DEFAULT 0;
DECLARE req_sql varchar(150);
DECLARE cur_table CURSOR FOR SELECT table_name FROM qsys2.systables where lower(table_name) like '%_oldcolumns' and lower(table_owner) = lower('<BASESQL>');
open cur_table;
fetch from cur_table into table_name;
WHILE (SQLCODE=0) DO
set req_sql = 'drop table <BASESQL>.' || table_name;
EXECUTE IMMEDIATE req_sql;
FETCH cur_table into table_name;
END WHILE;
close cur_table;
END
<execute>
call <BASESQL>.proc_migration()
<execute>
drop procedure <BASESQL>.proc_migration
<execute>

Déclaration des index dans le dictionnaire
Introduction
Le dictionnaire de données décrit pour chaque table les index permettant d'y accéder. Un index est caractérisé par une lettre clé utilisée par les programmes afin de préciser le choix du ou des index à utiliser pour accéder aux tables.
La gestion de fichiers d'Harmony est particulièrement riche au niveau des fonctionnalités apportées par les index. Notamment une même lettre clé peut permettre d'accéder à plusieurs tables différentes ou peut être définie plusieurs fois avec des compositions différentes ou encore peut porter de manière sélective sur certaines lignes particulières d'une table. Ces fonctionnalités n'existent pas directement dans les index classiques d'une base de données SQL où chaque index ne permet d'accéder qu'à une seule table unique, ne comporte qu'une seule description et accède de manière inconditionnelle à toutes les lignes d'une table.
Pourtant ces fonctionnalités des index de la gestion de fichiers d'harmony peuvent être apportées facilement et de manière complètement transparente grâce à des tables intermédiaires. Ces tables intermédiaires sont alimentées automatiquement par les déclencheurs opérant sur les tables de base.
Exemples

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


Les types d'index
Lors de la description d'un index dans le dictionnaire de données, le paramètre type d'index SQL permet de définir comment l'index d'Harmony doit être traité dans le cas d'une utilisation avec un serveur SQL. La suite de ce chapitre décrit les différents types d'index pris en compte.


Les déclencheurs
Un déclencheur (en anglais trigger) est une procédure stockée SQL qui est automatiquement exécutée par le moteur SQL lors de la mise à jour d'une table (requêtes insert, update ou delete). Elle s'exécute avec la mise à jour de la table dans le cadre d'une transaction, c'est à dire que si l'opération effectuée par le déclencheur n'aboutit pas, la mise à jour de la table n'est pas non plus effectuée. Ceci permet de garantir l'intégrité référentielle de la base de données.
Lors de la création des tables dans SQL par XPSQL.dhop, celui-ci crée automatiquement les tables intermédiaires nécessaires ainsi que les déclencheurs pour les alimenter. Une mise à jour directe d'une table par une requête SQL met également à jour les tables intermédiaires de manière tout à fait automatique et transparente.

Index normal
Pour un fichier Harmony, lorsqu'une lettre clé donnée permet d'accéder à une table et une seule, l'index peut-être déclaré de type normal. Il devient un simple index dans la base SQL avec pour composition les champs décrits dans le dictionnaire.
Il peut être éventuellement soumis à une condition. Plusieurs cas doivent alors être envisagés :

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

Exemple 1
L'index "Index_A" du fichier GTFSTA de Divalto Achat-Vente permet d'accéder exclusivement à la table STA. Le code condition CE1 correspond à l'identifiant de la table STA.
Exemple 2
L'index "Index_A" du fichier CCFTSC de Divalto Comptabilité permet d'accéder exclusivement à la table CS. Il ne comporte aucune condition particulière.

Index multi-tables
Pour un fichier Harmony, lorsqu'une même lettre clé permet d'accéder à plusieurs tables différentes l'index peut-être déclaré de type multi-tables. Plusieurs cas sont à envisager :

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


Exemple
Pour le fichier GTFPCF de Divalto Achat-Vente, la lettre clé 'A' permet d'accéder aux clients, aux prospects, aux fournisseurs, aux autres tiers et aux représentants. La description de l'index est la même pour toutes les tables. Une table intermédiaire est automatiquement créée dans la base SQL (la table des "Tiers" avec une nature de tiers et une référence à la table du tiers correspondant).

Index avec identifiant
Pour un fichier Harmony, lorsqu'une même lettre clé permet d'accéder à plusieurs tables différentes et que l'index inclut l'identifiant de la table à laquelle il permet d'accéder, l'index peut-être déclaré de type avec identifiant.
Avantages

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


Incompatibilité
Cependant, il y a deux différences majeures dans l'utilisation des index avec identifiant au niveau de la programmation qui peuvent nécessiter une adaptation des programmes qui les utilisent.

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

Exemple
Pour le fichier GTFTAB de Divalto Achat-Vente, la lettre clé 'A' permet d'accéder à toutes les tables de paramètres du fichier (Libellés des familles de tarif, mode de règlements, taux de tva, etc…). L'index contient l'identifiant de la table à laquelle il permet d'accéder. L'application positionne toujours l'identifiant dans la clé avant un accès.

Index multi-descriptions
Pour un fichier Harmony, lorsqu'une même lettre clé permet d'accéder à une seule table, mais que cette lettre clé est utilisée dans plusieurs index avec des descriptions différentes mais homogènes, l'index peut-être déclaré de type multi-descriptions.
Pour cet index, XLANSQL gère une table intermédiaire contenant les champs de l'index de référence et pointant sur les lignes correspondantes de la table de base.
Descriptions homogènes
"Descriptions différentes mais homogènes" signifie que les champs qui composent chaque index avec la même lettre clé sont différents, mais que chaque index comporte le même nombre de champs et que chacun des champs a la même nature (alphanumérique, numérique,…) et la même longueur dans tous les index. Les descriptions des clés différentes mais non homogènes ne sont pas prises en compte par XLANSQL et constituent une incompatibilité totale.
Référence pour la table intermédiaire
Pour les index de type multi-descriptions, le paramètre "Référence pour la table intermédiaire" doit être coché pour un et un seul des index de la lettre clé considérée. Cette description sera utilisée pour la création de la table intermédiaire
Exemple
Pour le fichier GTFSTAT de Divalto Achat-Vente, la lettre clé 'K' permet d'accéder à la table STA. Cette table contient un tableau de trois codes représentant. La lettre 'K' est utilisée par trois index de description homogène, chacune avec un des trois codes représentant. Le premier index est défini comme "référence pour la table intermédiaire". XLANSQL gère automatiquement la table intermédiaire des statistiques de ventes par représentant.

Index conditionnel
Pour un fichier Harmony, lorsqu'une lettre clé permet d'accéder à une table et une seule et que le code condition définit un sous-ensemble de la table, l'index peut-être déclaré de type conditionnel.
XLANSQL gère une table intermédiaire avec les champs de l'index pour les lignes qui répondent à la condition.
Exemple
La table C8 du fichier CCFDCE de Divalto Comptabilité contient des écritures "non lettrées" pour lesquels le condition Ce4 est égal à 1. Les écritures "non lettrées" constituent un sous-ensemble de l'ensemble des écritures. L'index "index_D_C8" permet d'accéder spécifiquement aux écritures "non lettrées". XLANSQL gère automatiquement une table des écritures "non lettrées" pour cet index.

Restrictions
L'interface d'HARMONY avec une base SQL permet théoriquement d'utiliser une application conçue avec les fichiers séquentiels-indexés d'Harmony et de l'exécuter après avoir transféré les données dans une base SQL. Cependant il existe quelques contraintes et incompatibilités. Elles sont de quatre ordres :

  • Celles dues à la base de données.

  • Celles dues à Harmony.

  • Les incompatibilités totales.

  • La gestion des réservations.

Elles peuvent éventuellement empêcher le fonctionnement de l'application, notamment pour les incompatibilités totales et si la taille maximum des enregistrements dépasse la taille autorisée par la base de données.
Voir également :
Contraintes liées à la base SQL
Contraintes liées à Harmony
Incompatibilités
Gestion des réservations
Conseils pour une intégration optimale avec SQL.

Contraintes liées à la base SQL

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


Pour Microsoft SQL Server

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


Contraintes liées à Harmony

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


Incompatibilités
Elles sont d'importances diverses et peuvent aller jusqu'à l'impossibilité de faire fonctionner l'application.

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


Gestion des réservations
La gestion des réservations des enregistrements, ainsi que la gestion des réservations des entités logiques (FSHARE) est entièrement réalisée par XLANSQL. L'accès à la base est effectué en mode forcé. XlanSQL ne gère pas les conflits d'accès avec des produits tiers accédant à la base de données.

Conseils pour une intégration optimale avec SQL
Lors de la conception d'applications et notamment des structures du dictionnaire, ces quelques conseils vous permettront une intégration optimale avec une base de données SQL :

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


Développement
L'interface d'HARMONY avec une base de données a été réalisée au niveau des fonctions de gestion de fichier. Les fonctions DIVA de gestion de fichiers existantes sont traduites en requêtes SQL. Cette opération est réalisée par le serveur XLANSQL.
Les descriptions des fichiers, des tables, des champs, des index sont prises dans le dictionnaire de données d'HARMONY. (versions du dictionnaire avec extension dhsd)
Les opérations sont réalisées pour un fichier complet. Chaque type d'enregistrement du fichier devient une table dans la base de données. Les clés deviennent des index.
Voir également :
Types de données
Jeu de caractères
Structure des tables
Structure des index
Description des index dans le dictionnaire

Types de données
Tous les types de données du dictionnaire d'HARMONY sont pris en compte par XLANSQL. Cependant nous déconseillons l'usage de données 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é.


Jeu de caractères Windows
Dans SQL, les caractères sont codifiés dans le jeu ISO (appelé aussi Caractères Windows, OSI 8859-1, Latin-1 ou ISO 1252).

Structure des tables
La structure des tables dans la base SQL correspond strictement à la description des tables dans le dictionnaire d 'HARMONY. A une table du dictionnaire correspond une table dans la base. La table SQL porte le même nom que la table dans le dictionnaire.
Cependant avec trois particularités :

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


Structure des index
A chaque index du dictionnaire correspond un index sur la table ou sur une table intermédiaire (pour les index de type multi-tables, multi-descriptions ou conditionnels).
Si l'index comporte un code de condition, la donnée correspondant à la condition est ajoutée en donnée majeure de l'index pour les index de type normal.
La donnée table_id est ajoutée en donnée mineure de l'index.
La donnée table_id constitue un index appelé table_id.
Voir également :
Déclaration des index dans le dictionnaire

Erreurs
XLANSQL, en cas d'erreur, renvoie des codes d'erreur à l'application. Un message est également consigné dans le journal des applications de l'observateur d'événements de WINDOWS, ainsi que dans le journal des erreurs d'Harmony (consultable par la console d'administration xconsole.dhop).
Voir également :
Erreurs de XLANSQL

Erreurs de XLANSQL
0B01 Erreur ODBC allocation de l'environnement
0B02 Erreur allocation HANDLE de connexion
0B03 Erreur de connexion au serveur SQL
0B04 Erreur ouverture FHSQL.dhfi
0B05 Erreur de SEEK dans FHSQL.dhfi
0B06 Erreur allocation d'un STATEMENT
0B07 Erreur PREPARE STATEMENT
0B08 Erreur BIND PARAMETER
0B09 Erreur EXECUTE
0B0A Erreur FETCH
0B0B Erreur GETDATA
0B0C Pas de donnée correspondant à la position du Ce dans l'enregistrement
0B0D Erreur d'allocation du STATEMENT pour la relecture de l'id
0B0E Erreur PREPARE pour la relecture de l'id
0B0F Erreur EXECUTE pour la relecture de l'id
0B10 Erreur FETCH pour la relecture de l'id
0B11 Erreur GETDATA pour la relecture de l'id
0B12 Erreur en lecture de la table intermédiaire, le nom de la table n'existe plus dans le dictionnaire
0B13 Erreur en lecture de la table intermédiaire, la ligne n'existe plus dans la table
0B14 Erreur en lecture de la table intermédiaire, le nom de la clé n'existe plus dans le dictionnaire
0B15 Erreur en lecture d'un index avec identifiant. Le code n'existe pas dans le dictionnaire
0B16 Pas de lecture avant un delete ou un rewrite
0B17 Type d'enregistrement à écrire indéterminé
0B18 Date erronée dans une clé lors d'une consultation
0B1A Pas de champs pour la table dans le dictionnaire
0B1B Pas de champs pour l'index dans le dictionnaire
0B1C Pas d'index pour la table dans le dictionnaire
0B1D Pas de table accessible par cet index
0B1E Fichier non défini dans le dictionnaire
0B1F Erreur de lecture des décimales variables dans FHSQL
0B20 Erreur d'allocation du STATEMENT pour les paramètres de session sous Oracle
0B21 Erreur EXECUTE de ALTER SESSION sous Oracle
0B22 L'enregistrement paramètre de connexion à la base n'existe pas dans le fichier FHSQL
0B23 Pour Oracle, erreur lors de l'ouverture du fichier XLOGF sur le serveur XLANSQL pour la recherche de l'utilisateur correspondant au schéma.
0B24 Pour Oracle, erreur lors de la recherche de l'utilisateur correspondant au schéma dans le fichier XLOGF du serveur.

  • Aucune étiquette