Discussion :

[no_me_entero]

Bonsoir.

J'ai un fichier facture, avec un clé composé IdClient+DateFacture
Je souhaite connaitre la dernière date de facture d'un client.

Code :

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

1
2
3
 
HLitRechercheDernier( Factures, idClientDateFacture , [Client.IdClient, 99991231 ] )
HLitPrécédent( Factures, idClientDateFacture )

Cela ne marche pas!

[frenchsting]

Je mettrais plutôt :

Code :

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

HLitDernier( Factures, idClientDateFacture )

[Hemgé]

Bonjour,

HLitDernier ne permet pas de préciser la valeur de la clé et entraînerait donc un parcours non optimisé du fichier avec la nécessité de tester la valeur de l'Id pour chaque enregistrement.
Il faut effectivement utiliser HLitRechercheDernier, comme proposé par no_me_entero.
D'après le contexte de la question, cette clé composée est a priori organisée de manière ascendante.

Quant à la clé composée, la liste de valeurs est la méthode préconisée.

Comme la date de facture est inconnue, je crois qu'il ne faut pas la mentionner et utiliser une liste (càd avec les crochets, comme proposé), mais réduite à la seule valeur de l'Id et sans "," (qui provoquerait une erreur ou une alerte de l'éditeur de code).
Windev va traiter cette liste incomplète comme une valeur (l'Id) et une valeur vide ou nulle.
Comme je n'utilise pas les clés composées de WD (je préfère générer mes propres clés sous forme de chaînes de caractères), je n'ai pas d'expérience spécifique, mais c'est comme cela que WD se comporte d'habitude avec les listes entre [ ].

Soit :

Code :

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

1
2
HLitRechercheDernier( Factures, idClientDateFacture , [Client.IdClient] )
HLitPrécédent( Factures, idClientDateFacture )

[no_me_entero]

Bonjour.

En fait

Code :

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

HLitRechercheDernier( Factures, idClientDateFacture , [Client.IdClient, 99991231 ] )

fonctionne tout seul!
C'est troublant car Htrouve = Faux, et HEnDehors = Faux

Parcontre controler HEnDehors n'est pas suffisant car sil nexiste pas d'enregistrement pour un IdClient, il retourne un facture d'sun client suivant, avec HEnDehors = Faux!
Donc oblige a vérifier Client.IdClient = Facture.IdClient

Tout cela en fait est pour plalier la lenteur de HFSQL sous Linux, face à MySQL sur le même serveur

Code :

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

1
2
3
4
5
HFiltre( Facture, idClientDateFacture , hValMin, hValMax, ...
	"IdClient=" + Client.IdClient+"")
 
	// Parcours des enregistrements filtrés
	HLitDernier( Facture, idClientDateFacture )

Ce traitement est 5 fois plus lent avec HFSQL, donc je cherche un solution pour améliorer.

HLitRechercheDernier, n'améliore pas la vitesse, elle chute avec les 2 bases.
Donc je dois continuer à chercher.

Merci

[Hemgé]

Parcontre controler HEnDehors n'est pas suffisant car sil nexiste pas d'enregistrement pour un IdClient, il retourne un facture d'sun client suivant, avec HEnDehors = Faux!
Donc oblige a vérifier Client.IdClient = Facture.IdClient

De mémoire, il est mentionné quelque part dans la documentation que ce n'est pas parce que l'enregistrement demandé n'a pas été trouvé que HF n'a pas lu quelque chose.
Il est au minimum resté sur l'enregistrement précédant l'opération qui a échoué. De là aussi l'intérêt de faire un HRAZ(Factures) avant toute lecture.

Attention également au fait que le premier contrôle c'est HTrouve : Vrai ou Faux, les autres contrôles (HEnDehors, HErreurBloquage) ne servant qu'à affiner le diagnostic si HTrouve = Faux.
Mais, si on ramène "quelque chose" accompagné d'un HTrouve = Faux, ce quelque chose n'est pas l'information cherchée, "point à la ligne".
Et quelle que soit la Facture trouvée, elle ne concerne pas le client ciblé.


En terme de vitesse, je ne connais pas la différence des mécanisme mis en jeu, mais je commencerais par remplacer les HFiltre par des query. (C'est même recommandé par la doc ...)
Et dans ces query, je ne rapatrierais que le nombre minimum de colonnes pour faire un éventuel test, quitte à refaire une lecture complète de la ligne de table à modifier.
Si vous travaillez avec des query, vous pouvez aussi vous limiter à un update limité aux colonnes cibles.
Tout cela concourt à améliorer vos accès.

[frenchsting]

Désolé pour la réponse en dehors de la plaque, mais je vais essayer de me rattraper en donnant quelques idées.

Au moins, il y aura la possibilité de faire des tests de rapidité.

Par une requête ? Le premier résultat de cette requête est la dernière date de facture :

Code :

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

SQL SELECT ... ORDER BY DateFacture DESC

Par une vue ? C'est la même chose que la requête SQL, c'est juste pour savoir si cette méthode est plus rapide.

[serendib]

Allez, je te met +1, tu t'es bien rattrapé.
Les vues, je suis adepte depuis WD5.5, c'est tout de même très pratique.

[frenchsting]

Merci pour le +1.

Je suis adepte également, mais il faut que le contexte s'y prête (clés + volumétrie fichier/performances machine). Une vue, c'est une requête SQL "déguisée" (cf discussion avec michel.souris sur ce sujet). Je pratique depuis longtemps également.

[Ben13d10]

Bonsoir.

J'ai un fichier facture, avec un clé composé IdClient+DateFacture
Je souhaite connaitre la dernière date de facture d'un client.

Code :

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

1
2
3
 
HLitRechercheDernier( Factures, idClientDateFacture , [Client.IdClient, 99991231 ] )
HLitPrécédent( Factures, idClientDateFacture )

Cela ne marche pas!

Bonjour,
afin de faire une recherche à l'aide d'une clef composée, tu as la fonction "hconstruitvalcle".

Ensuite tu peux lancer ta recherche à l'aide du résultat de cette fonction

Bon dev