[WD8][HLitRecherchePremier]

sebNews a exprimé avec précision :

Bonjour,
la fonction HLitRecherchePremier est elle optimisée
pour la recherche d'UN enregistrement sur Clé Unique
par rapport à HlitRecherche ?

Comment comprenez vous dans l'aide :
Positionne sur le premier enregistrement du fichier dont la valeur d'une
rubrique spécifique est supérieure ou égale à une valeur recherchée.

C'est le " supérieur ou éqale " qui m'intrigue

Je veux rechercher un client et le bloquer en écriture :
HlitRecherchePremier(client,code_cli,"C24",hBlocageEcriture)
ou bien ?
HlitRecherche(client,code_cli,"C24",hBlocageEcriture)


Sébastien

Par défaut Hlitrecherche est en valeur générique. L'autre est par
valeur identique.

A+

--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net

sebNews wrote:

Bonjour, la fonction HLitRecherchePremier est elle optimisée pour la
recherche d'UN enregistrement sur Clé Unique par rapport à
HlitRecherche ?

Comment comprenez vous dans l'aide : Positionne sur le premier
enregistrement du fichier dont la valeur d'une rubrique spécifique
est supérieure ou égale à une valeur recherchée.

C'est le " supérieur ou éqale " qui m'intrigue

Je veux rechercher un client et le bloquer en écriture :
HlitRecherchePremier(client,code_cli,"C24",hBlocageEcriture) ou bien
? HlitRecherche(client,code_cli,"C24",hBlocageEcriture)


Sébastien

Dans le cas de l'exemple, je ne vois pas vraiment de différence
lorsqu'on utilise les deux commandes. Je pense ils ont l'intention
d'arrêter HLitRecherche un jour. La recherche générique se fait aussi
par un paramètre de HLitRecherchePremier.

Je suis tout é fait d'accord de trouver intriguant "supérieur ou égale",
je ne l'ai vu encore nulle part ailleurs. Il y a pas mal de cas de
figures et selon des tests faits il y a quelque temps,
HLitRecherchePremier ne se comporte pas toujours comme décrit dans
l'aide (autre possibilité: l'info dans l'aide est fausse).

Il n'y a aucun problème avec le code ci-dessus, autre que le curseur va
se déplacer lorsque on ne l'attends pas. Une consultation de
l'aide en ligne donne, entre autre :

Quote+++
Exemples de recherches effectuées sur le fichier CLIENT trié par nom :

Dupuis

1
Faux
Faux
Dupuis n'existe pas. Positionnement sur la première valeur supérieure
(Durand).
La fin du fichier n'a pas encore été atteinte.

Dupon
HGénérique
8
Vrai
Faux
Dupon n'existe pas mais la recherche est générique et il existe un
Dupond (entre autres).
La fin du fichier n'a pas encore été atteinte.

Dupon

L'enregistrement n'a pas été trouvé (pas de déplacement)
Faux
Faux
Dupon n'existe pas.
La fin du fichier n'a pas encore été atteinte.

Unquote+++

A mon avis, il n'y a aucune raison que le curseur se déplace dans le cas
de Dupuis: la valeur n'existe simplement pas alors que tout à coup le
curseur se retrouve sur l'enregistrement avec une valeur supérieure à
Dupuis est illogique et gênant. C'est acceptable pour une fonction
générique, mais c'est justement HLitRecherche (générique) qu'ils
voulaient remplacer, n'est ce pas?

Mais le curseur peut se déplacer aussi dans le cas de Dupon,
toujours un comportement d'une recherche générique. Il semble que la
seule différence entre une recherche à l'identique et générique est la
valeur renvoyé HTrouve, mais pas le positionnement du curseur.

En fin de compte, je ne fais aucune confiance au placement du curseur.
J'utilise souvent une copie du fichier pour les recherches
(HAlias/HchangeNom) et de toute façon je teste la clé avant chaque
opération, même si théoriquement le curseur n'aurait pas dû changer.

Il est évident qu'ils ne peuvent plus corriger ces lacunes, car trop de
code fonctionne maintenant sur cette base.

Salutations
mat


p.s. voici un échange de correspondance avec le ST à ce sujet. On était
en 7.5 (205g) et on commençait à perdre un peu la patience...
Dans un bel exemple de perception sélective, PC Soft insistaient que le
problème de chercher "4" et se positionner sur "40238" correspond à la
l'exemple "Dupuis" de l'aide en ligne, tandis que c'est évidemment
l'exemple "Dupon" (à l'identique). PC soft aurait raison si "4"
n'existait nulle part et que Windev se positionne sur la première
valeure supérieure à "4". Mais le "4" existe dans "40238", comme "Dupon"
existe dans "Dupond". Alors selon l'aide, le curseur ne devrait pas
bouger, mais il bouge... En conséquence du problème decrit, j'ai aussi
remplacé HSauveposition / HRetourPosition par une nouvelle lecture de la
clé d'origine par HLitRecherchePremier.

