SaisieCode="ABCDEFGHIJK" // champ de saisie texte de 20 car. max.
HLitRecherchePremier(Client,IDClient,SaisieCode) // IDClient = rubrique
texte de 7 car.
// SaisieCode ne peut être réduit à moins de caracteres
Si un des enregistrements contient IDClient= "ABCDEFG", HTrouve() est
toujours à Vrai.
HLitRecherchePremier() fait une recherche à l'identique... alors HTrouve()
ne devrait-il pas toujours donner Faux systématiquement quand le contenu de
la recherche dépasse la largeur de la clef ?
HLitRecherche(Client,IDClient,SaisieCode,hIdentique) donne le même résultat.
Je comprend bien que WD compare sa clef avec le début du texte saisie et
trouve Vrai mais puisque qu'on fait une recherche à l'identique ne
devrait-il pas comparer la totalité de la chaîne recherchée avec la clef et
retourner Faux ? (comme le fait Foxpro)
Je peux contourner assez facilement mais quelqu'un a une explication à ce
comportement que je trouve illogique ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
mat
Real Phil wrote:
Bonjour,
SaisieCode="ABCDEFGHIJK" // champ de saisie texte de 20 car. max. HLitRecherchePremier(Client,IDClient,SaisieCode) // IDClient = rubrique texte de 7 car.
// SaisieCode ne peut être réduit à moins de caracteres
Si un des enregistrements contient IDClient= "ABCDEFG", HTrouve() est toujours à Vrai.
HLitRecherchePremier() fait une recherche à l'identique... alors HTrouve() ne devrait-il pas toujours donner Faux systématiquement quand le contenu de la recherche dépasse la largeur de la clef ?
HLitRecherche(Client,IDClient,SaisieCode,hIdentique) donne le même résultat.
Je comprend bien que WD compare sa clef avec le début du texte saisie et trouve Vrai mais puisque qu'on fait une recherche à l'identique ne devrait-il pas comparer la totalité de la chaîne recherchée avec la clef et retourner Faux ? (comme le fait Foxpro)
Je peux contourner assez facilement mais quelqu'un a une explication à ce comportement que je trouve illogique ?
Réal Phil
Salut Réal,
d'accord, j'ai fait la même observation en juillet 2003. MAIS, qu'est-ce qu'on fait avec le code qui s'est adapté à ce comportement faux? Donc, on ne fait rien... enfin, PCS n'ont trouvé rien de faux avec la fonction et que le comportement correspond avec l'aide. Par conséquent, je fais des vérifications/hLitRecherche... avant chaque opération fichier, même si théoriquement le curseur n'a pas bougé.
MESSAGE AU ST LE 27/7/2003 ========================= ... 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)
Real Phil wrote:
Bonjour,
SaisieCode="ABCDEFGHIJK" // champ de saisie texte de 20 car. max.
HLitRecherchePremier(Client,IDClient,SaisieCode) // IDClient = rubrique
texte de 7 car.
// SaisieCode ne peut être réduit à moins de caracteres
Si un des enregistrements contient IDClient= "ABCDEFG", HTrouve() est
toujours à Vrai.
HLitRecherchePremier() fait une recherche à l'identique... alors HTrouve()
ne devrait-il pas toujours donner Faux systématiquement quand le contenu de
la recherche dépasse la largeur de la clef ?
HLitRecherche(Client,IDClient,SaisieCode,hIdentique) donne le même résultat.
Je comprend bien que WD compare sa clef avec le début du texte saisie et
trouve Vrai mais puisque qu'on fait une recherche à l'identique ne
devrait-il pas comparer la totalité de la chaîne recherchée avec la clef et
retourner Faux ? (comme le fait Foxpro)
Je peux contourner assez facilement mais quelqu'un a une explication à ce
comportement que je trouve illogique ?
Réal Phil
Salut Réal,
d'accord, j'ai fait la même observation en juillet 2003. MAIS, qu'est-ce
qu'on fait avec le code qui s'est adapté à ce comportement faux? Donc,
on ne fait rien... enfin, PCS n'ont trouvé rien de faux avec la fonction
et que le comportement correspond avec l'aide. Par conséquent, je fais
des vérifications/hLitRecherche... avant chaque opération fichier, même
si théoriquement le curseur n'a pas bougé.
MESSAGE AU ST LE 27/7/2003
========================= ...
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)
SaisieCode="ABCDEFGHIJK" // champ de saisie texte de 20 car. max. HLitRecherchePremier(Client,IDClient,SaisieCode) // IDClient = rubrique texte de 7 car.
// SaisieCode ne peut être réduit à moins de caracteres
Si un des enregistrements contient IDClient= "ABCDEFG", HTrouve() est toujours à Vrai.
HLitRecherchePremier() fait une recherche à l'identique... alors HTrouve() ne devrait-il pas toujours donner Faux systématiquement quand le contenu de la recherche dépasse la largeur de la clef ?
HLitRecherche(Client,IDClient,SaisieCode,hIdentique) donne le même résultat.
Je comprend bien que WD compare sa clef avec le début du texte saisie et trouve Vrai mais puisque qu'on fait une recherche à l'identique ne devrait-il pas comparer la totalité de la chaîne recherchée avec la clef et retourner Faux ? (comme le fait Foxpro)
Je peux contourner assez facilement mais quelqu'un a une explication à ce comportement que je trouve illogique ?
Réal Phil
Salut Réal,
d'accord, j'ai fait la même observation en juillet 2003. MAIS, qu'est-ce qu'on fait avec le code qui s'est adapté à ce comportement faux? Donc, on ne fait rien... enfin, PCS n'ont trouvé rien de faux avec la fonction et que le comportement correspond avec l'aide. Par conséquent, je fais des vérifications/hLitRecherche... avant chaque opération fichier, même si théoriquement le curseur n'a pas bougé.
MESSAGE AU ST LE 27/7/2003 ========================= ... 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)
Real Phil
> > Bonjour, > > SaisieCode="ABCDEFGHIJK" // champ de saisie texte de 20 car. max. > HLitRecherchePremier(Client,IDClient,SaisieCode) // IDClient = rubrique > texte de 7 car. > > // SaisieCode ne peut être réduit à moins de caracteres > > Si un des enregistrements contient IDClient= "ABCDEFG", HTrouve() est > toujours à Vrai. > > HLitRecherchePremier() fait une recherche à l'identique... alors
HTrouve()
> ne devrait-il pas toujours donner Faux systématiquement quand le contenu
de
> la recherche dépasse la largeur de la clef ? > > HLitRecherche(Client,IDClient,SaisieCode,hIdentique) donne le même
résultat.
> > Je comprend bien que WD compare sa clef avec le début du texte saisie et > trouve Vrai mais puisque qu'on fait une recherche à l'identique ne > devrait-il pas comparer la totalité de la chaîne recherchée avec la clef
et
> retourner Faux ? (comme le fait Foxpro) > > Je peux contourner assez facilement mais quelqu'un a une explication à
ce
> comportement que je trouve illogique ? > > Réal Phil
Salut Réal,
d'accord, j'ai fait la même observation en juillet 2003. MAIS, qu'est-ce qu'on fait avec le code qui s'est adapté à ce comportement faux? Donc, on ne fait rien... enfin, PCS n'ont trouvé rien de faux avec la fonction et que le comportement correspond avec l'aide. Par conséquent, je fais des vérifications/hLitRecherche... avant chaque opération fichier, même si théoriquement le curseur n'a pas bougé.
MESSAGE AU ST LE 27/7/2003 ========================= > ... 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)
==================================================== Et bien, c'est pas avec ces fonctions qu'on va développer 10 fois plus vite. N'est-ce pas?
Quoique quand on le sait, on s'en méfie et on valide systématiquement. Mais tout de même, je vais contacter PCS à ce sujet et en profiter pour leur soumettre une bonne douzaine de suggestions que j'ai en note depuis un certain temps.
Best regards,
Réal
> > Bonjour,
>
> SaisieCode="ABCDEFGHIJK" // champ de saisie texte de 20 car. max.
> HLitRecherchePremier(Client,IDClient,SaisieCode) // IDClient = rubrique
> texte de 7 car.
>
> // SaisieCode ne peut être réduit à moins de caracteres
>
> Si un des enregistrements contient IDClient= "ABCDEFG", HTrouve() est
> toujours à Vrai.
>
> HLitRecherchePremier() fait une recherche à l'identique... alors
HTrouve()
> ne devrait-il pas toujours donner Faux systématiquement quand le contenu
de
> la recherche dépasse la largeur de la clef ?
>
> HLitRecherche(Client,IDClient,SaisieCode,hIdentique) donne le même
résultat.
>
> Je comprend bien que WD compare sa clef avec le début du texte saisie et
> trouve Vrai mais puisque qu'on fait une recherche à l'identique ne
> devrait-il pas comparer la totalité de la chaîne recherchée avec la clef
et
> retourner Faux ? (comme le fait Foxpro)
>
> Je peux contourner assez facilement mais quelqu'un a une explication à
ce
> comportement que je trouve illogique ?
>
> Réal Phil
Salut Réal,
d'accord, j'ai fait la même observation en juillet 2003. MAIS, qu'est-ce
qu'on fait avec le code qui s'est adapté à ce comportement faux? Donc,
on ne fait rien... enfin, PCS n'ont trouvé rien de faux avec la fonction
et que le comportement correspond avec l'aide. Par conséquent, je fais
des vérifications/hLitRecherche... avant chaque opération fichier, même
si théoriquement le curseur n'a pas bougé.
MESSAGE AU ST LE 27/7/2003
========================= > ...
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)
====================================================
Et bien, c'est pas avec ces fonctions qu'on va développer 10 fois plus vite.
N'est-ce pas?
Quoique quand on le sait, on s'en méfie et on valide systématiquement.
Mais tout de même, je vais contacter PCS à ce sujet et en profiter pour leur
soumettre une bonne douzaine de suggestions que j'ai en note depuis un
certain temps.
> > Bonjour, > > SaisieCode="ABCDEFGHIJK" // champ de saisie texte de 20 car. max. > HLitRecherchePremier(Client,IDClient,SaisieCode) // IDClient = rubrique > texte de 7 car. > > // SaisieCode ne peut être réduit à moins de caracteres > > Si un des enregistrements contient IDClient= "ABCDEFG", HTrouve() est > toujours à Vrai. > > HLitRecherchePremier() fait une recherche à l'identique... alors
HTrouve()
> ne devrait-il pas toujours donner Faux systématiquement quand le contenu
de
> la recherche dépasse la largeur de la clef ? > > HLitRecherche(Client,IDClient,SaisieCode,hIdentique) donne le même
résultat.
> > Je comprend bien que WD compare sa clef avec le début du texte saisie et > trouve Vrai mais puisque qu'on fait une recherche à l'identique ne > devrait-il pas comparer la totalité de la chaîne recherchée avec la clef
et
> retourner Faux ? (comme le fait Foxpro) > > Je peux contourner assez facilement mais quelqu'un a une explication à
ce
> comportement que je trouve illogique ? > > Réal Phil
Salut Réal,
d'accord, j'ai fait la même observation en juillet 2003. MAIS, qu'est-ce qu'on fait avec le code qui s'est adapté à ce comportement faux? Donc, on ne fait rien... enfin, PCS n'ont trouvé rien de faux avec la fonction et que le comportement correspond avec l'aide. Par conséquent, je fais des vérifications/hLitRecherche... avant chaque opération fichier, même si théoriquement le curseur n'a pas bougé.
MESSAGE AU ST LE 27/7/2003 ========================= > ... 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)
==================================================== Et bien, c'est pas avec ces fonctions qu'on va développer 10 fois plus vite. N'est-ce pas?
Quoique quand on le sait, on s'en méfie et on valide systématiquement. Mais tout de même, je vais contacter PCS à ce sujet et en profiter pour leur soumettre une bonne douzaine de suggestions que j'ai en note depuis un certain temps.
