+ Répondre à la discussion
Affichage des résultats 1 à 14 sur 14
  1. #1
    Membre actif
    Inscrit en
    mars 2007
    Messages
    308
    Détails du profil
    Informations forums :
    Inscription : mars 2007
    Messages : 308
    Points : 170
    Points
    170

    Par défaut Basculer de HF/CS vers une autre BDD

    Bonjour,

    Comme évoqué sur un autre topic je suis en train de développer une application Windev avec une BDD HF/CS. L'application brassera "beaucoup" de données à terme et j'ai peur des performances... Je ferai des tests de requête d'ici 2 semaines avec de vraies données (équivalent à 2 années) et je verrai ce qu'il en est.

    En attendant, si les tests se soldent par des résultats catastrophiques, il faudra envisager de passer sur une autre base. Et là j'ai plusieurs questions (je précise que j'ai trouvé des réponses partielles dans l'aide mais votre retour d'expérience permettra de les compléter) et je vous prie d'excuser ma grande ignorance sur le sujet...

    1) Quelle base gratuite choisir, si possible en Accès Natif ?

    2) Que change l'accès Natif par rapport à un accès OLEDB par exemple ?

    3) J'ai toujours travaillé en HF, et je ne sais pas quels éléments/processus gérés en automatique par Windev pour l'HF, je devrai gérer manuellement avec une autre base ?
    * Qu'en est-il de la synchronisation, des fonctions H*, des affectations directes (<=> EcranVersFichier), des transactions ... ? La doc en parle mais je n'arrive pas au final à savoir exactement ce que je vais devoir recoder, pouvez-vous m'éclairer sur le sujet ?

    4) Quelles sont les étapes à réaliser sous Windev pour passer d'une BDD HF/CS à une autre base (hors programmation) ? (sachant que je n'ai pas encore de version de prod chez des clients, nous abordons les tests, donc a priori pas de données à récupérer)

    Merci de votre aide précieuse

  2. #2
    Expert Confirmé
    Homme Profil pro
    Développeur freelance
    Inscrit en
    juillet 2002
    Messages
    1 881
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gard (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Développeur freelance

    Informations forums :
    Inscription : juillet 2002
    Messages : 1 881
    Points : 3 786
    Points
    3 786

    Par défaut

    Bonjour

    Je vais apporter quelques réponses en fonction de mon expérience

    1) Quelle base gratuite choisir, si possible en Accès Natif ?
    Avec Windev sont livré deux accès natifs interressants : MySql et PostgreSQL.
    Je te conseillerai vivement PostgreSQL, au niveau performance et surtout du fait que MySql c'est maintenant Oracle et qu'on ne sait pas trop comment ça va évoluer


    2) Que change l'accès Natif par rapport à un accès OLEDB par exemple ?
    En théorie plus performant mais surtout rien à installer sur le poste client.
    En effet le provider OLEDB est parfois installé pour certaines bases mais en général on doit le faire nous même, ou en installer un meilleur
    De plus certaines bases n'ont pas ou plus de provider OLEDB : MySql a arrêté, SQL Server projette de l'arrêter ...

    3) J'ai toujours travaillé en HF, et je ne sais pas quels éléments/processus gérés en automatique par Windev pour l'HF, je devrai gérer manuellement avec une autre base ?
    * Qu'en est-il de la synchronisation, des fonctions H*, des affectations directes (<=> EcranVersFichier), des transactions ... ? La doc en parle mais je n'arrive pas au final à savoir exactement ce que je vais devoir recoder, pouvez-vous m'éclairer sur le sujet ?
    Si par synchronisation tu veux dire mise à jour automatique de la structure des bases, là il faut oublier : il faudra gérer toi même les évolutions de structure par du SQL (ce qui n'est pas très compliqué) ou te faire tes propres procédures de modif auto.
    Pour les fonctions H* et les affectations directe aucun problème, concernant les transactions je ne sais pas.

    De mon coté je code principalement en SQL et le changement de base est plutôt facile, il faut bien sur éviter des syntaxes SQL exotiques ou non standard (ou gérer des cas particuliers par base si on ne peut pas faire autrement)
    J'ai bossé il y a quelques temps par exemple sur une appli qui travaille soit en DB2/400 soit en SQLite, et le code est le même

    A dispo pour d'autres infos si tu as besoin

  3. #3
    Membre actif
    Inscrit en
    mars 2007
    Messages
    308
    Détails du profil
    Informations forums :
    Inscription : mars 2007
    Messages : 308
    Points : 170
    Points
    170

    Par défaut

    Voici ce que j'ai compris d'après l'aide, corrigez moi si je me trompe.

    Citation Envoyé par cladoo Voir le message
    2) Que change l'accès Natif par rapport à un accès OLEDB par exemple ?
    L'accès natif permet d'utiliser les fonctions H, tout comme pour une connexion HF/CS, et accélère la vitesse par rapport à un accès OLEDB.

    Citation Envoyé par cladoo Voir le message
    3) J'ai toujours travaillé en HF, et je ne sais pas quels éléments/processus gérés en automatique par Windev pour l'HF, je devrai gérer manuellement avec une autre base ?
    * Qu'en est-il de la synchronisation, des fonctions H*, des affectations directes (<=> EcranVersFichier), des transactions ... ? La doc en parle mais je n'arrive pas au final à savoir exactement ce que je vais devoir recoder, pouvez-vous m'éclairer sur le sujet ?
    Cf point 2, l'accès natif a priori permet d'utiliser les fonctions H*, avec quelques limitations. Si j'ai bien compris la synchronisation se fait de la même manière qu'avec une base HF/CS. Les transactions nécessitent d'utiliser des fonctions spécifiques.

  4. #4
    Membre actif
    Inscrit en
    mars 2007
    Messages
    308
    Détails du profil
    Informations forums :
    Inscription : mars 2007
    Messages : 308
    Points : 170
    Points
    170

    Par défaut

    Citation Envoyé par hpascal Voir le message
    Si par synchronisation tu veux dire mise à jour automatique de la structure des bases, là il faut oublier : il faudra gérer toi même les évolutions de structure par du SQL (ce qui n'est pas très compliqué) ou te faire tes propres procédures de modif auto.
    Pour les fonctions H* et les affectations directe aucun problème, concernant les transactions je ne sais pas.

    De mon coté je code principalement en SQL et le changement de base est plutôt facile, il faut bien sur éviter des syntaxes SQL exotiques ou non standard (ou gérer des cas particuliers par base si on ne peut pas faire autrement)
    J'ai bossé il y a quelques temps par exemple sur une appli qui travaille soit en DB2/400 soit en SQLite, et le code est le même

    A dispo pour d'autres infos si tu as besoin
    Merci beaucoup pour ces informations précieuses. En effet j'hésitais entre MySql et PostgreSQL, ça me confirme que ces 2 bases sont un choix intéressant. Tes infos concernant PostgreSQL sont également très intéressantes quant à l'avenir de la base.

    Si j'ai bien compris, on n'a quasiment rien à modifier dans le code, hormis si les requêtes contiennent du code Windev (exemple WL.GAUCHE ...) ou une syntaxe SQL non formaté ? ça m'arrangerait franchement, surtout concernant les affectations directes, et fonctions H*...

    Finalement le plus gros point noir pour moi concerne la fameuse évolution de la structure par du SQL (chose quasiment jamais réalisée pour moi)

    Concrètement comme cela se passe-t-il ?
    On décide d'une nouvelle rubrique, ou d'une nouvelle table ou d'une modification, on réalise cette modif dans l'analyse sous Windev, et ensuite il faut déterminer le code SQL correspondant pour l'exécuter sur le moteur choisi et ainsi permettre la synchronisation ? J'ai tellement la (mauvaise) habitude de laisser faire Windev que je ne sais même pas comment procéder...

  5. #5
    Membre habitué

    Inscrit en
    février 2011
    Messages
    34
    Détails du profil
    Informations forums :
    Inscription : février 2011
    Messages : 34
    Points : 101
    Points
    101

    Par défaut

    Citation Envoyé par cladoo Voir le message

    Concrètement comme cela se passe-t-il ?
    On décide d'une nouvelle rubrique, ou d'une nouvelle table ou d'une modification, on réalise cette modif dans l'analyse sous Windev, et ensuite il faut déterminer le code SQL correspondant pour l'exécuter sur le moteur choisi et ainsi permettre la synchronisation ? J'ai tellement la (mauvaise) habitude de laisser faire Windev que je ne sais même pas comment procéder...
    bonjour
    je me permets de me greffer à cette discution car je suis dans le même cas.
    jusqu'à présent, je décrivais les fchiers dans l'analyse en HF classique, et selon le client, je restais en HF ou en C/S.
    en utilisant tous les automatismes (maj bdd...) que propose windev.

    je passerais bien à PostgreSQL, car je reproche à Hyperfile une gestion catastrophique du SQL, et un manque de performance.

    Mais alors comment faire son analyse ? (directement avec des fichiers de type PostgreSQL, mais quid de la connexion changeante d'un client à l'autre)

    comment faire les mises à jour des fichiers de données?

    vos retours sont les bienvenus!
    merci

  6. #6
    Membre expérimenté
    Homme Profil pro
    Consultant
    Inscrit en
    octobre 2004
    Messages
    253
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2004
    Messages : 253
    Points : 563
    Points
    563

    Par défaut

    Citation Envoyé par cladoo Voir le message
    Finalement le plus gros point noir pour moi concerne la fameuse évolution de la structure par du SQL (chose quasiment jamais réalisée pour moi)

    Concrètement comme cela se passe-t-il ?
    On décide d'une nouvelle rubrique, ou d'une nouvelle table ou d'une modification, on réalise cette modif dans l'analyse sous Windev, et ensuite il faut déterminer le code SQL correspondant pour l'exécuter sur le moteur choisi et ainsi permettre la synchronisation ? J'ai tellement la (mauvaise) habitude de laisser faire Windev que je ne sais même pas comment procéder...
    Attention, c'est effectivement le point le plus délicat.

    2 options possibles :

    - solution la plus simple : soit tu gère ça par des scripts "manuels" de mises à jour.
    Par exemple, quand tu crées une nouvelle rubrique : tu prévois un script de mise à jour (une requete SQL) qui va modifier la structure de la table pour rajouter la rubrique dans ta base Postgres (par exemple).
    Il faut gérer un n° de version du schéma de la BDD, qui te permet de déclencher automatiquement le script au lancement de l'application.
    Par ex : si n° version BDD < 2 alors appliquer script MAJ BDD v2

    Il faut simplement préparer ses scripts avant chaque diffusion d'une maj.

    - solution la plus élégante intellectuellement, la plus automatisée mais beaucoup plus compliquée :
    tu codes l'équivalent de WDModif mais qui fonctionne avec une BDD tierce : là il se faut se baser sur les Information Schema, qui sont des tables systèmes normalement implémentées dans les BDD (car normalisées par la norme SQL).
    Mais 2 difficultés :
    - malgré la norme, il y a des différences entre ces information schema entre les différentes BDD
    - ENORME DIFFICULTE : Windev ne permet pas de lire la propriété ..GuidRubrique d'une rubrique (malgré plusieurs demandes en ce sens au ST depuis 2 ans), ce qui empêche de détecter automatiquement un changement de nom de rubrique (car comment faire dès lors pour faire la différence entre un changement de nom et une nouvelle rubrique ??). On peut contourner ce problème, soit en indiquant manuellement les changements de noms (mais on perd en automatisation) soit en lisant le contenu du fichier RUBFIC.FIC dans le répertoire de l'analyse (mais c'est galère).

    Perso, nous avons fais le choix de la 2ème option et ca nous a pris plusieurs mois pour développer un module automatique pour Posgres...

    A+, Arnaud.

  7. #7
    Membre actif
    Inscrit en
    mars 2007
    Messages
    308
    Détails du profil
    Informations forums :
    Inscription : mars 2007
    Messages : 308
    Points : 170
    Points
    170

    Par défaut

    Citation Envoyé par Arnaud B. Voir le message
    Attention, c'est effectivement le point le plus délicat.

    2 options possibles :

    - solution la plus simple : soit tu gère ça par des scripts "manuels" de mises à jour.
    Par exemple, quand tu crées une nouvelle rubrique : tu prévois un script de mise à jour (une requete SQL) qui va modifier la structure de la table pour rajouter la rubrique dans ta base Postgres (par exemple).
    Il faut gérer un n° de version du schéma de la BDD, qui te permet de déclencher automatiquement le script au lancement de l'application.
    Par ex : si n° version BDD < 2 alors appliquer script MAJ BDD v2

    Il faut simplement préparer ses scripts avant chaque diffusion d'une maj.

    - solution la plus élégante intellectuellement, la plus automatisée mais beaucoup plus compliquée :
    tu codes l'équivalent de WDModif mais qui fonctionne avec une BDD tierce : là il se faut se baser sur les Information Schema, qui sont des tables systèmes normalement implémentées dans les BDD (car normalisées par la norme SQL).
    Mais 2 difficultés :
    - malgré la norme, il y a des différences entre ces information schema entre les différentes BDD
    - ENORME DIFFICULTE : Windev ne permet pas de lire la propriété ..GuidRubrique d'une rubrique (malgré plusieurs demandes en ce sens au ST depuis 2 ans), ce qui empêche de détecter automatiquement un changement de nom de rubrique (car comment faire dès lors pour faire la différence entre un changement de nom et une nouvelle rubrique ??). On peut contourner ce problème, soit en indiquant manuellement les changements de noms (mais on perd en automatisation) soit en lisant le contenu du fichier RUBFIC.FIC dans le répertoire de l'analyse (mais c'est galère).

    Perso, nous avons fais le choix de la 2ème option et ca nous a pris plusieurs mois pour développer un module automatique pour Posgres...

    A+, Arnaud.

    Merci pour votre retour.
    Est-ce que vous commercialisez votre module ? Etant seul sur mon projet, je n'ai ni le temps, ni les compétences pour un tel développement.

  8. #8
    Invité régulier
    Inscrit en
    juin 2009
    Messages
    3
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 3
    Points : 8
    Points
    8

    Par défaut Bascule vers une autre BDD

    bonjour, j'ai effectué cette bascule l'année dernière, voici les difficultés rencontrées :
    - Gestion des colonnes-tableaux HF non prise en compte sous MYsql
    - gestion des valeurs NULL différentes entre HF et MYSQL
    - gestion des clef composée de recherches
    -remplacement des fonction H* par des requetes SQL . certaines fonctions H* bien que compatible renvois des résultat différents sous MYSQL ( filtres, ordre etc etc)

    Bon courage

  9. #9
    Membre expérimenté
    Homme Profil pro
    Consultant
    Inscrit en
    octobre 2004
    Messages
    253
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2004
    Messages : 253
    Points : 563
    Points
    563

    Par défaut

    Citation Envoyé par cladoo Voir le message
    Merci pour votre retour.
    Est-ce que vous commercialisez votre module ? Etant seul sur mon projet, je n'ai ni le temps, ni les compétences pour un tel développement.
    Ah non désolé.
    Il faudrait le packager, le documenter... que du boulot

  10. #10
    Membre expérimenté
    Homme Profil pro
    Consultant
    Inscrit en
    octobre 2004
    Messages
    253
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2004
    Messages : 253
    Points : 563
    Points
    563

    Par défaut

    Citation Envoyé par zatoichi31 Voir le message
    bonjour, j'ai effectué cette bascule l'année dernière, voici les difficultés rencontrées :
    - Gestion des colonnes-tableaux HF non prise en compte sous MYsql
    - gestion des valeurs NULL différentes entre HF et MYSQL
    - gestion des clef composée de recherches
    -remplacement des fonction H* par des requetes SQL . certaines fonctions H* bien que compatible renvois des résultat différents sous MYSQL ( filtres, ordre etc etc)

    Bon courage
    J'ai aussi rencontré le problème suivant sur la migration des données elles-mêmes vers PG (Posgres) :

    Soit dans l'analyse Windev une contrainte de clé étrangère de cardinalité 0,1, avec sur le fichier HF la propriété ..NullSupporté = Faux.

    Avec HF, la valeur 0 (pour un numérique) ou '' '' (pour une chaine) signifie qu'il n'y a pas de clé étrangère à vérifier.
    Avec PG : la valeur 0 est recherchée dans la table étrangère et la contrainte est violée si la valeur 0 n'existe pas (ce qui est évidemment le cas).

    L'accès natif et les fonctions HLitXXX gèrent elle ce problème ?
    Hé bien non !
    Conséquence :
    dans l'analyse, il faut mettre les tables à ..NullSupporté = Vrai
    Toutes les rubriques seront dès lors à ..NullAutorisé = Vrai

    Puis faire une moulinette dans windev pour passer toutes les valeurs 0 à Null avant d'importer les données dans PG.

  11. #11
    Membre expérimenté
    Homme Profil pro
    Consultant
    Inscrit en
    octobre 2004
    Messages
    253
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2004
    Messages : 253
    Points : 563
    Points
    563

    Par défaut

    Autre problème rencontré :
    la fonction HgèreIntégrité() n'est pas utilisable avec les accès natifs !

    Par conséquent, l'activation/désactivation de contraintes devra se faire directement par des ordres SQL :

    Désactivation d'une contrainte = suppression d'une contrainte

    Ex (avec Posgres) :
    ALTER TABLE nom_table DROP CONSTRAINT [ IF EXISTS ] nom_contrainte [ RESTRICT | CASCADE ]

    Paralèlement, activation d'une contrainte = ajout d'une contrainte

  12. #12
    Membre actif
    Inscrit en
    mars 2007
    Messages
    308
    Détails du profil
    Informations forums :
    Inscription : mars 2007
    Messages : 308
    Points : 170
    Points
    170

    Par défaut

    Merci à tous pour vos retours d'expérience, c'est très précieux.

    Si d'autres points posent problème lors d'une migration sur une autre BDD, surtout n'hésitez pas à les évoquer et à indiquer comment vous avez résolu le problème.

    Il pourrait être intéressant de constituer une "base de connaissance" sur les bonnes pratiques, points à vérifier, subtilités constituée par vos retours d'expérience lorsqu'on laisse HF pour une autre base, qu'en pensez-vous ?

  13. #13
    Membre expérimenté
    Homme Profil pro
    Consultant
    Inscrit en
    octobre 2004
    Messages
    253
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2004
    Messages : 253
    Points : 563
    Points
    563

    Par défaut

    Citation Envoyé par cladoo Voir le message
    Merci à tous pour vos retours d'expérience, c'est très précieux.

    Si d'autres points posent problème lors d'une migration sur une autre BDD, surtout n'hésitez pas à les évoquer et à indiquer comment vous avez résolu le problème.

    Il pourrait être intéressant de constituer une "base de connaissance" sur les bonnes pratiques, points à vérifier, subtilités constituée par vos retours d'expérience lorsqu'on laisse HF pour une autre base, qu'en pensez-vous ?
    Complètement.
    On fait ça comment ?

  14. #14
    Membre expérimenté
    Homme Profil pro
    Consultant
    Inscrit en
    octobre 2004
    Messages
    253
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2004
    Messages : 253
    Points : 563
    Points
    563

    Par défaut

    Autre problème rencontré lors de la migration HF -> PG :

    Si on utilise le script de création de Windev, celui-ci met tous les noms de tables, contraintes... en majuscules, et entre guillemets (en tout cas avec WD16, je n'ai pas réessayé depuis). Et on n'a pas le choix.

    Or en SQL, mettre des guillemets doubles autour d'un nom d'objet, c'est rendre celui-ci sensible à la casse.

    Dès lors, si les noms sont en majuscules, si vous utilisez le nom en minuscule dans une requete : résultat : erreur dans Posgres, nom inconnu.

    En revanche, avec les ordres HLitXXX(), je crois me souvenir que c'est retraité.

    Moralité : ne pas utiliser le script SQL de création de Windev tel quel, car mieux vaut garder les noms insensibles à la casse !
    Et je ne parle pas des autres bugs de ce script de création, je ne les ai même plus tous en tête...

    Cdlt, Arnaud.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •