Bonjour,

Le Sql en WinDev n'est pas vraiment optimisé (Pour Hyper File) peut être parce qu'il est trop jeune et surement pas si facile à intégrer au moteur Hyper File, et ce justement sur les tris et encore plus sur les tris multiples

Donc dans certains cas, afin d'optimiser au mieux les traitements, il est nécessaire de trouver une parade au SQL, quoi que les deux méthodes conjointes pourraient peut être une bonne alternative.

Les vues sont bien plus optimisées sur Hyper File et étaient déjà utilisées en WinDev 5.x pour les accès distants.(Bien que cela soit gourmand en ressources syteme)

Bonjour tout le monde,

Apres quelques jours d'absence voila ou j'en suis :

J'ai abandonné l'idée d'utiliser SQL pour trier mes fichiers...

J'ai récup un algorithme de tri (Le Tri Rapide) qui me procure une bonne rapidité d'éxécution et que je peux surement améliorer (55 secondes pour 44000 lignes et 12 champs).

En SQL j'obtenais un temps de 51 secondes.

Maintenant que ma procédure de tri est au point je cherche a l'ameliorer.

Voila ce que je pensais faire :

Je découpe mon fichier suivant les Zones et j'obtiens 9 fichiers que je tri séparément avec des threads et je les fusionne qd ils sont tous triés.

Pensez vous que j'obtiendrais un gain de performances ???

Merci

S'ils sont trié uniquement dans chaques parties, il est possible que les plus petis enreg d'un groupe soit tout de même plus grands que les plus petis d'un autre...

Thread ou pas thread, tu n'as qu'un proc...

Ne peut tu par réduire le tris avec uniquement l'ID de l'enreg et les valeurs de tris?
Suite à cela, tu n'as qu'a recherche l'enregistrement correspondant.
Le temps est répartis sur les demandes d'enreg et non à l'initialisation.

Citation :

Je suis d'accord avec toi mais les threads s'éxécute indépendemment les uns des autres cependant comme tu dis je n'ai qu'un proc...

Mais je pense qu'en découpant le fichier en plusieurs en regroupant les zones entre elles, cela me permet un (excuse si ce n'est pas francais) pré-tri qui permettra d'optimiser le tri final.

Qu'en penses tu???

Je ne pense pas que tu va aller plus vite.

Ici, quand on a des problèmes de rapidité génants, on passe en Access.

En Access dis-tu????



J'ai laissé tombé Access car j'avais des problemes de fiabilité avec le moteur de base de données de "Crosoft" (Microsoft Jet SP8)

Mes requetes de création de table avec tri ne me donnait aléatoirement pas le même résultat (encore un bug dont je n'ai trouvé aucune info sur le net)

Ex :


TableOrig : (details sur les enregistrements)
06000 Commune
08000 Commune
14000 Commune
14000 Commune
22000 Commune
24000 Commune

voila le résultat attendu :
14000
14000
22000
24000
06000
08000

et le résultat retourné par le moteur Microsoft Jet (ceci ce produit aléatoirement) :

22000
14000
14000
24000
06000
08000

Comme tu peux le constater le 22000 est passé devant les 14000 (ceux sont des Codes Postaux)

Si je rééxécute la requete je peux tomber sur le bon résultat ou bien pas et je n'en ai jamais trouvé la cause

Le seul moyen que j'avais trouvé c'etait d'exporter directement le résultat de la requete et ne pas créer la table triée qui pouvait etre fausse par moment

Donc j'ai laissé tomber Access pour Windev mais je ne savais pas qu'il etait limité au niveau SQL

Bonjour,

Afin d'optimiser au mieux votre parcours, créer directement dans l'editeur d'analyse une clé composée adéquate qui correspondes au résultat attendu, ainsi aucune requête ni aucun tri ne sera nécessaire , un simple parcours et c'est tout.