Odbc server Harmony (pour mémoire)

La base de donnée est forcément sous gestion SQL par un serveur SQL depuis les générations 7 de l’ERP et la version d’Harmony associée.

Ce pilote ODBC Diva natif n’a donc aucune utilité depuis les version Harmony 400 et supérieures

Généralités
Open Database Connectivity (ODBC) est une interface standard définie par Microsoft, permettant d'accéder à une base de données par une requête SQL.
L'interface ODBC définit les éléments suivants :

  • Une bibliothèque de fonctions qui permettent à une application de se connecter à un serveur, d'exécuter des requêtes SQL et de récupérer le résultat.

  • La syntaxe du langage SQL.

  • Les codes d'erreurs standard.

  • Une procédure standard de connexion et d'identification au serveur.

  • Une normalisation des types de données.


L'architecture ODBC se compose de quatre éléments :

  • L'application, qui appelle des fonctions ODBC pour exécuter des requêtes et récupérer des résultats.

  • Le driver Manager, fourni par Microsoft, qui sert d'interface entre l'application et le driver ODBC.

  • Le driver ODBC, propre à chaque base, qui traite les fonctions ODBC et gère l'interface avec la base de données.

  • La source de données qui contient la base d'informations.


Langage SQL
SQL (Structured Query Language) est un standard de fait pour la manipulation des bases de données. Il est issu du concept des bases de données relationnelles. Il utilise des tables, des index, des clés, des lignes et des colonnes.
SQL ne comporte pas de structures de contrôle ( if ... then ... else, do ... while, etc.), il est donc en général utilisé en complément d'un langage de programmation traditionnel.
SQL est au standard ANSI depuis 1989 et la plus récente spécification du langage est SQL-92.

