Restrictions

Owned by Khouloud Achouri (Unlicensed)
19/05/2022
5 min read

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.