Discussion :

[Arnaud B.]

Bonjour,

Je fais suite à un sujet évoqué cet été sur le forum officiel de l'éditeur, qui mettait en évidence le problème suivant sur les jointures externes en SQL, pour lequel il n'y a pas aujourd'hui de solution.

En gros, le problème est le suivant :

Hyperfile ne fait pas la différence entre la syntaxe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
select * from A LEFT OUTER JOIN B on A.id=B.id WHERE B.lib=’test’

et la syntaxe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
select * from A LEFT OUTER JOIN B on (a.id=B.id AND B.lib=’test’)

Hyperfile interprète la 2ème requête comme la première, alors que ce n'est pourtant pas la même chose en SQL !

Dans la 2ème requête, la condition fait partie de la jointure : si elle n'est pas respectée, comme il s'agit d'une jointure externe, tous les enregistrements de la table A doivent néanmoins être ramenés.
Or Hyperfile l'applique comme une clause WHERE et ramène uniquement les enr. de A auxquels correspond un enr. de B avec B.lib = 'test'.

Je considère ce problème comme très pénalisant, car il m'oblige à utiliser plusieurs requêtes et du code pour arriver au résultat voulu, alors que cette requête fonctionne très bien avec d'autres bases SQL.

Par exemple (exemple fictif), si je veux ramener, par une requete SQL, la liste de tous les clients, et pour les clients qui ont une commande en cours (condition sur la table commande), afficher les informations de la commande : je ne peux pas le faire en une requete SQL avec Hyperfile.


J'ai transmis ce pb au support technique qui l'a enregistré en tant que "suggestion", sans qu'il y ait de correction à ce jour.

D'après un autre développeur, ce pb aurait été enregistré le 8 juillet 2009 sous le n°62273

Afin de mettre en évidence ce pb, j'ai réalisé un petit projet WD15 que j'ai mis en ligne :

http://www.covelys.fr/maj/test_jointure_externe.zip

Ce projet permet d'effectuer différents tests avec HF Classic, permet également de se connecter à une base PosgreSQL (connue pour son très bon respect de la norme SQL) pour comparer les résultats avec HF Classic. Ce qui permet de constater que les résultats, pour une même requête, sont très différents.

Si vous êtes concernés/intéressés par ce pb, merci de tester le projet et de faire part de vos remarques.

Je serai également intéressé de savoir comment vous contournez cette limitation de Hyperfile.

Cdlt, Arnaud Benhamdine.

[Bowen]