Clients ODBC
De nombreux produits d'interrogation de bases de données proposent l'interface ODBC pour accéder à la base. Citons par exemple Hyperion, Excel, Word, Crystal Report.
ODBC est aussi une interface de programmation (API) et la plupart des langages de programmation (C#, C++, Java, Visual Basic, Diva ... ) proposent une interface ODBC.

Sources ODBC
La connexion à une base de données par le driver ODBC passe par la connexion à une source de données.
Une source est associée à un driver ODBC. Elle comporte une liste de tables accessibles simultanément dans une requête. Plusieurs sources différentes peuvent être gérées par le même driver.
Lorsque la connexion est établie, seules les tables définies dans cette source sont accessibles.
On créera généralement une source par application. S'il existe des tables communes à deux applications, il faudra déclarer ces tables dans chacune des sources.

Driver Harmony
Le driver ODBC Harmony permet la consultation, ainsi que la mise à jour des fichiers Harmony par des requêtes SQL à partir d'un client ODBC.
Afin qu'une table soit accessible par le driver ODBC, elle doit être :

  • Décrite dans le dictionnaire de données.

  • Incluse dans une source de données.


Le driver prend également en charge la consultation des vues. Une vue est une table virtuelle regroupant une ou plusieurs tables réelles. Les vues sont décrites dans un dictionnaire de vues.
Le choix « paramètres serveur ODBC » du menu « Paramétrage » d' Harmony permet de définir les sources de données et d'y inclure les tables et les vues.

Source de données

Définir une source
Le choix « paramètres serveur ODBC » du menu « Paramétrage » d' Harmony permet de définir les sources de données et d'y inclure les tables et les vues. Ce choix appelle le programme Xodbc.dhop. Il s'agit d'un zoom sur le fichier fodbc.dhfi.
L'administration des sources de données et des vues nécessite le code de confidentialité « HODB ». Celui-ci peut être ajouté (par xlog1.dhop) par l'administrateur aux utilisateurs ayant la permission d'administrer (créer, modifier et supprimer) les sources de données ou les vues. Les autres utilisateurs peuvent uniquement consulter ces informations.
Sources de données réservées
Les sources de données dont le nom commence par DIVALTO sont réservées. Elles peuvent être créées ou modifiées lors de l'installation d'une nouvelle version d'un produit Divalto. Elles sont utilisées en particulier par les documents Hyperion fournis avec l'ERP Divalto.
Tables et vues de la source
Une source de données comporte des tables et/ou des vues. Le bouton « Tables/Vues de la source » permet de consulter, d'ajouter, de modifier ou de supprimer une table ou une vue à la source courante.
La suppression d'une source de données supprime toutes les tables et vues associées à cette source.
Remarque
Dans les outils d'administration du panneau de configuration de Windows, le choix « Source de données ODBC » permet d'administrer une source. Les sources Harmony sont gérées par l'utilitaire xodbc.dhop. Celui-ci interagit avec la gestion des sources de Windows. Par exemple, la création d 'une nouvelle source l'ajoute dans l'administrateur de source ODBC de Windows. Cette administration est locale au poste de travail. Dans le cas d'une gestion centralisée des sources ODBC d'Harmony, le bouton « Actualiser les sources Windows » permet de mettre à jour la liste des sources connues de Windows.

Gestion centralisée des sources
La description des sources est stockée dans le fichier fodbc.dhfi. Ce nom est paramétrable par la commande xDivaltoMajIni dans le chapitre [odbc] du fichier Divalto.ini.
Si l'on souhaite centraliser la gestion des sources sur un serveur, il faut :

  • Sur chaque poste, modifier le paramètre FichierSources du chapitre [odbc] pour indiquer le chemin du fichier central. ( par exemple //Serveur/Divalto/sys/fodbc.dhfi)

  • Après la création d'une nouvelle source sur le serveur demander l'actualisation des sources Windows sur chaque poste client par Xodbc.dhop. Voir Remarque


Remarque
L'ajout, la suppression ou la modification de tables ou de vues d'une source ne nécessitent par la réactualisation sur les postes clients. On essaiera donc de prévoir les sources au départ sachant que leur contenu pourra évoluer facilement au fil du temps.

Création de source
La création d'une source demande les informations suivantes :

  • Le nom de la source. C'est le nom par lequel s'établira la connexion avec la source de données.

  • Un commentaire.

  • L'indicateur de lecture seule. La case cochée indique que les tables de la source ne sont accessibles qu'en lecture. Elles ne peuvent pas faire l'objet de modification. Il s'agit de la valeur par défaut conseillée, en effet la modification de champs des tables par des utilisateurs peu avertis peut avoir des conséquences graves.

  • Le traitement des dates à espace. Les dates non renseignées dans les fichiers Harmony ont une valeur à espace. Cette valeur peut être mal comprise par certaines applications clientes ODBC. Deux alternatives sont proposées :

  • Le renvoi d'une valeur nulle.

  • Le renvoi d'une valeur arbitraire ( par exemple le 1/1/1900)

  • L'indicateur de traitement du produit cartésien de tables. Lorsqu'une requête fait référence à plusieurs tables, celles-ci sont généralement liées. Au cas où cette liaison ne serait pas exprimée dans la requête ou que le lien correspondant à l'expression de la relation n'existerait pas dans le dictionnaire de données, le driver ODBC effectue un produit cartésien des tables de la requête. C'est à dire que pour chaque ligne d'une des tables, il lit toutes les lignes des autres tables de la requête. Cette opération peut être relativement longue et résulte le plus généralement d'une erreur d'expression de la requête ou de paramétrage des liens dans le dictionnaire de données. Lorsque l'indicateur n'est pas coché (valeur par défaut) le driver n'effectue pas le produit cartésien, mais renvoie une erreur au client ODBC.

  • Les noms ODBC sont destinés à donner aux objets du dictionnaire (les tables et les champs) un nom plus orienté utilisateur qu'informaticien. Pour assurer la compatibilité avec des requêtes utilisant les noms informatiques, l'usage des noms ODBC est soumis à une option de la source.

  • Le tableau des décimales variables. Voir l'annexe


Tables de la source

Table
Le bouton "Tables/Vues de la source" ou la touche F6 permettent d'afficher la liste des tables et des vues d'une source. Il est alors possible d'ajouter, de modifier ou de supprimer une table dans cette source.
L'ajout d'une table se fera généralement par sélection dans une liste de tables de référence. Toutefois il est possible de saisir manuellement les informations.
Pour une table, on trouvera les informations suivantes:

  • le nom de la table.

  • le libellé de la table.

  • le nom du dictionnaire où se trouve la description.

  • le mnémonique du fichier dans ce dictionnaire.

  • le mnémonique de table de ce fichier.

  • la confidentialité en lecture.

  • la confidentialité en mise à jour.

Sous l'onglet « décimales variables » on trouve le paramétrage des décimales pour cette table. Voir annexe.

Table de référence
Le bouton "Tables/Vues Divalto" ou la touche F11 permettent d'afficher la liste des tables et des vues de référence de l'ERP DIVALTO.
Il s'agit d'un zoom sur le fichier fodbcdivalto.dhfi.
Les tables et les vues sont regroupées par application. Le zoom propose un accès :

  • par application

  • par table et vue

  • par vue uniquement

Ce fichier ne doit pas être mis à jour, il est livré à chaque nouvelle version de l'ERP. Il contient les tables et les vues de référence de l'ERP.
Pour inclure des tables ou des vues dans une source, il convient de sélectionner les tables ou les vues à ajouter, puis de les renvoyer vers les tables de la source (par le bouton renvoyer les données ou le raccourci F12).
Si des tables ou des vues sélectionnées existent déjà dans la source de données, le remplacement des tables et des vues déjà existantes est proposé.
Importer des tables ou des vues depuis le dictionnaire
Les tables ou les vues de référence peuvent être importées automatiquement depuis un dictionnaire de données ou un dictionnaire de vues par le bouton « Import Tables/Vues ».
Une boîte de dialogue demande :

  • Le nom de l'application

  • Le nom du dictionnaire de données ou de vues.

Pour les tables, l'import concerne toutes les tables de tous les fichiers permanents. (voir propriété fichier temporaire des objets « fichier »).

Tables de référence spécifiques
La personnalisation du zoom des tables d'une source permet d'ajouter un choix (au menu et dans la barre de boutons) pour accéder à une liste de tables de référence spécifiques.
Pour cela, il faut adapter le « zoom des tables de la source » pour sélectionner des tables à partir d'un fichier de modèles spécifiques en surchargeant le module zodbcTable.dhop.
La surcharge consiste à ajouter un choix d'accès au zoom des modèles spécifiques par la fonction ZoomOdbcAjouterModeles. Il est possible d'ajouter plusieurs fichiers modèles en appelant autant de fois la fonction.
Dans le module de surcharge « zodbcTableU.dhsp » on écrira :
OverWrite "zodbcTable.dhoP"
procedure ZoomDebut
beginp
ZoomOdbcAjouterModeles("Tables ODBC xxx",
"Ajouter des tables à partir de xxx", \
"Ajout de tables xxx", \
"fodbcxxx.dhfi", \
'Tables et Vues de xxx')
Standard.ZoomDebut
endp
Description de ZoomOdbcAjouterModeles :
ZoomOdbcAjouterModeles(ToolBar, Bulle, Menu, Fichier, Titre )

  • ToolBar

Texte du bouton de la toolbar

  • Bulle

Info bulle du bouton

  • Menu

Texte du choix dans le menu

  • Fichier

Nom du fichier des tables spécifiques

  • Titre

Titre du zoom des modèles spécifiques


Fichier de modèles spécifiques:
Le fichier des modèles de tables spécifiques doit être créé. Il a les mêmes caractéristiques que le fichier fodbcdivalto.dhfi. On peut procéder par copie, effacement et renommage de ce fichier.
Ajout des tables dans un fichier de modèles spécifiques
Voir le paragraphe Importer des tables ou des vues depuis le dictionnaire du chapitre Tables de référence.

Vues de la source

Vue
Voir la définition des vues
Le bouton "Tables/Vues de la source" ou la touche F6 permettent d'afficher la liste des tables et des vues d'une source. Il est alors possible d'ajouter, de modifier ou de supprimer une vue dans cette source.
L'ajout d'une vue se fera généralement par sélection dans une liste des vues de référence. Toutefois il est possible de saisir manuellement les informations.
Pour une vue, on trouvera les informations suivantes:

  • le nom de la vue. C'est généralement le nom de la vue dans le dictionnaire. Il peut être modifié dans le cas où deux vues de deux dictionnaires porterait le même nom.

  • le libellé de la vue.

  • le nom du dictionnaire des vues.

  • le nom de la vue dans le dictionnaire.

  • la confidentialité en lecture.

  • la confidentialité en mise à jour.


Remarque :
Le champ mnémonique du fichier n'est pas utilisé pour les vues. La vue fait directement référence au fichier. Il est affiché à titre d'information.
Sous l'onglet « décimales variables » on trouve le paramétrage des décimales pour cette table. Voir annexe.
Accès à la description de la vue
Le bouton «Vues » permet d'accéder directement à la description de la vue. L'administrateur ODBC a la possibilité de modifier la vue.

Vues de référence
Le bouton "Tables/Vues Divalto" ou la touche F11 permettent d'afficher la liste des tables et des vues de référence de l'ERP DIVALTO.
Voir le chapitre « Tables de référence »

Gestion des vues

Définition des vues
Une vue est une table virtuelle constituée de champs provenant d'une ou de plusieurs tables réelles. Elle est composée à partir des tables d'un ou de plusieurs dictionnaires. Elle est stockée dans un dictionnaire de vues (extension .dhdv).
Les vues offrent de nombreux avantages :

  • L'utilisation d'une vue par un utilisateur est très simple. Il n'a pas à se soucier des jointures entre les différentes tables de la vue. La vue est composée des champs les plus pertinents. Elle rend un jeu de lignes cohérent.

  • Elle apporte un niveau d'abstraction sur l'organisation des tables et masque la complexité interne liée à des contraintes informatiques.

  • Lors d'une requête sur une vue, la recherche infructueuse d'une ligne dans une table liée renvoie des valeurs à espace pour les champs de cette table. De ce fait, on peut déclarer dans une vue des tables liées pour lesquelles les champs du lien n'ont pas été renseignés (Par exemple une adresse de livraison facultative pour un client).

  • Une vue peut être confidentielle globalement ou pour chacun de ses champs. Chaque utilisateur verra les vues et les champs pour lesquelles il a les autorisations.


Remarques :

  • Les champs d'une vue ne peuvent pas être mis à jour par les requêtes SQL « Insert », « Update » ou « Delete ».

  • Une vue est beaucoup plus facile à exploiter par un utilisateur, notamment lorsqu'elle fait intervenir plusieurs tables. On privilégiera donc l'utilisation des vues dans une source de données, plutôt que celle des tables individuelles.


Dictionnaire de vues
Le programme XodbcView.dhop est accessible depuis le menu harmony, depuis le dictionnaire de données dans Xwin, ainsi que depuis la saisie des tables et des vues d'une source de données (par Xodbc.dhop). Les vues sont stockées dans un dictionnaire de vues. Il s'agit d'un fichier texte avec l'extension .dhdv. On peut créer autant de dictionnaires de vues qu'on le souhaite.
Nouveau dictionnaire de vues
Le choix « Nouveau dictionnaire de vues » permet de créer un nouveau dictionnaire. Il porte une extension .dhdv.
Choix des dictionnaires de données
Une vue peut être composée de champs de tables décrites dans différents dictionnaires de données. A partir d'une table de base, l'outil affiche la liste de toutes les tables liées. Ces tables sont cherchées dans la liste des dictionnaires de données associés au dictionnaire des vues. Le choix « Liste des dictionnaires » (raccourci F5) permet de compléter ou de mettre à jour la liste des dictionnaires de données associés.
Remarque : Ce choix est appelé automatiquement lors de la création d'un nouveau dictionnaire de vues.
Généralités sur les vues
A partir d'une table de base, le programme affiche un arbre avec toutes les tables liées à cette table de base. L'ouverture de la branche d'une table liée affiche la liste des tables liées de second niveau.
Pour chaque table le programme affiche la liste des champs. La constitution de la vue s'effectue par une simple sélection des champs que l'on souhaite inclure dans la vue à partir de la table de base et des tables liées.
La vue est constituée d'une liste de champs en provenance des différentes tables. L'ordre final des champs de la vue est respecté lors de l'interrogation du catalogue d'une vue par un client odbc. On peut ainsi rapprocher un code de sa désignation.
Une vue peut contenir des champs provenant d'un grand nombre de tables (plusieurs dizaines par exemple). Le driver ODBC optimise les accès lors de l'interrogation de la vue pour n'accéder qu'aux tables pour lesquelles des champs ont été sélectionnés dans la requête.

Création d'une vue
La création d'une vue demande les informations suivantes :

  • Le nom de la vue. C'est normalement aussi sous ce nom que la vue apparaîtra dans la liste des tables et des vues de la source. Pour distinguer les vues des tables, on peut préfixer les noms de vues par le mot « Vue ».

  • Un commentaire.

  • Le dictionnaire de données. C'est un multichoix qui propose la liste des dictionnaires de données associés au dictionnaire de vues. Si le dictionnaire souhaité n'est pas dans la liste, celle-ci peut être complétée. (raccourci F5)

  • Le fichier. C'est un multichoix qui propose la liste des fichiers décrits dans le dictionnaire choisi.

  • La table. C'est un multichoix qui propose la liste des tables du fichier choisi. Il s'agit de la table de base de la vue. Pour la constitution de la vue, on pourra choisir des champs dans cette table de base ainsi que dans toutes les tables qui lui sont directement ou indirectement (en passant par une autre table) liées. La table de base est lue séquentiellement par le driver ODBC. Il effectue un accès direct pour lire les champs des tables liées de la requête SQL.

  • L'index. C'est un multichoix qui propose la liste des index de la table choisie. Cette information est facultative. Si elle n'est pas renseignée, le driver ODBC choisira le meilleur index en fonction des critères de sélection, de regroupement ou de tri de la requête SQL. Dans certains cas il peut être intéressant de préciser l'index à utiliser directement dans la vue, en particulier si l'on souhaite utiliser un index conditionnel. En effet, le driver ODBC ne choisit jamais un index conditionnel. Par contre, si l'index est précisé dans la vue, le driver prendra cet index quel que soit son type.

  • La condition. La condition est une « search_condition » de la clause Where du langage SQL. Elle permet de faire une sélection des lignes lues. Les champs de la condition doivent obligatoirement appartenir à la vue (ils peuvent éventuellement être cachés, dans ce cas il n'apparaîtront pas dans le catalogue des champs de la vue). La condition de la vue est combinée par un ET LOGIQUE avec la condition de la clause Where du Select. Elle entre dans le processus d'optimisation des accès.

Exemples

  • TypeTiers='C' and TypePiece='4'

  • Dossier = 1 and NOT Left(CodePostal,2)in(22,29,35,56)

  • L'indicateur de lecture du fichier des données. Pour les vues pour lesquelles l'on sait qu'il faut lire l'ensemble du fichier, il peut être plus performant d'activer l'option de lecture des données plutôt que de passer par les index. Cette option n'est généralement intéressante que pour des fichiers volumineux pour lesquels la table lue correspond à une proportion importante des lignes du fichier. Un chronométrage avec et sans l'option permet de prendre la meilleure décision.

  • La confidentialité. Elle permet de réserver l'accès à la vue aux utilisateurs ayant les droits d'accès correspondants.

  • Les noms des procédures Diva associées à l'initialisation, à la lecture et à la gestion des confidentialités.


Champs d'une vue
A partir d'une table de base, la création des vues affiche un arbre avec toutes les tables liées à cette table de base. L'ouverture de la branche « Champs de nom table » permet d'afficher les champs de cette table. C'est la première branche de chaque table liée.
L'option « Voir champs masqués ODBC » du menu permet d'inclure dans la liste des champs des tables les champs masqués pour ODBC dans le dictionnaire de données. Elle doit être activée avant l'affichage de l'arborescence des tables de la vue.
La constitution de la vue s'effectue par simple sélection des champs des différentes tables liées.
Sélection des champs de la vue
Pour ajouter un champ à la vue, il suffit de se positionner sur le champ (pour ne pas dire tout de suite! ) de l'arbre et de l'envoyer (soit par le bouton >>, soit par double-clic ou la touche inser), soit par un drag and drop dans le tableau des champs de la vue.
La sélection multiple dans l'arbre permet d'envoyer plusieurs champs simultanément.
La touche Tab permet de passer de l'arbre au tableau et vice-versa.
La touche Ctrl+Tab permet de se positionner sur le même champ dans l'arborescence. Ceci est assez pratique si l'on souhaite ajouter d'autres champs de cette table dans la vue.
Propriétés des champs de la vue

  • Le nom de la table. Le nom contient une concaténation des noms des tables liées depuis la table de base jusqu'à la table contenant le champ de la vue. Ceci permet d'identifier la table dans l'arborescence des tables liées. Exemple Mouvement.Client.Table_Naf identifie la Table_Naf liée au Client, elle-même liée à la table des mouvements.

  • Le nom ODBC du champ. Ce nom provient généralement du dictionnaire de données, en prenant d'abord le nom local à la table (s'il existe), puis le nom général (s'il existe et en effectuant éventuellement la substitution de $r par le nom de la table) et enfin le nom du champ. Il peut arriver que deux champs de deux tables portent le même nom, il faut dans ce cas changer manuellement un des deux noms, en effet, chaque champ de la vue doit porter un nom unique.

  • La nature. Elle provient du dictionnaire de données à titre informatif.

  • L'indicateur de champ caché. Cet indicateur permet de masquer un champ de la vue lors de l'interrogation du catalogue de la vue par le client ODBC. On utilise généralement cette option pour les champs ajoutés à la vue pour des besoins de filtrage par la condition de la vue. Pour les champs masqués pour ODBC au niveau du dictionnaire de données, cette option est active par défaut lors de l'insertion du champ dans la vue.

  • La confidentialité. Elle permet de cacher les champs de la vue aux utilisateurs n'ayant les droits d'accès correspondants


L'ordre des champs
L'ordre final des champs de la vue est respecté lors de l'interrogation du catalogue d'une vue par un client odbc. On peut ainsi effectuer un regroupement sémantique des champs. (par exemple rapprocher un code de sa désignation)
Pour déplacer un champ il faut se positionner sur le champ et utiliser les boutons de déplacement vertical vers le haut ou vers le bas. (raccourci Ctrl+flèche haut ou bas)
Pour déplacer plusieurs champs il faut au préalable les sélectionner.
On pourra également procéder par couper/coller des lignes du tableau.
Optimisation des accès
Une vue peut contenir des champs provenant d'un grand nombre de tables (plusieurs dizaines par exemple). Le driver ODBC optimise les accès lors de l'interrogation de la vue pour n'accéder qu'aux tables pour lesquelles des champs ont été sélectionnés dans la requête.

Surcharge des vues
Le choix « Créer une surcharge » du menu « Fichier » permet de créer un dictionnaire de surcharge du dictionnaire des vues. Le principe des surcharges permet de conserver des personnalisations effectuées dans des vues existantes en cas de mise à jour.
Dans un dictionnaire de vues surchargé on pourra :

  • Ajouter des champs dans une vue existante,

  • Changer l'ordre des champs d'une vue existante,

  • Modifier la confidentialité des champs d'une vue existante,

  • Ajouter de nouvelles vues.

  • Ajouter des dictionnaires de données complémentaires afin d'inclure dans la vue des champs de tables liées décrites dans ces dictionnaires.


Remarques :

  • Il n'est pas possible de modifier l'entête des vues existantes.

  • Suite à une mise à jour du dictionnaire de base, des erreurs d'incohérences avec la surcharge peuvent apparaître. Elles sont signalées par un message d'erreur clair.


Dictionnaire de données

Dictionnaire
Différents objets doivent être décrits dans le dictionnaire de données. Le dictionnaire doit être accessible par le Serveur ODBC Harmony lors de l'exécution d'une requête.
La description du fichier doit contenir les informations sur :

  • Le fichier.

  • Les tables du fichier.

  • Les champs de la table.

  • Les index d'accès à la table.

  • Les liens vers d'autres tables.

On se reportera à la documentation du dictionnaire de données pour les explications détaillées concernant le dictionnaire.
Fichier
Le fichier doit être un fichier séquentiel-indexé.

Table et champs
Dans les caractéristiques des tables la propriété Nom ODBC permet de nommer la table avec un nom orienté utilisateur. Par exemple la table T017 du fichier gtftab devient la table Table_Depot. Par convention, on séparera les différents mots des noms de table par le caractère _ (underscore).
La propriété « nom général » est valable pour toutes les instances de la table, alors que le « nom local » est spécifique à l'utilisation de la table pour le fichier auquel elle appartient.
Champ
Dans les caractéristiques des champs la propriété Nom ODBC permet de donner un nom orienté utilisateur. Par convention, on utilisera la notation « Pascal » (La première lettre de chaque mot est une majuscule, exemple TypeTiers)
Les propriétés ODBC des champs peuvent être définies

  • Soit au niveau général, dans ce cas elles s'appliquent à toutes les utilisations de ce champ.

  • Soit au niveau local, dans ce cas elles s'appliquent à l'usage spécifique de ce champ dans la table où la valeur locale a été définie. Le nom local prévaut sur le nom général.


Le mot clé $Record ( ou $r ) peut être mis dans un nom général ODBC. Il sera substitué par le nom de la table où il est utilisé.
Exemple : Libelle_$r devient :

  • Libelle_Code_Tarif pour la table Code_Tarif

  • Libelle_Devise pour la table Devise

  • Etc.

Ceci évite de donner un nom local à chaque instance du champ Libelle.
La propriété "Masqué dans ODBC" permet de masquer certaines données qui ne doivent pas apparaître dans le catalogue des données d'une table comme par exemple les données de redécoupage d'une autre donnée, les redéfinitions, les codes enregistrement.
La case à cocher locale pour le masquage est à trois états :

  • Cochée signifie oui

  • Non cochée signifie non

  • Par défaut signifie prend la valeur générale



Index
Au moins un index doit être défini pour accéder à une table.
Type d'index SQL
Lorsque le driver ODBC est amené à choisir un index pour la lecture de la table, il ne prend en compte que les index de type « Normal », « avec Identifiant » et « Multi-table ».
La lecture par un index de type « Multi-Table » filtre les lignes ne correspondant pas à la table sélectionnée.
En particulier, il n'utilisera pas les index de type « Conditionnel » qui ne délivrent pas toutes les lignes d'une table, ni les index de type « Multi-description » qui peuvent délivrer plusieurs fois la même ligne d'une table.
Vues
Lorsqu'un index est précisé au niveau de la vue, il est utilisé par le driver quel que soit son type.
Clé Primaire
La clé primaire correspond à un index qui identifie de manière unique chaque ligne d'une table. Une table ne peut comporter qu'une seule clé primaire (même s'il existe plusieurs clés uniques, dans ce cas il faudra choisir laquelle est la clé primaire).
Cette information est utilisée dans les cas suivants :

  • A l'exécution d'une requête, si l'optimiseur de la requête n'a pas trouvé d'index favorable, le driver lit le fichier par la clé primaire. Si elle n'existe pas il prend le premier index défini.

  • En cas de création par une requête INSERT, le driver ODBC interdit la création de doublons sur la clé primaire.

  • La compilation d'une requête UPDATE interdit de modifier les données de la clé primaire.

  • Certains clients ODBC utilisent cette information pour établir des liens entre les tables en recherchant une correspondance entre les noms de champs de la clé primaire d'une table et les autres tables de la requête. Les outils plus évolués interrogent le driver pour connaître les liens entre les tables.


Optimisation des accès grâce aux index

Lien
Les liens permettent de définir les relations entre les tables. Ils peuvent être interrogés par le client ODBC pour proposer les jointures entre les différentes tables d'une requête.
Ils sont utilisés lors de la création des vues pour constituer l'arborescence des tables liées entre elles.
Remarque
Pour des raisons de performance, il est fortement recommandé de décrire les liens dans le dictionnaire. Pour les requêtes SQL utilisant plusieurs tables, ces liens sont utilisés pour optimiser les temps d'accès. Lors d'une requête impliquant plusieurs tables, s'il n'y a pas de lien défini dans le dictionnaire, le moteur SQL effectue le produit cartésien des différentes tables de la requête, ce qui peut engendrer des temps de réponses importants.
Nom ODBC des liens
Un nom ODBC peut être associé à une table au niveau d'un lien sortant.
Exemple
La table Mouvement (Mouv) permet d'accéder à l'entête du devis (Ent), de la commande (Ent), du Bon de livraison (Ent) et de la facture (Ent). On peut ainsi associer un nom ODBC spécifique à chacune de ces tables, Piece_Entete_Devis pour l'entête du devis, Piece_Entete_Commande pour la commande, etc. Ces noms sont repris pour la constitution des vues à partir des tables.
Liens Multiples entre tables
Deux tables peuvent être liées entre elles par plusieurs liens. Par exemple, la table « Table_Libelle_famille_tarif » (T001) est liée 2 fois à la table « Client », pour le tarif ordinaire et pour le tarif exceptionnel
Si l'on ajoute ces deux tables au modèle de données d'Hyperion, il ne trace pas de lien automatiquement entre les tables, puisqu'il ne sait pas lequel choisir.
Par contre, lors de la création d'une vue, la table des libellés des familles de tarif apparaît deux fois :

  • une fois sous le nom Table_Libelle_Famille_Tarif

  • et l'autre sous Table_Libelle_Famille_Tarif_Exc (qui correspond au nom ODBC donné à la table au niveau du lien)


Driver ODBC

Connexion
La connexion au driver requiert un code utilisateur et son mot de passe.
Lors de la connexion, le driver ODBC vérifie que l'utilisateur existe dans le fichier XLOGF. Il récupère les droits d'accès, ainsi que les chemins implicites.
La recherche des dictionnaires et des fichiers utilise les chemins implicites de l'utilisateur.
Chaque connexion au driver utilise une tâche Harmony. Le driver alloue les numéros de tâches dynamiquement à partir de 999 en descendant.

Optimisation des accès
Lors de la préparation d'une requête avant son exécution, le driver ODBC recherche l'index le plus favorable en fonction des critères de sélection (clause Where et Having), des critères de regroupement (clause Group by) ou des critères de tri (clause Order by).
Remarque
Lorsqu'un index est imposé pour une vue, le driver ODBC l'utilise quels que soient les critères de la requête. Voir la création des vues.
Choix de l'index
Le choix de l'index s'effectue d'abord en fonction de critères de sélection, puis des critères de regroupement et enfin des critères de tri. Si aucun index ne convient ou si la requête ne comporte pas de critères particuliers, le driver utilise un index par défaut (la clé primaire si elle existe, sinon le premier index de la table).
Exemples:

  • Select * from client where CodePostal BETWEEN '67000' and '68999' lit le fichier client par l'index comprenant le CodePostal pour les valeurs spécifiées.

  • Select CodeCli, sum(Montant), NomCli from Stat, Client where Stat.CodeCli = Client.CodeCli Group By CodeCli utilise l'accès par le code client pour gérer le regroupement.


FichierLog
Le paramètre FichierLog du chapitre [ODBC] de Divalto.ini permet d'indiquer le nom du fichier mouchard donnant des indications sur l'exécution des requêtes, en particulier l'index utilisé.

Diva

Traitements Diva pour les requêtes ODBC
Le driver ODBC peut appeler des procédures Diva lors de l'exécution de requêtes SQL de consultation.
Cette ouverture majeure des fonctionnalités du driver ODBC offre notamment la possibilité de constituer des vues très élaborées à partir d'algorithmes « intelligents » permettant de quitter le cadre purement relationnel des requêtes classiques.
Certains traitements sont valables pour toutes les requêtes, alors que d'autres sont spécifiquement liés aux vues. Les modalités de dialogue entre le driver ODBC et le module Diva sont toutefois identiques.
Ceux-ci communiquent de deux manières complémentaires :

  • par les enregistrements publics définis dans le module Diva,

  • par des paramètres passés par le tunnel. Le module Diva récupère ces paramètres par la fonction PingReceive et renvoie des informations vers le driver par la fonction Pong.


Ces fonctionnalités ouvrent un vaste domaine d'application notamment :

  • Définir dans les tables des champs virtuels calculés par un traitement Diva.

  • Initialiser un contexte pour le traitement d'une vue par exemple en fonction du code de l'utilisateur.

  • Effectuer la lecture personnalisée des lignes de la table de base d'une vue.

  • Gérer les confidentialités des champs d'une vue

  • Lire une table liée d'une vue par un algorithme évolué.


Remarque :
Les procédures sont exécutées à partir d'un programme générique XodbcDiva.dhop qui charge le module et exécute la fonction. C'est lui qui dialogue avec le driver ODBC. Il est lancé par le service Divalto Agent Diva.
Debug :
Si l'on souhaite déboguer les procédures Diva appelées par le driver ODBC, il convient d'attacher le programme XodbcDiva.dhop correspondant au traitement en cours par le choix « attacher une tâche » du menu « Déboguer » de XWIN.
L'outil Hypérion lance une nouvelle instance du programme XodbcDiva.dhop à chaque traitement d'une requête. Pour permettre d'attacher le programme, insérez la fonction
MessageBox("Attache-moi si tu veux","debug")
dans la procédure d'initialisation de la vue.
De plus, le service Divalto AgentDiva doit être autorisé à interagir avec le bureau.
Voir aussi le paramètre Visible de Divalto.ini.

Initialisation d'une vue
Le paramétrage d'une vue permet de lui associer une procédure Diva d'initialisation. Cette procédure est exécutée lors de la préparation de la requête SQL d'interrogation de la vue.
Elle peut être utilisée pour :


Initialiser des variables globales liées à la vue
Les traitements Diva associées à la vue peuvent nécessiter l'initialisation de variables globales dépendant par exemple du code utilisateur ou de paramètres spécifiques à la vue. Ces variables peuvent être initialisées dans la procédure d'initialisation de la vue.
Exemple :
Garnissage de la zone MZ en fonction du code utilisateur, notamment le dossier par défaut de l'utilisateur.
public record A5dd.dhsd Muser
public record A5dd.dhsd Mz
module "a5tm000.dhop"
; procédure d'initialisation de MaVue
Public Procedure MaVue
Beginp
rechercher_utilisateur() ;recherche l'utilisateur system.user
Mz.Dos = Muser.Dos
Mz.Depo = Muser.Depo
Mz.Etb = Muser.Etb
Endp
Initialiser la clé de lecture du fichier de base
Lorsque la lecture de la table de base est assurée par une procédure Diva, il peut être nécessaire de positionner la clé de lecture dans la table de fichier. Le choix de l'index peut être :

  • Paramétré dans la vue

  • Choisi par le driver ODBC en fonction des critères de sélection, de regroupement ou de tri

  • Choisi par le programme Diva arbitrairement.

Exemple :
Choix arbitraire de l'index de lecture pour la vue des écritures non lettrées
Hfile ccfdd.dhsd ccfdce ccfdce
; procédure d'initialisation de MaVue
Public Procedure MaVue
Beginp
Ccfdce.key = 'E'
Endp

Positionner des filtres de lecture du fichier
Lorsque la lecture de la table de base est assurée par une procédure Diva, il peut être intéressant de positionner un filtre afin d'optimiser les temps de lecture.
Exemple :
; procédure d'initialisation de MaVue
Public Procedure MaVue
Beginp


hfilter(gtfpcf,"ce1 = 3 and dos = " & Mz.Dos ,"B 3" )
Endp
Paramètres de la vue pingreceive « ODBCINIT »
Le driver Odbc envoie par le tunnel le paramètre « ODBCINIT ». C'est une chaîne <hmp> qui contient les paramètres de la vue définis dans le dictionnaire de vue.

<Nom>

Nom de la vue

<Version>

Numéro de version de la vue

<NomDicoVue>

Nom du dictionnaire de vue

<Dico>

Nom du dictionnaire de données du fichier de base

<Fichier>

Nom du fichier dans le dictionnaire de données

<Table>

Nom de la table dans le dictionnaire

<VersionFichier>

Numéro de version du fichier ayant servi à la description de la vue

<Index>

Nom de l'index à utiliser pour lire la table de base. Ce paramètre est absent s'il n'est pas renseigné dans la vue

<Condition>

Clause SQL de sélection des lignes à lire

<LectureDonnees>

Indicateur pour forcer la lecture du fichier des données sans passer par les index. Ce paramètre est absent si l'option n'est pas requise pour la vue

<Confidentialite>

Code de confidentialité de la vue

<DivaLecture>

Nom de la procédure Diva de lecture de la table de base. Ce paramètre est absent s'il n'est pas renseigné dans la vue


Paramètres de la variable d'environnement Windows « ODBCPARAM »
Le driver ODBC au chargement du programme Diva crée une variable d'environnement nommée «ODBCPARAM» qui contient une chaîne <hmp> avec notamment le code de l'utilisateur.

<program>

Nom du programme Diva générique XodbcDiva.dhop

<User>

Code de l'utilisateur


Exemple :
1 Parametres S
1 User 20


Parametres = GetEnv("ODBCPARAM")
User = HmpSeek(Parametres, "user")
Remarque :
Le champ System.User contient également le code de l'utilisateur.

Lecture de la table de base d'une vue
Le paramétrage des vues permet d'associer à la vue une procédure Diva de lecture de la table de base. Cette procédure est exécutée par le driver ODBC pour chaque lecture d'une ligne de la table de base.
Ceci permet d'effectuer une lecture plus « applicative » de la table que la simple lecture séquentielle opérée en standard par le driver ODBC, pour obtenir par exemple la liste des clients sans facture pendant une période.
La description de tables fictives dans le dictionnaire permet de mettre à disposition des vues très élaborées, résultats d'algorithmes pris en charge par la fonction de lecture associée à la vue.
Paramètres
Le module comportant la procédure de lecture de la table doit impérativement comporter une déclaration publique de la table de base de la vue. Le nom de l'instance doit être impérativement le nom de la table elle-même. C'est cet enregistrement qui est renvoyé au driver à la fin de l'exécution de la procédure.
Fin de fichier
La fin de fichier est signifiée au driver ODBC par l'enregistrement entièrement à espace.
Index de lecture
Lorsque le choix de l'index de lecture est opéré par le driver ODBC, la procédure de lecture doit récupérer dans le tunnel la valeur de la clé courante (par PingReceive) et renvoyer la nouvelle valeur (par Pong) après la lecture. La valeur de la clé est identifiée par le mot clé 'ODBCKEY' dans le tunnel.
Exemple :
public record gtfdd.dhsd cli
; lecture des clients sans facture pour une période
Public Procedure LireClientSansFacture
1 Status X
1 Filtre s
Beginp
pingreceive("ODBCKEY",gtfpcf.key)
do
status = hread(gtfpcf,cli,,'F' )
while status <> H_EOF
; on cherche les factures
Filtre = "ticod = 'C' and tiers = '" & cli.tiers & "'"
Filtre &= " and dos = " & dos
Filtre &= " and pidt between "
Filtre &= datesql(datedebut) & " and " & datesql(datefin)
Filtre &= " and picod = 4"
hfilter( gtfent,filtre,"B" )
status = hread(gtfent,ent,,'F')
if Status = H_EOF
pong ("ODBCKEY",gtfpcf.key) ;il n'y a pas de facture
preturn
endif
wend
; c'est la fin
cli = ' '
preturn
Endp


Confidentialités des champs d'une vue
Le paramétrage des vues permet d'associer à la vue une procédure Diva de gestion des confidentialités des champs de la table de base d'une vue. Cette procédure est exécutée par le driver ODBC pour chaque lecture d'une ligne de la table de base.
Paramètres
Le module comportant la procédure de gestion des confidentialités doit impérativement comporter une déclaration publique de la table de base de la vue. Le nom de l'instance doit être impérativement le nom de la table elle-même.
Cet enregistrement est garni par le driver ODBC avant l'appel de la procédure. Il est renvoyé au driver après le traitement.
La procédure peut :

  • Mettre à espace les champs confidentiels.

  • Mettre à espace tout l'enregistrement. Dans ce cas, il n'est pas renvoyé au client ODBC. Le driver passe à la ligne suivante de la table de base.


Lecture d'une table liée d'une vue
La description des liens dans le dictionnaire de données permet d'associer au lien une procédure Diva de lecture de la table liée. Cette procédure n'est exécutée que dans le cadre des vues. Elle n'est jamais exécutée dans le cas d'une requête simple portant directement sur des tables.
Elle permet d'effectuer une recherche « intelligente » de la table liée plutôt qu'une recherche simplement relationnelle, par exemple effectuer des recherches en cascade d'abord avec le dossier du client, puis avec le dossier par défaut.
Paramètres
Le module comportant la procédure de lecture de la table liée doit impérativement comporter une déclaration publique des deux tables liées. Le nom des instances doit être impérativement le nom des tables elles-mêmes.
Le driver ODBC garnit la table d'origine avant l'appel de la procédure.
La procédure effectue la recherche de l'enregistrement public correspondant à la table liée. C'est cet enregistrement qui est renvoyé au driver à la fin de l'exécution de la procédure.
S'il n'y a pas de correspondance, l'enregistrement doit être mis entièrement à espace.
Exemple :
La fonction Lectab du module Gttm000 cherche le mode de règlement soit dans le dossier du client soit dans le dossier commun en fonction du paramétrage.
La procédure d'initialisation de la vue charge la table T000 qui précise le mode de fonctionnement par la fonction seek_t000
Module GTTM000.dhop
public record gtfdd.dhsd T000
public record gtfdd.dhsd cli
public record gtfdd.dhsd T006
;recherche du mode de règlement en fonction des paramètres Dossier
Public Procedure Cli_T006_FL
Beginp
Mz.Dos = Cli.dos
if Lectab(6 , Cli.Regl) <> 0
T006 = ' '
endif
Endp

Ecriture de variables d'environnement ODBC
Les variables d'environnement ODBC peuvent être positionnées par la fonction DIVA du module ysystemex.dhop
OdbcTxt ( Variables [, Local] )
Paramètres
Variables Il s'agit d'une chaîne <hmp> contenant les paramètres des variables d'environnement à écrire. La chaîne peut comporter plusieurs variables, avec pour chacune d'elle :

  • <nom> le nom de la variable

  • <valeur> la valeur de la variable

  • <type> le type de la variable (A, N, D ou L).


Le type est facultatif. Il est déterminé automatiquement en fonction du contenu.
10/2/2005 est de type date <D>
123,45 est de type numérique <N>
'Roméo' est de type alpha <A> Le type <L> permet de définir une liste de valeurs pour l'opérateur IN de SQL.
Exemple :
<Nom>Departement<Type>L<Valeur>67,68
Local false pour les variables d'environnement globales
true (par défaut) pour les variables d'environnement locales
Remarques :

  • Pour les variables globales, si le fichier Fodbc.txt n'existe pas, la fonction affiche une erreur.

  • Pour les variables locales, le fichier FodbcLocal.txt est automatiquement créé.


Exemple : mettre à jour le dossier par défaut de l'utilisateur
public record A5dd.dhsd Muser
module "a5tm000.dhop"
module "ysystemex.dhop"
; procédure d'initialisation de MaVue
Public Procedure MaVue
Beginp
rechercher_utilisateur()
OdbcTxt("<nom>Fodbc_dossier<valeur>" & Muser.Dos)
Endp

Lecture des variables d'environnement ODBC
Les variables d'environnement ODBC peuvent être lues par la fonction DIVA du module ysystemex.dhop
Variables = OdbcTxtRead
Retour
Variables Contient une chaîne <hmp> avec les variables d'environnement globales et locales. Lorsqu'une variable est à la fois locale et globale, la valeur locale est renvoyée. La fonction HmpSeek permet d'extraire chaque variable individuelle.
Chaque variable est identifiée par son nom.
Remarque : On utilisera de préférence un champ de type S (string) pour la lecture de la chaîne <hmp>.
Exemple
module "ysystemex.dhop"
1 FodbcParam S
FodbcParam = OdbcTxtRead
Debut = hmpseek(fodbcparam,"fodbc_datedebut",hdate(,'p','p',-1))
Fin = hmpseek(fodbcparam,"fodbc_datefin",hdate(,'d','d',-1))
Dos = hmpseek(fodbcparam,"fodbc_dossier",1)

Hyperion Intelligence Explorer

Hyperion
Hyperion est un outil de requêtes, d'analyse des résultats et de production de rapports doté d'une interface très intuitive. La phase la plus délicate pour un utilisateur est la compréhension du modèle de données pour une mise à disposition d'informations fiables et cohérentes. La gestion des vues permet de masquer la complexité de l'organisation interne des tables et donc de rendre cette phase parfaitement transparente.

Fichier OCE
Les fichiers OCE sont des fichiers de connexion à la base de données. Le fichier DivaltoDemo.Oce permet de se connecter à la source de données Divalto de démonstration. Les noms de fichiers OCE commençant par Divalto sont réservés par Divalto.
Pour créer un fichier de connexion OCE, il faut activer le choix « Un nouveau fichier de connexion de base de données » de la boîte de dialogue de « Bienvenue dans Hyperion ».

Dans la boîte de l'assistant, sélectionner les options ci-dessus.
Puis sélectionner la source de données et garnir la boîte de connexion au Serveur ODBC Harmony.
Après la boîte sur la connexion actuelle

Il faut modifier les paramètres de la métaconnexion personnalisée

Sur l'onglet « Jointures », il faut activer l'option « Définie par le serveur » qui invite Hyperion à consulter les liens définis dans le dictionnaire pour établir les jointures entre les tables.
On nommera généralement le fichier OCE avec le nom de la source de données.

Fichier BQY
Un fichier BQY contient un document Hyperion avec ses différentes sections : interrogation, résultat, pivot, graphique, rapport, etc. Il fait référence au fichier OCE qui a permis la connexion à la base de données.

Modèle de données
Après la modification de la structure d'une table ou d'une vue, le choix « synchroniser avec la base de données » du menu « modèle de données » permet d'actualiser la liste des champs des tables ou des vues du modèle de la section « requête » (ou de la section « modèle de données » pour les modèles de données maître).
Option du modèle de données
Il faut désactiver l'option « Alias automatique des tables » pour avoir les noms des champs dans la notation « Pascal » (Première lettre des mots en majuscule). Puis « Enregistrer par défaut »


Annexes

Paramétrage complémentaire
Dans Divalto.ini, on trouve dans le chapitre [ODBC] les mots clés suivants :
FichierSources=/Divalto/sys/fodbc.dhfi
Indique le nom du fichier paramètre des sources.
Le fichier fodbc.dhfi contient la liste des sources et des tables ODBC.
Il est géré par le programme xodbc.dhop.
La valeur par défaut est /Divalto/sys/fodbc.dhfi.
DialogConnectToujours=0
Lors de l'appel à la fonction SQLDriverConnect, si les paramètres sont corrects, le serveur ODBC Harmony se connecte directement sans ouvrir la boîte de dialogue invitant à saisir le code utilisateur et le mot de passe. Toutefois on peut rendre obligatoire l'affichage de cette boîte de dialogue (DialogConnectToujours=1), ceci permet de modifier le code utilisateur à chaque connexion.
La valeur par défaut est 0.
TailleBuffers=1024
Taille, en kilo octets, des buffers alloués lorsque le serveur ODBC Harmony doit faire un tri. On peut modifier cette taille si on rencontre une erreur de mémoire insuffisante lors d'une requête sql exécutant un tri.
La valeur par défaut est 1024 k, la valeur minimum est de 128 k.
TRAVAIL= chemin du répertoire de travail
Chemin du répertoire de travail qui sera utilisé lors de l'utilisation de fichiers de travail pour le tri. Le chemin du répertoire de travail par défaut est le même que celui défini par Windows.
FichierLog= chemin du fichier mouchard
A chaque exécution d'une requête SQL, le driver ODBC Harmony peut écrire le texte de la requête, ainsi que des informations sur l'optimisation de celle-ci dans un fichier log. On utilisera cette possibilité si l'on a des problèmes de temps de réponse ou de requêtes qui ne semblent pas donner le bon résultat. Le fichier mouchard n'est jamais effacé.
Exemple : FichierLog=c:\temp\xodbc.log
Visible= 0
Les fonctions Diva invoquées par le driver ODBC peuvent être amenées à afficher des messages dans une fenêtre (par exemple en cas d'erreur grave). Cette option permet d'interdire l'affichage de ces fenêtres.
La valeur par défaut est 1

Gestion des décimales variables
Par défaut, lorsque le Serveur ODBC Harmony trouve une donnée numérique de type décimale variable, il prend la valeur 2 comme nombre de décimales de la variable.
Toutefois, pour une table, on peut indiquer une autre valeur en renseignant le champ correspondant lors de la saisie des paramètres d'une table ( onglet "Décimales variables" ). Cette valeur ne sera prise en compte que pour cette table.
On peut aussi indiquer une autre valeur pour toutes les tables d'une source en renseignant le champ correspondant lors de la saisie des paramètres d'une source (onglet "Décimales variables" ). Dans ce cas, cette valeur sera prise en compte pour toutes les tables qui auront ce champ à espace.
On peut définir 10 types de décimales variables.
Elles sont déclarées dans le dictionnaire par le type "Numérique,D" et par la valeur "Nombre de décimales" qui dans ce cas indique le type de décimales variables (entre 0 et 9).

Caractéristiques et limites du Serveur ODBC Harmony

  • Le driver ODBC Harmony ( xodbcil.dll ) utilise la dll dhXisam.dll pour accéder aux fichiers, ceux-ci pouvant être en local ou sur un serveur XLAN. A chaque connexion, le serveur ODBC Harmony utilise donc une tâche Harmony. Le nombre de connexions possibles sur un ordinateur est donc limité à 998 (Tâches Harmony de 2 à 999).

  • Il gère les données de type alphanumérique, numérique et numérique avec décimales variables, ainsi que les dates (D8). Tous les autres types : date mensuelle, date et heure, heure, B, X, L sont considérés comme des données ALPHA.

  • Il ne gère pas de curseur SQL.

  • Toutes les fonctions jusqu'au niveau de conformité "LEVEL 1" sont implémentées.


Grammaire SQL supportée par le driver ODBC Harmony
SELECT [ALL|DISTINCT] * | table_name.* | expression [ [AS] column_alias] [,...]
FROM table_name [ [AS] correlation_name] [,...]
[WHERE search_condition]
[GROUP BY column_name [,...]]
[HAVING search_condition]
[ORDER BY expression [ASC|DESC] [,...]]
DELETE FROM table_name
[WHERE search_condition]
INSERT INTO table_name [(colum_name [,...] )]
VALUES (insert_value,[,...])
UPDATE table_name
SET column_name=expression [,...]
[WHERE search_condition]
Les éléments entre crochets sont facultatifs.
Le signe | désigne ou.
La notation [,...] indique que l'on peut répéter le paramètre précédent n fois.
table_name désigne un nom de table défini par xodbc.
column_alias est un nom utilisateur ( user defined name ) de 16 caractères maximum.
correlation_name est un nom utilisateur ( user defined name ) de 16 caractères maximum.
insert_value désigne une constante alpha ou numérique ou un paramètre dynamique .
expression désigne une somme de termes ou un produit de facteurs avec des parenthèses. Les éléments de base d'une expression sont :

  • des noms de colonne

  • des constantes numériques signées

  • des constantes alpha ( entre ' apostrophe simple ) pour mettre une apostrophe dans le texte, doubler l'apostrophe

  • les fonctions d'agrégation COUNT, MIN, MAX, SUM, AVG

  • des fonctions scalaires

  • des fonctions date

  • des variables d'environnement ODBC

  • des paramètres dynamiques ( ? )


search_condition désigne une expression logique avec des opérateurs NOT, AND et OR avec des parenthèses.
Les éléments de base d'une expression logique sont les suivants :

  • expression < | > | <= | >= | = | <> expression

  • expression [NOT] BETWEEN expression AND expression

  • expression [NOT] IN (valeur [,...])

  • expression [NOT] LIKE masque masque est une chaîne de caractères, où _ désigne un caractère quelconque et % une suite quelconque de caractères ( même vide ).


Fonctions Scalaires
Le driver ODBC prend en charge la gestion des fonctions scalaires suivantes :

Fonctions Date

Commentaire

Current_Date() ou CurDate()

Date du jour

Current_time(precision) ou Curtime()

Heure





DayOfMonth(date)

Jour du mois dans une date

Month(date)

Mois dans une date

Year(date)

Année dans une date



Fonctions Chaîne

Commentaire

Lcase(chaîne) ou Lower(chaîne)

Conversion minuscule

Ucase(chaîne) ou Upper(chaine)

Conversion majuscule

Left(chaîne,nb)

Partie gauche

Right(Chaîne,nb)

Partie droite

Substring(Chaîne,pos,lg)

Sous-chaîne






La syntaxe officielle pour l'appel de fonctions ODBC est { fn scalar-fonction(param) }
Par exemple : Select { fn lcase(nom) } from Client ;
Le driver accepte également la syntaxe scalar-fonction(param)
Par exemple : Select lcase(nom) from Client ;

Fonctions Date
Des fonctions spécifiques du driver Harmony permettent de faciliter le traitement des dates, et de développer des vues ou des requêtes SQL indépendantes de la période.
Par exemple la clause :
DateFacture between Har_FirstDayofLastMonth() and Har_LastDayofLastMonth()
donnera tous les mois les factures du mois précédent. Il n'est pas nécessaire d'adapter la requête chaque mois.

Fonctions Date

Commentaire

Har_Yesterday()

Hier

Har_FirstDayofMonth()

Premier jour du mois courant

Har_LastDayofMonth()

Dernier jour du mois courant

Har_FirstDayofLastMonth()

Premier jour du mois – 1

Har_LastDayofLastMonth()

Dernier jour du mois – 1

Har_FirstDayofMonthLastYear()

Premier jour du mois année n-1

Har_LastDayofMonthLastYear()

Dernier jour du mois année n-1

Har_FirstDayofYear()

Premier jour de l'année courante

Har_LastDayofYear()

Dernier jour de l'année courante

Har_FirstDayofLastYear()

Premier jour de l'année – 1

Har_LastDayofLastYear()

Dernier jour de l'année – 1

Har_TodayLastYear()

Aujourd'hui l'année dernière

Har_FirstDayofLastMonthLastYear()

Premier jour du mois – 1 de l'année – 1

Har_LastDayofLastMonthLastYear ()

Dernier jour du mois – 1 de l'année – 1


Variables d'environnement ODBC
Les variables d'environnement ODBC à l'instar des fonctions de date, permettent de développer des vues ou des requêtes SQL paramétrables.
Exemple 1
La variable MonDossier peut désigner le dossier de l'utilisateur courant. Ainsi la même requête peut être utilisée pour traiter le dossier 2 pour l'utilisateur Durand et le dossier 3 pour l'utilisateur Dupuis.
On écrira dans la clause
Where Dossier = MonDossier
Exemple 2
De la même manière, on peut utiliser deux variables pour définir les dates de début et de fin d'exercice comptable. Ainsi la requête n'aura pas besoin d'être adaptée lors du changement d'exercice, il suffira de modifier les valeurs des variables d'environnement.
Where DateEcriture between DateDebutExercice() and DateFinExercice()
Fichiers paramètre
Les fichiers paramètres fodbc.txt et fodbclocal.txt permettent de définir les noms, les valeurs et types des variables d'environnement ODBC.
Le fichier fodbc.txt contient des valeurs générales valables pour tous les utilisateurs, comme la date début d'exercice. Il sera en général sur le serveur de données.
Tandis que le fichier fodbclocal.txt contiendra plutôt des valeurs liées à l'interrogation en cours comme les dates de début et de fin d'interrogation ou le dossier de l'utilisateur. Il sera en général sur le poste de travail.
Si une variable est définie à la fois dans fodbc.txt et dans fodbclocal.txt, la valeur locale prévaut sur la valeur générale.
Ces variables sont stockées au format <hmp> dans les fichiers paramètres.

  • <nom> le nom de la variable

  • <valeur> la valeur de la variable

  • <type> le type de la variable (A, N, D ou L)


Le paramètre type est facultatif.
Exemple
<nom>sys_refcli<valeur>3<type>A
<nom>sys_dated<valeur>30/01/2004
<nom>sys_datef<valeur>30/03/2004
<nom>sys_autreval<valeur>123,45
Le type <L> permet de définir une liste de valeurs pour l'opérateur IN de SQL.
Exemple : <Nom>Departement<Type>L<Valeur>67,68
On accède à une variable en SQL avec les syntaxes suivantes :{ fn NomVariable } { fn NomVariable () }, NomVariable () ou NomVariable
Remarques :

  • Les préfixes divalto, Divalto_ et sys_ sont réservés pour Divalto.

  • Si vous ajoutez des valeurs, il est important de les préfixer pour ne pas entrer en conflit avec des noms de champ ou des mots clés du langage SQL.


Attention :
Le fichier Fodbclocal.txt est systématiquement stocké dans le répertoire Windows
Documents and settings\<user>\Application Data\Divalto
propre à chaque utilisateur.