Discussion :

[cladoo]

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

[hpascal]

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

[cladoo]

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

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.

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.

[cladoo]

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...

[bejibe]

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

[Arnaud B.]

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.

[cladoo]

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.

[zatoichi31]

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

[Arnaud B.]

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

[Arnaud B.]

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.

[Arnaud B.]

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

[cladoo]

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 ?

[Arnaud B.]

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 ?

[Arnaud B.]

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.