Désolé, j'ai tenté de tester, mais je n'ai pas Prostgre installé, (et pas envie de l'installer).
Le bug me semblait pourtant réglé chez PC-soft...

[hpascal]

Bonjour

Je serai également intéressé de savoir comment vous contournez cette limitation de Hyperfile.

... en n'utilisant pas HyperFile

Bon ok, j'exagère un peu ... et puis on n'a pas toujours le choix

[Arnaud B.]

... en n'utilisant pas HyperFile

C'est effectivement la solution à laquelle je pense, en optant pour PosgreSQL par exemple...
Mais on perd en simplicité.

[tatayo]

Bonjour,
J'ai choisis la même solution depuis pas mal de temps, et ce que j'ai perdu en simplicité je l'ai gagné en fonctionnalités, performances... et en connaissance du SQL !

Tatayo.

[Bowen]

Question :
tu as testé si le comportement différait avec ou sans clé composée sur tes fichiers ?
(clé composée de ton ID et de ton Lib sur les champs textes)

[vmolines]

On peut poser la question mais la présence ou non d'index ne doit avoir aucune conséquence sur le jeu de résultats d'une requête de sélection.

[Bowen]

On peut poser la question mais la présence ou non d'index ne doit avoir aucune conséquence sur le jeu de résultats d'une requête de sélection.

Ne doit, je suis d'accord, mais n'a...
En 2008, nous avions un bug de ce type (vraie différence comportementale entre deux recherches, l'une indexée, et l'autre non, d'abord réglée par un patch de PCSoft)

La recherche se passe physiquement différemment, selon que la rubrique soit indexée ou non. (cf par exemple, les sensibles à la casse, ou accents, etc...)

[Arnaud B.]

Ne doit, je suis d'accord, mais n'a...
En 2008, nous avions un bug de ce type (vraie différence comportementale entre deux recherches, l'une indexée, et l'autre non, d'abord réglée par un patch de PCSoft)

La recherche se passe physiquement différemment, selon que la rubrique soit indexée ou non. (cf par exemple, les sensibles à la casse, ou accents, etc...)

Non je n'ai pas testé, mais je ne manquerai pas de le faire, au moins par curiosité.

Question subséquente à celle d'origine : pour ceux qui ont choisi d'utiliser un SGBD autre qu'Hyperfile, comment gérez vous les modifications de l'analyse ?
A la main (en générant un script SQL ALTER TABLE etc...) ?
Avec Windev ? (ce qui suppose que WDModif gère les bases externes, or je n'en ai pas l'impression... mais je manque de recul précisément sur ce point)
Avec un autre outil ?

Merci de vos précieuses contributions.

Cdlt, Arnaud.

[tatayo]

Question subséquente à celle d'origine : pour ceux qui ont choisi d'utiliser un SGBD autre qu'Hyperfile, comment gérez vous les modifications de l'analyse ?

En ce qui me concerne, la réponse est toute simple: aucune analyse...
Je fais tout à la main, mais comme les applications ne sont déployées que sur "mes" serveurs, ce n'est pas bloquant (je n'ai qu'une seule base à gérer).

Tatayo.

[vmolines]

En tenant à jour des scripts versionnés tout comme on tient à jour le code de son application.

Il ne faut pas faire confiance à l'analyse et à ses outils pour faire le travail de mise à jour de structure. Exemple avec une table qui possède un identifiant auto dans l'analyse, à la génération de script (ou en utilisant hcreationsiinexistant je ne sais plus), la colonne est créée en entier et l'accès natif fait ensuite un select max() + 1 pour donner une valeur à la colonne.

[Arnaud B.]

En tenant à jour des scripts versionnés tout comme on tient à jour le code de son application.

Donc je suppose en suivant grosso modo le principe suivant :
- stocker un numéro de version de la structure des données dans une table, à chaque modification (l'équivalent du n° d'analyse)
- déclencher le bon script de modification de la structure des données (script ALTER TABLE etc...) quand on détecte un ancien numéro de version.

N'est ce pas très lourd à gérer si on doit upgrader de plusieurs versions d'un coup ?
N'y a-t-il pas moyen de conserver l'analyse dans Windev, de générer les scripts SQL de mise à jour, qu'on pourrait éventuellement modifier pour gérer les éventuels problèmes de format que tu évoquais ?

Cordialement, Arnaud.

[hpascal]

Bonjour

En tenant à jour des scripts versionnés tout comme on tient à jour le code de son application

Idem et même pour des applis à grande diffusion ça fonctionne très bien
Je le fais depuis des années sur MySql (natif) et maintenant sur DB2/400 (OLEDB)

Dans la pratique j'ai un script par version du logiciel (ex : maj_1005A.sql pour la version 1005A d'une appli)

Ces scripts de mise à jour sont recherchés au démarrage de l'application (maj_*.sql) dans un dossier spécifique
Ainsi pour gérer le passage de plusieurs versions d'un coup il suffit d'avoir les différents scripts dans ce dossier
Ensuite à chaque fois qu'un script est exécuté il est déplacé en archive et historisé dans une table de l'application
Ceci permet de ne pas réexécuter un script au cas ou on le redéposerait dans le dossier des scripts (réinstallation de l'appli par exe.)

C'est une méthode, il y en a d'autres

Quant à l'analyse elle me sert juste à avoir la liste des fichiers/rubriques sous les yeux (pour le F11, le drag & drop etc ...) mais je pourrais m'en passer

[Arnaud B.]

Bonjour
Dans la pratique j'ai un script par version du logiciel (ex : maj_1005A.sql pour la version 1005A d'une appli)

Merci, très intéressant.

Et pour générer ce script, une méthode particulière ? Ou entièrement à la mimine ?

Cdlt, Arnaud.

[Bowen]

Il doit être possible de lire cette analyse, et de s'en servir pour la convertir en script SQL (cf. HOuvreAnalyse, HListeFichier, HListeRubrique, HListeLiaison, ..Type, etc...).
Ça serait le plus pratique je pense.
Et ça a l'avantage de continuer à coder avec les auto-complétions sur les noms de fichiers / rubriques.

Reste seulement à prendre le temps de faire ce modifieur SQL.
Si quelqu'un fait le script, je suis preneur !

[Arnaud B.]

Il doit être possible de lire cette analyse, et de s'en servir pour la convertir en script SQL (cf. HOuvreAnalyse, HListeFichier, HListeRubrique, HListeLiaison, ..Type, etc...).
Ça serait le plus pratique je pense.
Et ça a l'avantage de continuer à coder avec les auto-complétions sur les noms de fichiers / rubriques.

Reste seulement à prendre le temps de faire ce modifieur SQL.
Si quelqu'un fait le script, je suis preneur !

On peut générer le script CREATE dans Windev (Editeur d'analyses -> Menu Structure des fichiers -> Générer le script SQL

Mais effectivement impossible de générer un script de mise à jour d'après les modifications effectuées dans l'analyse.

En fait on est en train de parler d'un WDModif pour des bases tierces. J'avoue que je suis surpris que ça n'existe pas...

Cdlt, Arnaud.

[vmolines]

L'analyse peut être lue et des scripts générés en effet. Le problème étant que l'analyse ne permet pas de représenter des fonctionnalités de base des SGBDR, notamment :

- clé primaire : il n'y a pas de clé primaire dans les tables. A ne pas confondre avec un index unique qui n'a rien à voir. (Plaquette HFSQL, page 5 est indiqué qu'HyperFileSQL gère les clés primaires )
- clé étrangère composée : il n'est pas possible d'avoir une contrainte clé étrangère qui porte sur deux colonnes

J'ai travaillé sur des projets qui s'appuyaient malheureusement sur l'analyse et été amené à faire du code de génération de scripts pour plusieurs SGBDR à partir de cette dernière. Mais rien côté script différentiel.

[vmolines]

On peut générer le script CREATE dans Windev (Editeur d'analyses -> Menu Structure des fichiers -> Générer le script SQL

Mais effectivement impossible de générer un script de mise à jour d'après les modifications effectuées dans l'analyse.

En fait on est en train de parler d'un WDModif pour des bases tierces. J'avoue que je suis surpris que ça n'existe pas...

Cdlt, Arnaud.

La fonctionnalité de génération de scripts est buggée. Il est notamment impossible de générer le script d'une table qui contient des types numériques exacts. Le script ressort alors vide pour cette table. Bug enregistré en 15 depuis un moment mais non corrigé.

Ca existe mais pas chez PCSoft, Sybase Power AMC permet notamment de tenir un modèle de données indépendamment d'un SGBDR et de générer des scripts différentiels entre deux version d'un modèle.

De ce côté là, PCSoft fait les choses à moitié et, en tant que développeur, il faut être lucide et ne pas croire au discours commercial mirobolant. Vous pouvez lire ce sujet pour vous convaincre des méfaits de l'accès aux données par Windev.

[Arnaud B.]

Il doit être possible de lire cette analyse, et de s'en servir pour la convertir en script SQL (cf. HOuvreAnalyse, HListeFichier, HListeRubrique, HListeLiaison, ..Type, etc...).
Ça serait le plus pratique je pense.
Et ça a l'avantage de continuer à coder avec les auto-complétions sur les noms de fichiers / rubriques.

Reste seulement à prendre le temps de faire ce modifieur SQL.
Si quelqu'un fait le script, je suis preneur !

Bon ben je crois que je vais devoir à un moment donné développer un générateur de script différentiel, car je ne me vois pas rester avec une base HF à terme s'il n'y a pas de corrections des pbs actuels, et je ne me vois pas non plus écrire à chaque fois tous les ALTER TABLE à la main...

Si quelqu'un a des bouts de codes libres de droits sur le sujet, et qu'il est prêt à les partager, je suis preneur... et je partagerai en retour.

Cdlt, Arnaud.

[Arnaud B.]

La fonctionnalité de génération de scripts est buggée. Il est notamment impossible de générer le script d'une table qui contient des types numériques exacts. Le script ressort alors vide pour cette table. Bug enregistré en 15 depuis un moment mais non corrigé.

Ca existe mais pas chez PCSoft, Sybase Power AMC permet notamment de tenir un modèle de données indépendamment d'un SGBDR et de générer des scripts différentiels entre deux version d'un modèle.

De ce côté là, PCSoft fait les choses à moitié et, en tant que développeur, il faut être lucide et ne pas croire au discours commercial mirobolant. Vous pouvez lire ce sujet pour vous convaincre des méfaits de l'accès aux données par Windev.

Merci, topic très intéressant...
J'étais sceptique sur le discours de l'éditeur... mais là je viens de prendre un coup de massue derrière la tête...

J'ai la même grande interrogation que toi : qu'est ce qui est passé par la tête des développeurs qui ont développé le moteur HF ? A croire qu'ils n'ont pas testé leur moteur.

Cdlt, Arnaud