Message envoyé au ST le 27/7/2003:
-----------------------------------
Dysfonctionnement de HLitRecherchePremier et HRetourPosition

Détail de la demande :
On utilise HSauvePosition (=1, le premier enregistrement), suivi par
HLitRecherchePremier qui ne trouve pas sa valeur de recherche (4). Le
curseur se déplace sur le premier enregistrement commençant avec la même
valeur (40238), même si l'aide dit ""L'enregistrement n'a pas été trouvé
(pas de déplacement)"". Ensuite, HRetourPosition ne retourne pas au
début du fichier !!!!!!!!

Protocole de reproduction :
nPos=HSauvePosition(:cMasterTable,:cMasterIDFld) // ( = 1 )
SI HLitRecherchePremier(:cMasterTable,:cRecNameFld,vName) ALORS //
(valeur recherché = 4, mais se positionne sur ID 40238 ???)
vID = {:cMasterTable + "." + :cMasterIDFld,indRubrique}
vRes=True
SINON
vResúlse // (exécute correctement cette ligne)
FIN
HRetourPosition(nPos) // ( ne s'exécute pas. ID reste sur 40248 enregistrement n° 2266)
******************************************************

La réponse du ST du 31/7/2003:
-------------------------------
Nous sommes surpris par votre description et l'information est inexacte
"L'enregistrement n'a pas été trouvé (pas de
déplacement)". Pouvez-vous nous préciser l'entrée de l'aide qui vous a
permis d'obtenir cette information ? Nous la
ferons corriger.

Le fonctionnement est le suivant (valable quelque soit la version de
WINDEV) : en cas de recherche, si la valeur
n'est pas trouvé on est positionné dans le fichier sur le premier
enregistrement supérieur. Dans l'aide de
HLitRecherchePremier, on peut lire dans le tableau récapitulatif :
"Dupuis n'existe pas. Positionnement sur la
première valeur supérieure (Durand)."

Veuillez nous excuser pour l'erreur de documentation qui vous a gêne
dans la mise au point de votre traitement.
*******************************************************

Ma réponse du 1/8/2003:
------------------------
L'information se trouve dans l'aide de la commande même, voir le
fichier gif en annexe.
Ce que vous expliquez serait le résultat d'une lecture générique et
correspond avec celle de HLitRecherche. Ce comportement est clairement
FAUX pour une recherche à l'identique. Y-a-t-il un autre langage de
programmation dans lequel un curseur dans un fichier se déplace quand
une recherche n'aboutit pas? C'est totalement illogique et les
langages que je connais ne le font pas.

Dans l'aide, soit l'exemple pour "Dupuis" ou celui pour "Dupon" (sans
options) est faux. Pour moi, c'est le premier.

En outre ceci explique peut-être pourquoi HRetourPosition ne
fonctionne pas après HLitRecherchePremier. Windev pense que la
position n'a pas changé. De toute façon, le curseur reste sur
l'enregistrement (faux) et ne retourne pas sur celui sauvé par
HSauvePosition. C'est tellement grave que je ne peux presque pas
croire que c'est vrai !

Ca fait un moment que n'ai plus testé les parties du programme qui
utilisent ces commandes ensembles, mais c'est claire que le jour où
nous l'avions testé, il n'y avait pas ce problème. Nous ne trouvons
nullement amusant ces changements continuels de comportement.
Avez-vous une idée ce que ça veut dire quand on a une application en
clientèle et on fait juste un petit changement, recompile et toute
l'application risque avoir des nouveaux problèmes auparavant inconnus?
Je crains que vous ne vous rendez pas compte...
****************************************************

La réponse du ST du 6/8/2003:
------------------------------
Nous avons bien pris note de vos remarques. Notre précédente réponse
reste cependant valable.

> Je suis tout é fait d'accord de trouver intriguant "supérieur ou égale",
je ne l'ai vu encore nulle part ailleurs. Il y a pas mal de cas de
figures et selon des tests faits il y a quelque temps,
HLitRecherchePremier ne se comporte pas toujours comme décrit dans
l'aide (autre possibilité: l'info dans l'aide est fausse).

Comme quoi la prudence est de mise.
J'ai pris l'habitude de valider toute nouvelle fonction
du WLanguage que j'utilise.
Mais dans ce cas c'est la simple lecture de l'aide sur la fonction
qui me déroute.

Sébastien