Astuce |
---|
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 :
...
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.
Ancre | ||||
---|---|---|---|---|
|
Source de données
Ancre | ||||
---|---|---|---|---|
|
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.
Ancre | ||||
---|---|---|---|---|
|
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.
Ancre | ||||
---|---|---|---|---|
|
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
Ancre | ||||
---|---|---|---|---|
|
Tables de la source
Ancre | ||||
---|---|---|---|---|
|
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:
...
Sous l'onglet « décimales variables » on trouve le paramétrage des décimales pour cette table. Voir annexe.
Ancre | ||||
---|---|---|---|---|
|
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 :
...
Pour les tables, l'import concerne toutes les tables de tous les fichiers permanents. (voir propriété fichier temporaire des objets « fichier »).
Ancre | ||||
---|---|---|---|---|
|
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 )
| Texte du bouton de la toolbar |
| Info bulle du bouton |
| Texte du choix dans le menu |
| Nom du fichier des tables spécifiques |
| 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.
Ancre | ||||
---|---|---|---|---|
|
Vues de la source
Ancre | ||||
---|---|---|---|---|
|
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:
...
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.
Ancre | ||||
---|---|---|---|---|
|
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 »
Ancre | ||||
---|---|---|---|---|
|
Gestion des vues
Ancre | ||||
---|---|---|---|---|
|
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 :
...
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.
...
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.
Ancre | ||||
---|---|---|---|---|
|
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
...
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
Ancre | ||||
---|---|---|---|---|
|
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 :
...
Ancre | ||||
---|---|---|---|---|
|
Driver ODBC
Ancre | ||||
---|---|---|---|---|
|
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.
Ancre | ||||
---|---|---|---|---|
|
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:
...
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.
Ancre | ||||
---|---|---|---|---|
|
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
Initialiser la clé de lecture du fichier
Positionner des filtres de lecture du fichier
...
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.
Ancre | ||||
---|---|---|---|---|
|
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
Ancre | ||||
---|---|---|---|---|
|
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 :
...
Ancre | ||||
---|---|---|---|---|
|
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
Ancre | ||||
---|---|---|---|---|
|
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 :
...
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
Ancre | ||||
---|---|---|---|---|
|
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)
Ancre | ||||
---|---|---|---|---|
|
Hyperion Intelligence Explorer
Ancre | ||||
---|---|---|---|---|
|
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.
Ancre | ||||
---|---|---|---|---|
|
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.
Ancre | ||||
---|---|---|---|---|
|
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.
Ancre | ||||
---|---|---|---|---|
|
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 »
Ancre | ||||
---|---|---|---|---|
|
Annexes
Ancre | ||||
---|---|---|---|---|
|
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
Ancre | ||||
---|---|---|---|---|
|
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).
Ancre | ||||
---|---|---|---|---|
|
Caractéristiques et limites du Serveur ODBC Harmony
...
Ancre | ||||
---|---|---|---|---|
|
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 ;
Ancre | ||||
---|---|---|---|---|
|
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 |
Ancre | ||||
---|---|---|---|---|
|
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.
...