Je commence à admettre que l'utilisation de la base de données de WinDev n'est pas le meilleur choix, surtout que la version 10 du kit ne fournit pas de solutions aux problèmes SQL existant.
D'abord je n'ai pas réussi a introduire une sous requête dans la clause Select d'une requête du genre

SELECT IdNom, (Select Nom from Utilisateur where Profil.IdNom=Utilisateur.IdNom) From Profil

Cette requête n'est qu'à titre indicatif, inutile de me proposer de solutions, j'ai pu me débrouiller autrement (j'ai changé de SGBD, incroyable qu'Access puisse traiter cette requête alors qu'Hyper File qui est orienté développement WinDev ne reconnaisse pas cette requête)

Un autre type de requête comporte des erreur dès qu'on commence à la taper, il s'agit de cumul de jointure:

Select code, désignation, CoûtTotal, CoûtFixe from Produit inner join (Vente inner join production on ...) on ...

Dans cet exemple dès qu'on essaie de cumuler deux jointure le mot vente se voit attribuer une sous-ligne et un message d'erreur indique ne pas connaitre l'instruction "Vente".

PCSoft doit prendre en considération ces problèmes parce qu'il n'est pas acceptable qu'un kit de développement aussi puissant et complet soit doté d'un SGBD aussi faible.

Bonjour,

Non pour prendre la défense du SGBD, mais il faut dire que "rome ne s'est pas fait en un jour". Le moteur SQL de WD n'existe pas depuis très longtemps 2001, donc il subsiste des cas non traités (n'hésitez pas à leur remonter l'information ->> Requête au ST). Par contre vous n'êtes pas obligé d'utiliser les requêtes SQL, les ordres du W-Langage fonctionnent parfaitement bien, hlitrecherche, hlitsuivant, etc ...

Bon dév.,

Totof

QUand SQL ne donne pas satisfaction, il y a la série des ordres h*, une vraie mine...
Il ne faut pas essayer de refaire simplement en Windev ce qu'on ferait avec d'autres lnagages
Pour exploiter au mieux Windev, il faut en comprendre 'un peu' sa philosophie... Et à mon avis les ordres h* sont actuellement incontournables

Bonjour Danger.

Je vous invite, comme il vous a été signalé, de soumettre vos demandes d'améliorations directement à l'éditeur. En effet, nous ne sommes en position de le faire pour vous.

Ensuite, le SQL sur HyperFile est effectivement réscent et souffre donc de manques qui peuvent vous sembler insupportables. Toujours est-il que les choses évoluent et que parfois elle ne sont pas si simples.
Je fais trop peu de SQL pour être affirmatif. Mettre une requete dans une autre est permis semble-t il mais dans condition de sélection et non encore dans le résultat :


Il est effectivement possible que votre besoin ne passe encore, je n'ai pas vérifié. Cela ne justifie pas pour autant que les améliorations abouties dans la 10 attendent que ce point non bloquant soit réglé pour permettre la sortie.

Bonjour,

C'est souvent l'erreur que je rencontre.

On change de produit mais on veut garder ses habitudes de développement.
NON, quand on change d'outil il faut aussi adopter la philosophie de l'éditeur, même si celui ci n'a pas fait les choix que l'on aurait préféré.

Le Sql n'est pas le plus optimisé pour l'utilisation des bases HF mais cela facilite quand même grandement les choses dans certains cas.
Les Ordres H* sont beaucoup plus optimisés et dans certain cas les vues souvent ignorées peuvent même surprendre dans leurs rapidités d'exécution, encore une fois lorsqu'elles sont utilisées à bonne escient

Access à certes de grandes qualités au niveau du sql mais beaucoup moins au niveau des acces concurentiels de la charge et de l'occupation réseau.

Pour résumer il faut savoir s'adapter aux outils que l'on utilisent

Tout à fait DrCharly93 :)
Les fonctions H* marchent parfaitement bien et sont souvent très agréables :)
Néanmoins je dois dire dans quelques cas assez précis un p'tit coup de reuqête SQL "sauve" d'un code parfois assez long ;)

bonjour,

tout depend

j'ai eu un jour un programme a faire avec une possibilite pour l'utilisateur de pouvoir faire ses affichage. j'entend par la a lui de pouvoir choisir les données qu'il veut voir les filtre etc ...

et la pour programmer ca en ordre H... c'est pratiquement impossible car il faudrait connaitre a l'avance ce que veut l'utilisateur. le plus simple et de construire une requete avec les champs desirer, et faire les liaisons en focntion des cle. ce qui est beaucoup plus simple en SQL que de faire des boucle de lecture

donc suivant certain cas il est peut etre important de pouvoir faire du SQL.

ensuite si le client choisi une autre base que HF la il vaut mieux travailler en requete qu'en ordre H car sinon c'est la cata un SGBDR n'apprecie pas trop les lecture successive, mais aime plutot travailler en global, pour avoir la somme des facture en HF on lit chaque facture et on a le resultat, en SQL on demande directment la somme et on la lit. de ce cote il y a pour le client 1 seule lecture (le resultat).

donc les ordres H.. sont incontournables, si on programme pour HF uniquement. si votre client vous demande de changer de base , on peut egalement avoir les ordre H... mais les performance ne seront pas la