IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Contribuez Discussion :

Application WinDev et Moteur HyperFile


Sujet :

Contribuez

  1. #1
    Membre émérite

    Profil pro
    Inscrit en
    Février 2005
    Messages
    1 751
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2005
    Messages : 1 751
    Points : 2 368
    Points
    2 368
    Par défaut 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).
    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().
    _

  2. #2
    Membre éprouvé
    Homme Profil pro
    Inscrit en
    Mars 2002
    Messages
    899
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations forums :
    Inscription : Mars 2002
    Messages : 899
    Points : 1 100
    Points
    1 100
    Par défaut
    Presque tout bon.

    • Requêtes définies dans l’éditeur
    HexecuteRequete() ne lance pas l'exécution de la requête, il ne fait que la préparer. C'est la première lecture qui lance l'exécution réelle de la requête (exemple : HLitPremier(), HLitRecherchepremier(), HNbEnr())

    Exception: déclaration automatique d’une requête.
    L'exception n'est en fait que du coté développeur. Le HExecuteRequete() est bien envoyé au moteur HyperFile, la seule différence est que le l'on ne le saisit pas, c'est windev qui s'en charge.
    De mémoire (ça fait un moment que j'ai testé), on peut le vérifier en activant les logs du serveur HF : on voit bien passer la commande.

Discussions similaires

  1. Réponses: 5
    Dernier message: 10/12/2007, 20h41
  2. Réponses: 1
    Dernier message: 13/11/2007, 10h10
  3. Utiliser un fichier Word avec une application Windev.
    Par Belgarath4 dans le forum WinDev
    Réponses: 7
    Dernier message: 18/07/2007, 18h04
  4. Réponses: 2
    Dernier message: 12/07/2007, 00h24
  5. Réponses: 3
    Dernier message: 15/10/2006, 19h46

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo