Application WinDev et Moteur HyperFile

Modifications:
27/05/2010. Compléments (remarques; nom logique d'une source de données).
12/05/2010. Ajout sur les Fichiers Alias.
08/05/2010. Compléments (sources de données; HExécuteRequêteSQL()).
04/05/2010. Merci à Bowen pour ses corrections que j'ai essayé d'intégrer dans le message.
_

Je vous livre ma compréhension du fonctionnement d’une application WinDev avec le moteur HyperFile. Cette réflexion est directement liée à plusieurs discussions auxquelles j‘ai participé sur le forum WinDev de DVP.

Je suis intéressé par vos commentaires, en particulier en cas de mauvaise compréhension de ma part, mais aussi par toute information qui pourra enrichir ce message. Merci.

Motivation

Les débutants WinDev/HyperFile sont un jour ou l’autre confrontés à ce message d’erreur :

Fichier <nom du fichier> inconnu dans l'analyse <nom de l’analyse>, ou requête ou vue non initialisée.
Quand il ne s’agit pas d’une simple étourderie, cette erreur est révélatrice d’une mauvaise compréhension du fonctionnement d’une application WinDev avec le moteur de données HyperFile.

Dans ce qui suit, j’essaye d’expliquer les conditions dans lesquelles une application WinDev peut utiliser le moteur de données HyperFile pour accéder aux données.

Remarque: à ce stade de l‘explication, je préfère ne pas faire apparaître la notion de «contexte HyperFile» qui n’est pas nécessaire à la compréhension.

Le moteur HyperFile manipule des jeux de données qui lui ont été déclarés

Le moteur HyperFile utilisé par l’application WinDev travaille à partir d’un ensemble de jeux de données.
Un jeu de données est un ensemble de lignes de données, comme par exemple les enregistrements contenus dans un fichier de données, ou encore le résultat d’une requête de sélection de données.

A chaque jeu de données est associé un nom logique nécessaire pour le désigner dans l'application ainsi que dans les requêtes, les vues...
Ce nom logique est unique: déclarer un jeu de données avec un nom logique déjà connu par le moteur HyperFile aura pour conséquence de remplacer le précédent jeu de données (effet de bord intéressant mais dangereux !).
Ce nom logique est de portée globale (il n'y a pas de notion de portée locale).

Pour utiliser un jeu de données dans une application, il doit d’abord être déclaré au moteur HyperFile.
Par exemple, les fonctions HAjoute(), HModifie() ou HSupprime() commandent au moteur HyperFile d’ajouter, modifier ou supprimer une ligne dans un jeu de données qui lui a été préalablement déclaré.

Selon le type du jeu de données, la manière de le déclarer peut varier (cf. http://doc.pcsoft.fr/fr-FR/?type).

Citation:

Envoyé par WinDev: Les différents types de jeux de données

Fichier normal (Hyper File Classic), Fichier OLE DB, Fichier AS 400, Fichier HyperFile Client / Serveur, Fichier HyperFile 5, Fichier MySQL, Fichier PostgreSQL, Fichier Oracle, Fichier Oracle Lite, Fichier Progress, Fichier SQL Server, Fichier SQL Server CE, Fichier Sybase, Fichier temporaire, Fichier xBase, Fichier XML.

Requête Sélection. Requête sur une base de données accédée par un provider OLE DB.
Requête sur une base de données Hyper File Classic, Hyper File Client Serveur, AS/400, MySQL, PostgreSQL, Oracle, Oracle Lite, SQL Server, SQL Server Mobile, Sybase, XML.

Vue HyperFile.

• Remarques

(1) La terminologie employée dans WinDev/HyperFile est particulière. Dans le tableau ci-dessus qui liste les types de jeux de données, le terme fichier (ou fichier de données) est synonyme de "Table d'une base de données".

(2) Une Vue HyperFile n'est pas une Vue au sens SQL (pas de CREATE VIEW). Cependant, le nom logique d'une Vue HyperFile peut être utilisé dans une requête SQL.

(3) En général, dans la "littérature WinDevienne", l'expression «Fichier HyperFile» signifie «un jeu de données déclaré au moteur HyperFile, dans un certain contexte HyperFile».
Par conséquent, l'expression «Fichier HyperFile» peut très bien désigner un "Fichier de données", le résultat d'une "Requête Sélection" ou une "Vue HyperFile".
_
Donc, avant de pouvoir manipuler un jeu de données dans une application, il est primordial de savoir s’il a été déclaré au moteur HyperFile.

Quelles sont les règles de déclaration d’un jeu de données ?

• Fichiers de données
Pour les «fichiers de données», si l’application est issue d'un projet qui utilise une «analyse», alors tous les fichiers décrits dans l’analyse sont automatiquement déclarés au moteur HyperFile, dès le démarrage de l’application.

Si ces fichiers existent physiquement, ils sont (en principe) autant de jeux de données directement utilisables par programmation en WLangage, ou dans des champs de fenêtre.

Remarque 1:
La fonction HOuvre() n’est nécessaire que pour spécifier un mot de passe. En outre, la fonction HPasse() permet de déclarer le mot de passe à employer pour un fichier en particulier, ou pour tous les fichiers.

Remarque 2:
Si on programme en WLangage, l'ouverture du fichier de données ne suffit pas pour accéder au contenu du jeu de données; il faut exécuter au préalable une fonction de lecture (par exemple, HLit(), HLitPremier()).

Si ces fichiers n’existent pas physiquement, ils doivent être d’abord créés avant toute autre opération (cf. les fonctions HCréation() et HCréationSiInexistant())

En dehors de l’analyse utilisée par l’application, il est possible de déclarer explicitement des fichiers de données (cf. les fonctions HDéclare(), HDéclareExterne() et HDécritFichier())

Les Fichiers Alias:
Il est aussi possible déclarer un «Fichier Alias» au moteur HyperFile.
Le Fichier Alias est relatif à un "fichier de référence" déjà connu par HyperFile, dont il hérite de la structure (rubriques, clés, liaisons).
Le Fichier Alias introduit un nouveau nom logique associé à une description d'un fichier physique (cf. la fonction HAlias()).

Par défaut, le fichier physique désigné par l'alias est un nouveau fichier différent de celui du "fichier de référence".
Dans ce cas, le jeu de données de l'Alias et le jeu de données du "fichier de référence" opèrent sur des enregistrements physiquement distincts puisqu'ils appartiennent à des fichiers distincts.

On peut aussi choisir que l'alias utilise le même fichier physique que celui référencé dans l'appel à la fonction HAlias() (il faudra exécuter la fonction HChangeNom()).
Dans ce cas, les jeux de données opèrent sur les mêmes enregistrements physiques, mais ils sont manipulés indépendamment (positions différentes, filtres différents). Cette fonctionnalité pratique permet de gérer "simplement" différents "contextes de fichier".

• Requêtes définies dans l’éditeur
Pour les requêtes définies avec l’éditeur de requêtes dans le projet de l’application, il n’y a pas de déclaration automatique au moteur HyperFile. Par conséquent, au démarrage de l’application les requêtes ne sont pas connues du moteur HyperFile.

Pour accéder au jeu de données d’une requête de sélection de données, il faut d’abord exécuter la fonction HExécuteRequête().
Cette fonction permet de déclarer le jeu de données au moteur HyperFile. Cependant le moteur HyperFile ne ne lance pas l'exécution de la requête, il ne fait que la préparer.

La connaissance de cette caractéristique est primordiale quand on programme directement en WLangage: c'est la première lecture du jeu de données qui lance l'exécution réelle de la requête (exemple : HLitPremier(), HLitRecherchepremier(), HNbEnr()).

Cas des requêtes de requêtes:
Une «requête de requêtes» est une requête qui utilise les données issues d’une ou plusieurs autres requêtes, que j’appellerai "requêtes imbriquées" (pour bien faire la distinction avec les sous-requêtes SQL).
Comme chaque requête imbriquée est elle-même définie dans le projet de l’application, il est nécessaire d’exécuter la fonction HExécuteRequête() pour chacune d’entre elles, dans l’ordre logique de leur utilisation par le moteur HyperFile..

Exception: Déclaration automatique d’une requête.
Dans le cas d'un «champ de fenêtre» basé sur une requête, il n'est pas nécessaire d'exécuter la fonction HExécuteRequête().
En effet, si le jeu de données correspondant à cette requête n'est pas déjà connu par le moteur HyperFile, alors l'application exécute automatiquement HExécuteRequête() lors de l’affichage du champ.
Cela concerne les champs de fenêtre de type Table, Zone Répétée, Liste ou Combo, basés sur une requête.

Remarque: attention à l’utilisation d’une requête paramétrée qui nécessite de spécifier les paramètres avant l’affichage du champ de fenêtre (la documentation en ligne est claire sur ce point).

Cependant cette fonctionnalité est limitée dans le cas d'un champ de fenêtre basé sur une «requête de requêtes» qui impose quand même une ou plusieurs déclarations explicites des requêtes imbriquées.

• Variables de type source de données
Il existe encore un autre moyen de déclarer un jeu de données : les variables de type source de données.
Une variable source de données permet de définir un jeu de données basé sur une «vue HyperFile», ou sur une requête SQL.
On peut aussi baser la source de données sur un alias de fichier (pas difficile) ou encore un alias de requête définie dans l'éditeur (mais pour l'instant ce n'est pas très pratique).

http://www.developpez.net/forums/ima...ons/report.gif Il faut savoir que, par défaut, le nom d'une variable source de données est utilisé comme nom logique pour le jeu de données.
Comme un nom logique HyperFile est obligatoirement unique et global, il faut faire attention à ce que les déclarations locales de plusieurs variables source de données avec le même nom n'entrent pas "en collision" au niveau du moteur HyperFile.
Pour contourner ce risque, il est aussi possible de spécifier le nom logique d'une source de données, avant de la déclarer au moteur HyperFile. Pour en savoir plus...
Une variable source de données a une durée de vie limitée: si elle est déclarée dans une procédure, elle est automatiquement détruite en sortie de cette procédure.
Quand une variable source de données est détruite (libérée), alors:
_ • le moteur HyperFile "libère" la collection de données associé à la source de données,
_ • le nom logique correspondant n'est plus valable.

• Fonction HExécuteRequêteSQL() utilisée sans source de données
Si on exécute la fonction HExécuteRequêteSQL() en spécifiant une chaîne de caractères pour le paramètre <Nom de la requête> alors le moteur HyperFile utilise cette chaîne pour créer un nom logique.
Ce nom logique est donc totalement sous le contrôle du développeur.
Il est ensuite utilisable tel quel dans les fonctions HyperFile, les requêtes, et les champs des fenêtres.
Pour retirer ce nom logique et libérer le jeu de données, il faut explicitement faire appel à la fonction HAnnuleDéclaration().
_