En WD8 quand on fait une recherche sur une clef texte
HLitRecherchePremier(Fichier,MaClef,"MaRecherche")
Si la taille de MaRecherche est plus grande que la taille de la clef,
cela devrait retourner syst=E9matiquement Faux (ce qui n'est pas la cas
actuellement) - sans m=EAme v=E9rifier quoi que ce soit d'autre.
J'aimerais savoir si ce probl=E8me est r=E9gl=E9 avec WD10.
En WD8 quand on fait une recherche sur une clef texte HLitRecherchePremier(Fichier,MaClef,"MaRecherche")
Si la taille de MaRecherche est plus grande que la taille de la clef, cela devrait retourner systématiquement Faux (ce qui n'est pas la cas actuellement) - sans même vérifier quoi que ce soit d'autre.
J'aimerais savoir si ce problème est réglé avec WD10.
********************** sValrech est une chaîne bRes est un booléen c est un entier POUR c=1 A 3 SELON c CAS 1 : sValrech = "toto" CAS 2 : sValrech = "t" CAS 3 : sValrech = "totolasmoulette" FIN bRes = HLitRecherchePremier(PERSONNE,NOM, sValrech) Trace("bRes="+bRes + " h.trouve="+ H.trouve + " h.endehors=" + H.endehors) FIN **********************
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Après mure réflexion, Réal Phil a écrit :
Bonjour,
En WD8 quand on fait une recherche sur une clef texte
HLitRecherchePremier(Fichier,MaClef,"MaRecherche")
Si la taille de MaRecherche est plus grande que la taille de la clef,
cela devrait retourner systématiquement Faux (ce qui n'est pas la cas
actuellement) - sans même vérifier quoi que ce soit d'autre.
J'aimerais savoir si ce problème est réglé avec WD10.
**********************
sValrech est une chaîne
bRes est un booléen
c est un entier
POUR c=1 A 3
SELON c
CAS 1 : sValrech = "toto"
CAS 2 : sValrech = "t"
CAS 3 : sValrech = "totolasmoulette"
FIN
bRes = HLitRecherchePremier(PERSONNE,NOM, sValrech)
Trace("bRes="+bRes + " h.trouve="+ H.trouve + " h.endehors=" +
H.endehors)
FIN
**********************
En WD8 quand on fait une recherche sur une clef texte HLitRecherchePremier(Fichier,MaClef,"MaRecherche")
Si la taille de MaRecherche est plus grande que la taille de la clef, cela devrait retourner systématiquement Faux (ce qui n'est pas la cas actuellement) - sans même vérifier quoi que ce soit d'autre.
J'aimerais savoir si ce problème est réglé avec WD10.
********************** sValrech est une chaîne bRes est un booléen c est un entier POUR c=1 A 3 SELON c CAS 1 : sValrech = "toto" CAS 2 : sValrech = "t" CAS 3 : sValrech = "totolasmoulette" FIN bRes = HLitRecherchePremier(PERSONNE,NOM, sValrech) Trace("bRes="+bRes + " h.trouve="+ H.trouve + " h.endehors=" + H.endehors) FIN **********************
En tout cas, le problème n'existe pas en WD7.5... Fichier 10 enregistrements, clé texte doublon NOM. 1 enregistrement contient "toto".
Précision, la clé est sur 10 caractères, fichiers HF mode 7.
Tes fichiers ont-ils été migrés à partir d'une 5.5 ?
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Réal Phil
Bonjour Romain,
...et merci pour cette réponse très appréciée... et qui m'a fait réaliser que je n'avais pas été assez précis dans ma question. En effet les tests que tu montre me donnent les mêmes résultats avec la version 8.
Maintenant, essai l'exemple qui suit;
// Fichier CLT.FIC avec 5 000 enregistrements (pas important) // Rubrique CLT.Code avec clef unique de 7 caractères de large // Un seul enregistrement contient CLT.Code="W10677W" // Paramètres de l'index Sensible à tout (Avancé) // CAS 3 : sValrech = "W10677WWWWW" provient d'un champ de saisie de 20 caractères qui ne peut etre reduit
sValrech est une chaîne bRes est un booléen c est un entier POUR c=1 A 3 SELON c CAS 1 : sValrech = "W10677W" CAS 2 : sValrech = "W10677" CAS 3 : sValrech = "W10677WWWWW" // dépasse la taille de la rubrique FIN bRes = HLitRecherchePremier(CLT, CODE, sValrech) Trace("bRes="+bRes + " h.trouve="+ H.trouve + " h.endehors=" + H.endehors + " "+sValrech) FIN
Donne comme résultat; bRes=1 h.trouve=1 h.endehors=0 W10677W bRes=0 h.trouve=0 h.endehors=0 W10677 bRes=1 h.trouve=1 h.endehors=0 W10677WWWWW
ET WD8 DIT QU'IL A TROUVÉ W10677WWWWW !! Ce qui ne devrait pas se produire. C'est pourquoi je dis que dès que la taille de la variable recherchée dépasse la taille de la rubrique clef WD devrait retourner Faux tout de suite sans même vérifier quoi que soit d'autre.
bRes=HLitRecherche(Clt,Code,sValrech,hIdentique) // même résultat.
Quels sont les résultats de ce nouveau test avec ta version ?
Quelqu'un peut aussi tester avec la version 10 ?
Bonjour Romain,
...et merci pour cette réponse très appréciée... et qui m'a fait
réaliser que je n'avais pas été assez précis dans ma question.
En effet les tests que tu montre me donnent les mêmes résultats avec
la version 8.
Maintenant, essai l'exemple qui suit;
// Fichier CLT.FIC avec 5 000 enregistrements (pas important)
// Rubrique CLT.Code avec clef unique de 7 caractères de large
// Un seul enregistrement contient CLT.Code="W10677W"
// Paramètres de l'index Sensible à tout (Avancé)
// CAS 3 : sValrech = "W10677WWWWW" provient d'un champ de saisie de 20
caractères qui ne peut etre reduit
sValrech est une chaîne
bRes est un booléen
c est un entier
POUR c=1 A 3
SELON c
CAS 1 : sValrech = "W10677W"
CAS 2 : sValrech = "W10677"
CAS 3 : sValrech = "W10677WWWWW" // dépasse la taille de la rubrique
FIN
bRes = HLitRecherchePremier(CLT, CODE, sValrech)
Trace("bRes="+bRes + " h.trouve="+ H.trouve + " h.endehors=" +
H.endehors + " "+sValrech)
FIN
Donne comme résultat;
bRes=1 h.trouve=1 h.endehors=0 W10677W
bRes=0 h.trouve=0 h.endehors=0 W10677
bRes=1 h.trouve=1 h.endehors=0 W10677WWWWW
ET WD8 DIT QU'IL A TROUVÉ W10677WWWWW !!
Ce qui ne devrait pas se produire. C'est pourquoi je dis que dès que
la taille de la variable recherchée dépasse la taille de la rubrique
clef WD devrait retourner Faux tout de suite sans même vérifier quoi
que soit d'autre.
bRes=HLitRecherche(Clt,Code,sValrech,hIdentique) // même résultat.
Quels sont les résultats de ce nouveau test avec ta version ?
...et merci pour cette réponse très appréciée... et qui m'a fait réaliser que je n'avais pas été assez précis dans ma question. En effet les tests que tu montre me donnent les mêmes résultats avec la version 8.
Maintenant, essai l'exemple qui suit;
// Fichier CLT.FIC avec 5 000 enregistrements (pas important) // Rubrique CLT.Code avec clef unique de 7 caractères de large // Un seul enregistrement contient CLT.Code="W10677W" // Paramètres de l'index Sensible à tout (Avancé) // CAS 3 : sValrech = "W10677WWWWW" provient d'un champ de saisie de 20 caractères qui ne peut etre reduit
sValrech est une chaîne bRes est un booléen c est un entier POUR c=1 A 3 SELON c CAS 1 : sValrech = "W10677W" CAS 2 : sValrech = "W10677" CAS 3 : sValrech = "W10677WWWWW" // dépasse la taille de la rubrique FIN bRes = HLitRecherchePremier(CLT, CODE, sValrech) Trace("bRes="+bRes + " h.trouve="+ H.trouve + " h.endehors=" + H.endehors + " "+sValrech) FIN
Donne comme résultat; bRes=1 h.trouve=1 h.endehors=0 W10677W bRes=0 h.trouve=0 h.endehors=0 W10677 bRes=1 h.trouve=1 h.endehors=0 W10677WWWWW
ET WD8 DIT QU'IL A TROUVÉ W10677WWWWW !! Ce qui ne devrait pas se produire. C'est pourquoi je dis que dès que la taille de la variable recherchée dépasse la taille de la rubrique clef WD devrait retourner Faux tout de suite sans même vérifier quoi que soit d'autre.
bRes=HLitRecherche(Clt,Code,sValrech,hIdentique) // même résultat.
Quels sont les résultats de ce nouveau test avec ta version ?
Quelqu'un peut aussi tester avec la version 10 ?
Romain PETIT
Réal Phil a émis l'idée suivante :
Quels sont les résultats de ce nouveau test avec ta version ?
La seule modif est l'unicité de la clé -> j'ai essayé, pas de problème j'ai le même résultat que précédemment...
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Réal Phil a émis l'idée suivante :
Quels sont les résultats de ce nouveau test avec ta version ?
La seule modif est l'unicité de la clé -> j'ai essayé, pas de problème
j'ai le même résultat que précédemment...
--
Romain PETIT
http://cerbermail.com/?O16kfXOFcq
(cliquez sur le lien ci-dessus pour me contacter en privé)
Quels sont les résultats de ce nouveau test avec ta version ?
La seule modif est l'unicité de la clé -> j'ai essayé, pas de problème j'ai le même résultat que précédemment...
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Réal Phil
>La seule modif est l'unicité de la clé -> j'ai essayé, pas de problème j'ai le même résultat que précédemment...
Pour simuler la même situation - comme la rubrique chez vous a 10 caractères de large - il faudrait écrire dans la rubrique (au lieu de toto) quelque chose comme toto123456 puis ensuite chercher toto123456789
>La seule modif est l'unicité de la clé -> j'ai essayé,
pas de problème j'ai le même résultat que précédemment...
Pour simuler la même situation - comme la rubrique chez vous a 10
caractères de large - il faudrait écrire dans la rubrique (au lieu de
toto) quelque chose comme toto123456 puis ensuite chercher toto123456789
>La seule modif est l'unicité de la clé -> j'ai essayé, pas de problème j'ai le même résultat que précédemment...
Pour simuler la même situation - comme la rubrique chez vous a 10 caractères de large - il faudrait écrire dans la rubrique (au lieu de toto) quelque chose comme toto123456 puis ensuite chercher toto123456789
Romain PETIT
Il se trouve que Réal Phil a formulé :
La seule modif est l'unicité de la clé -> j'ai essayé, pas de problème j'ai le même résultat que précédemment...
Pour simuler la même situation - comme la rubrique chez vous a 10 caractères de large - il faudrait écrire dans la rubrique (au lieu de toto) quelque chose comme toto123456 puis ensuite chercher toto123456789
Ah Ok, compris. Effectivement, même comportement en WD7.5...
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Il se trouve que Réal Phil a formulé :
La seule modif est l'unicité de la clé -> j'ai essayé,
pas de problème j'ai le même résultat que précédemment...
Pour simuler la même situation - comme la rubrique chez vous a 10
caractères de large - il faudrait écrire dans la rubrique (au lieu de
toto) quelque chose comme toto123456 puis ensuite chercher toto123456789
Ah Ok, compris.
Effectivement, même comportement en WD7.5...
--
Romain PETIT
http://cerbermail.com/?O16kfXOFcq
(cliquez sur le lien ci-dessus pour me contacter en privé)
La seule modif est l'unicité de la clé -> j'ai essayé, pas de problème j'ai le même résultat que précédemment...
Pour simuler la même situation - comme la rubrique chez vous a 10 caractères de large - il faudrait écrire dans la rubrique (au lieu de toto) quelque chose comme toto123456 puis ensuite chercher toto123456789
Ah Ok, compris. Effectivement, même comportement en WD7.5...
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Réal Phil
C'est bien ce que je pensais.
Quand on est conscient du bug on peut éviter assez facilement - quoique parfois c'est pas évident - et même très facile à oublier.
J'espère qu'un utilisateur de version 10 fera le test aussi. Je suis bien curieux de connaitre le résultat.
C'est bien ce que je pensais.
Quand on est conscient du bug on peut éviter assez facilement -
quoique parfois c'est pas évident - et même très facile à oublier.
J'espère qu'un utilisateur de version 10 fera le test aussi.
Je suis bien curieux de connaitre le résultat.
Quand on est conscient du bug on peut éviter assez facilement - quoique parfois c'est pas évident - et même très facile à oublier.
J'espère qu'un utilisateur de version 10 fera le test aussi. Je suis bien curieux de connaitre le résultat.
Pascal F
Réal Phil a présenté l'énoncé suivant :
C'est bien ce que je pensais.
Quand on est conscient du bug on peut éviter assez facilement - quoique parfois c'est pas évident - et même très facile à oublier.
J'espère qu'un utilisateur de version 10 fera le test aussi. Je suis bien curieux de connaitre le résultat.
Même comportant en WD 10 40k, par contre dans l'aide il est indiqué: Pour effectuer une recherche à l'identique, il faut que la taille de l'argument de recherche soit exactement égale à la taille de la clé.
-- Pascal
Ne garder que le prénom pour me joindre
Réal Phil a présenté l'énoncé suivant :
C'est bien ce que je pensais.
Quand on est conscient du bug on peut éviter assez facilement -
quoique parfois c'est pas évident - et même très facile à oublier.
J'espère qu'un utilisateur de version 10 fera le test aussi.
Je suis bien curieux de connaitre le résultat.
Même comportant en WD 10 40k, par contre dans l'aide il est indiqué:
Pour effectuer une recherche à l'identique, il faut que la taille de l'argument de recherche soit exactement égale à la taille de
la clé.
--
Pascal
N0.pascal.SPAM@efpe.biz
Ne garder que le prénom pour me joindre
Quand on est conscient du bug on peut éviter assez facilement - quoique parfois c'est pas évident - et même très facile à oublier.
J'espère qu'un utilisateur de version 10 fera le test aussi. Je suis bien curieux de connaitre le résultat.
Même comportant en WD 10 40k, par contre dans l'aide il est indiqué: Pour effectuer une recherche à l'identique, il faut que la taille de l'argument de recherche soit exactement égale à la taille de la clé.
-- Pascal
Ne garder que le prénom pour me joindre
Réal Phil
Merci Pascal,
L'aide indique que pour effectuer une recherche à l'identique, il faut que la taille de l'argument de recherche soit exactement égale à la taille de la clé.
Ouais, pas fort comme Aide de la part de PCS. Pourtant quand on cherche avec une variable plus petite, et bien Windev dit qu'il ne la trouve pas tout simplement - et c'est ce qu'on espère recevoir comme réponse.
Le comportement devrait être le même avec une variable de recherche plus longue que la clef.
Il me semble que cela ne se peut pas que PCS laisse passer un illogisme pareil. Je vais les recontacter avec plus de détails.
Merci à tous pour les tests.
Merci Pascal,
L'aide indique que pour effectuer une recherche
à l'identique, il faut que la taille de l'argument
de recherche soit exactement égale à la taille
de la clé.
Ouais, pas fort comme Aide de la part de PCS. Pourtant quand on cherche
avec une variable plus petite, et bien Windev dit qu'il ne la trouve
pas tout simplement - et c'est ce qu'on espère recevoir comme
réponse.
Le comportement devrait être le même avec une variable de recherche
plus longue que la clef.
Il me semble que cela ne se peut pas que PCS laisse passer un illogisme
pareil.
Je vais les recontacter avec plus de détails.
L'aide indique que pour effectuer une recherche à l'identique, il faut que la taille de l'argument de recherche soit exactement égale à la taille de la clé.
Ouais, pas fort comme Aide de la part de PCS. Pourtant quand on cherche avec une variable plus petite, et bien Windev dit qu'il ne la trouve pas tout simplement - et c'est ce qu'on espère recevoir comme réponse.
Le comportement devrait être le même avec une variable de recherche plus longue que la clef.
Il me semble que cela ne se peut pas que PCS laisse passer un illogisme pareil. Je vais les recontacter avec plus de détails.
Merci à tous pour les tests.
Pascal F
Réal Phil a utilisé son clavier pour écrire :
Merci Pascal,
L'aide indique que pour effectuer une recherche à l'identique, il faut que la taille de l'argument de recherche soit exactement égale à la taille de la clé.
Ouais, pas fort comme Aide de la part de PCS. Pourtant quand on cherche avec une variable plus petite, et bien Windev dit qu'il ne la trouve pas tout simplement - et c'est ce qu'on espère recevoir comme réponse.
Le comportement devrait être le même avec une variable de recherche plus longue que la clef.
Il me semble que cela ne se peut pas que PCS laisse passer un illogisme pareil. Je vais les recontacter avec plus de détails.
Merci à tous pour les tests.
d'autant qu'en WD 5.5 une erreure était générée dans un tel cas. Issu de l'aide 5.5: Si la taille de la valeur de recherche est de taille supérieure à la taille de la clé, l'erreur 11 sera retournée.
-- Pascal
Ne garder que le prénom pour me joindre
Réal Phil a utilisé son clavier pour écrire :
Merci Pascal,
L'aide indique que pour effectuer une recherche
à l'identique, il faut que la taille de l'argument
de recherche soit exactement égale à la taille
de la clé.
Ouais, pas fort comme Aide de la part de PCS. Pourtant quand on cherche
avec une variable plus petite, et bien Windev dit qu'il ne la trouve
pas tout simplement - et c'est ce qu'on espère recevoir comme
réponse.
Le comportement devrait être le même avec une variable de recherche
plus longue que la clef.
Il me semble que cela ne se peut pas que PCS laisse passer un illogisme
pareil.
Je vais les recontacter avec plus de détails.
Merci à tous pour les tests.
d'autant qu'en WD 5.5 une erreure était générée dans un tel cas. Issu de l'aide 5.5:
Si la taille de la valeur de recherche est de taille supérieure à la taille de la clé, l'erreur 11 sera retournée.
--
Pascal
N0.pascal.SPAM@efpe.biz
Ne garder que le prénom pour me joindre
L'aide indique que pour effectuer une recherche à l'identique, il faut que la taille de l'argument de recherche soit exactement égale à la taille de la clé.
Ouais, pas fort comme Aide de la part de PCS. Pourtant quand on cherche avec une variable plus petite, et bien Windev dit qu'il ne la trouve pas tout simplement - et c'est ce qu'on espère recevoir comme réponse.
Le comportement devrait être le même avec une variable de recherche plus longue que la clef.
Il me semble que cela ne se peut pas que PCS laisse passer un illogisme pareil. Je vais les recontacter avec plus de détails.
Merci à tous pour les tests.
d'autant qu'en WD 5.5 une erreure était générée dans un tel cas. Issu de l'aide 5.5: Si la taille de la valeur de recherche est de taille supérieure à la taille de la clé, l'erreur 11 sera retournée.
