Discussion :

[vmolines]

En gros ça marche mais ça ne doit pas être comparé à de véritables SGBDR et c'est là où l'éditeur se moque du monde avec son discours. Microsoft n'a jamais comparé access à SQL Server...

Les développeurs ont fait ce qu'on leur a dit de faire dans les temps impartis et les compétences à disposition. C'est dur de sortir une version par an avec 600 nouveautés et corriger les anomalies des versions précédentes. Je vous laisse constater quels choix ont été faits.

[Bowen]

Tout n'est pas à jeter non plus, l'essentiel est de connaitre les limitations.
Le coté pratique, par exemple, c'est la mise à jour automatique des données.
Le moteur HF en lui-même est buggé, c'est sûr, mais il existe presque toujours un moyen de contourner ces limitations.
Le plus dur étant de repérer les bugs...
(dernier en date : un SUM qui renvoie plusieurs lignes, si on a un WHERE un peu complexe)
Avis aux modérateurs : que pensez-vous de faire un topic épinglé unique, résumant les bugs connus, et éventuellement leurs solutions ?

[vmolines]

Contourner les bugs ou les limitations c'est ce que je passe mon temps à faire quand je dois travailler sur des projets où la consigne est analyse + ordres H.

• Ne pas modéliser comme la base doit être modélisée pour être "Windev compatible"
• Programmer les parcours avec des ordres HLit conduit à des performances innacceptables si on est pas en monotable.
• Utiliser les requêtes Windev ne permet pas d'attaquer tous les SGBDR malgré l'utilisation d'ordres donnés compatibles dans l'aide : COALESCE + fonction d'agrégat sous oracle = plantage
• Utiliser les requêtes Windev conduit à des requêtes non optimisées sur la base de données : un paramètre de type date dans un where est passé sous forme de chaine et comparé à une colonne date transformée en chaine => aucune utilisation des indexes
• Le fait de contourner induit soit une perte de performance (en traitant côté code), soit une non utilisation de la fonctionnalité (utilisation du SQL pur spécifique à chaque base)

Chaque projet où l'intention était de rester dans les clous de Windev pour l'accès aux données a présenté les mêmes problèmes avec les mêmes (non) solutions :

• Mixité des méthodes d'accès aux données au sein du projet : requêtes windev, parcours HLit, requêtes sans correction, ...
• Acceptation en l'état de performances catastrophiques en faisant comme si tout était normal et fait dans les règles de l'art

Après chacun son niveau d'exigence, mais me concernant ce sont des choses inacceptables si on connait un minimum les SGBDR. La vérité c'est que beaucoup de développeurs Windev se servent d'une base de données comme d'un fichier texte et ne sont pas plus ennuyés que ça

[Arnaud B.]

Mixité des méthodes d'accès aux données au sein du projet : requêtes windev, parcours HLit, requêtes sans correction, ...

Globalement d'accord...

Mais la mixité en tant que telle ne me parait pas être un problème si elle n’entraîne pas une baisse des performances.

Par exemple, utiliser des ordres HLitRecherchePremier() de manière ponctuelle ne me parait pas être nécessairement à bannir.

D'autre part, en tant que développeur, le gain de performances est à mettre en regard du temps de développement : si je dois passer beaucoup de temps à synchroniser une base tierce pour gagner un peu en performances, cela peut se discuter.

Dans cette optique, je suis prêt à accepter un certain nombre de bugs ou de limitations, dans une certaine mesure, si la recherche de contournements de ces bugs n'est pas trop pénalisante.

Cdlt, Arnaud.

[vmolines]

C'est l'éternel argument qui dit que faire du full SQL est plus long qu'utiliser l'accès aux données Windev pour privilégier celui ci. Et ça, même si je ne peux vous le prouver, je le conteste totalement mon expérience à l'appui.