OVH Cloud OVH Cloud

RECHERCHEV #N/A

8 réponses
Avatar
Ingrid
J'ai créé une table nommée "REGIONS" et comportant 3 colonnes :
A B C
Région Département Code POSTAL

pour récupérer le nom de la région dans une autre feuille j'ai rentré la
formule :
=SI(ESTVIDE(I3);"";RECHERCHEV(I3;REGIONS;1;FAUX))
quand la cellule I3 est vide ça marche il ne m'affiche rien ; en revanche
quand elle comporte une valeur le résultat est #N/A.
s'AGIT-IL D4UN PROBLeME DE FORMAT ,
merci de votre aide

8 réponses

Avatar
anomymousA
bonjour,

es-tu sure que ta cellule I3 contient une valeur qui existe dans colonne 1
de ta plage de noms REGIONS ?
Par ailleurs, je te rappelle que recherchev fonctionne en comparant la
valuer de ce qu'il y a dans 1 cellule avce un tabealu matriciel en
considérant que le colonne de référence ( donc les élements qui seront
comparés avec ta cellule) est forcément la colonne la plus à gauche.
Enfin, les références de format (au sens texte ou numérique. le reste des
formats importe peu) , c'est vrai , doivent être similaires. Attention au
fait que des valeurs qui semblent numériques ne sont pas forcément si
numériques que ça. Cet inconénient apparait souvent lorsqu'on extrait des
données depuis des fichiers d'autres applications et qu'on veut les utiliser
sous Excel.

Bonne chance.

A+


J'ai créé une table nommée "REGIONS" et comportant 3 colonnes :
A B C
Région Département Code POSTAL

pour récupérer le nom de la région dans une autre feuille j'ai rentré la
formule :
=SI(ESTVIDE(I3);"";RECHERCHEV(I3;REGIONS;1;FAUX))
quand la cellule I3 est vide ça marche il ne m'affiche rien ; en revanche
quand elle comporte une valeur le résultat est #N/A.
s'AGIT-IL D4UN PROBLeME DE FORMAT ,
merci de votre aide



Avatar
AV
Salut,

Enfin, les références de format (au sens texte ou numérique. le reste des
formats importe peu) , c'est vrai , doivent être similaires.


Bien que anti-RechercheTruc de façon obstiné et depuis des lustres, je n'arrive
pas à "le" prendre en défaut (à mon grand regret ;-))
Pas de différence de comportement avec l'EQUIV
Si tu as un exemple...

AV

Avatar
Daniel.M
Bonjour Alain,

Bien que anti-RechercheTruc de façon obstiné et depuis des lustres, je
n'arrive

pas à "le" prendre en défaut (à mon grand regret ;-))
Pas de différence de comportement avec l'EQUIV
Si tu as un exemple...


Le dernier argument de RECHERCHEV() est un booléen.
Lorsque son évaluation donne 0 (ou FAUX), il fait une recherche exacte.
Lorsque son évaluation <>0 (ou VRAI), il fait une recherche dichotomique en
considérant un plage triée ascendante.

Le dernier argument de EQUIV() est un nombre
S'il est 0, il fait une recherche exacte
S'il est positif, il fait une recherche dichotomique en considérant une plage
triée ascendante.
S'il est négatifs, il fait une recherche dichotomique en considérant une plage
triée descendante.

Il y a donc un peu plus de possibilité avec EQUIV(). Avec un dernier argument
négatif, on obtient des résultats différents.

Malgré cette légère possibilité additionnelle, la principale raison d'utiliser
INDEX(EQUIV()) au lieu de RECHERCHEV() a plutôt directement rapport avec l'idée
qu'avec INDEX(EQUIV()), on associe explicitement dans sa formule notre
structuration des données, au lieu de fournir un nombre de colonnes de décalage.
Ce nombre pourrait être éventuellement mis-à-mal pour le déplacement d'une
colonne dans ses données.

AMA, il faut privilégier la stabilité des résultats (des formules) et se
prémunir contre des formules qui, comme RECHERCHEV(), soudainement se mettent à
fournir d'autres résultats simplement parce qu'on ajoute/détruit/déplace des
colonnes (sans changer les données dépendantes).

Salutations,

Daniel M. (secrétaire à l'éradication de l'ambiguité, SPA)

Avatar
AV
Bigre de bigre... il en avait gros sur la patate ! ;-))
Ha dichotomie quand tu nous tiens....! ;-)
Je crois que tu as mal compris le sens de ma question :
Il ne s'agit pas du tout de chercher des raisons d'utiliser Equiv au lieu de
RechercheTruc
Ca il y a "berlurette" que je le clame en ce lieu ...
Ma question s'adressait à AnonymusA qui signalait un cas de figure (mélange de
données "apparemment numériques" (format texte et num mélangés))dans lequel
RechercheTruc se plantait
C'est cette chose que je n'arrive pas à reproduire et j'ai même précisé "à mon
grand regret"
Le dit-regret étant celui de ne pouvoir garnir mon argumentaire
anti-Recherche-Truc

Pffff...
quand je pense qu'à la lecture de ton texte (remarquable) qu'un passant pourrait
croire, un seul instant, que je suis un utilisateur/défenseur de RechercheTruc,
ça me "bouleversifie" complètement !
;-)
AV
Avatar
anonymousA
Belle démonstation et complète ce qui ne gate rien.
je suis plutot un inconditionnel de recherchev (je pense que vous avez
pu le remarquer) mais seulement quand on en connait les pièges notamment
le booleen de determination exacte, ce qui veut dire que je ne la
conseille pas à tout le monde..
J'aime bien equiv aussi mais je le reserve à des determinations de N° de
ligne ou de colonne , c'est selon , et encore il ne faut pas se gourer
de paramètres. J'ai eu ainsi la désagréable surprise de recevoir l'autre
jour un fichier de ma boite à destination de tous les départements de
France où le confctionneur du fichier s'était lamentablement planté sur
le parmamètre d'EQUIV ce qui du coup rendait fausses toutes ses formules
qui l'utilisaient.

A+

Bonjour Alain,


Bien que anti-RechercheTruc de façon obstiné et depuis des lustres, je


n'arrive

pas à "le" prendre en défaut (à mon grand regret ;-))
Pas de différence de comportement avec l'EQUIV
Si tu as un exemple...



Le dernier argument de RECHERCHEV() est un booléen.
Lorsque son évaluation donne 0 (ou FAUX), il fait une recherche exacte.
Lorsque son évaluation <>0 (ou VRAI), il fait une recherche dichotomique en
considérant un plage triée ascendante.

Le dernier argument de EQUIV() est un nombre
S'il est 0, il fait une recherche exacte
S'il est positif, il fait une recherche dichotomique en considérant une plage
triée ascendante.
S'il est négatifs, il fait une recherche dichotomique en considérant une plage
triée descendante.

Il y a donc un peu plus de possibilité avec EQUIV(). Avec un dernier argument
négatif, on obtient des résultats différents.

Malgré cette légère possibilité additionnelle, la principale raison d'utiliser
INDEX(EQUIV()) au lieu de RECHERCHEV() a plutôt directement rapport avec l'idée
qu'avec INDEX(EQUIV()), on associe explicitement dans sa formule notre
structuration des données, au lieu de fournir un nombre de colonnes de décalage.
Ce nombre pourrait être éventuellement mis-à-mal pour le déplacement d'une
colonne dans ses données.

AMA, il faut privilégier la stabilité des résultats (des formules) et se
prémunir contre des formules qui, comme RECHERCHEV(), soudainement se mettent à
fournir d'autres résultats simplement parce qu'on ajoute/détruit/déplace des
colonnes (sans changer les données dépendantes).

Salutations,

Daniel M. (secrétaire à l'éradication de l'ambiguité, SPA)






Avatar
anonymousA
bonjour AV,

Je maintiens qu'il m'est arrivé de ne pas pouvoir faire une recherchev
correcte parceque j'étais d'abord contraint de faire un cnum sur des
données soit de recherche soit de la matrice elle-même. M'en souviens
plus trop bien.Peut-être des blancs dans les données , va savoir que du
coup cnum éliminait. Il me semble que c'était à l'extraction de fichiers
au format .SYLK.
Je ne penses pas que ce soit lié au mode de recherche des données.
Simplement je voulais indiquer à notre aimable demandeuse quelles
étainet les pistes possibles de recherhce pour la déplanter.

A+

Bigre de bigre... il en avait gros sur la patate ! ;-))
Ha dichotomie quand tu nous tiens....! ;-)
Je crois que tu as mal compris le sens de ma question :
Il ne s'agit pas du tout de chercher des raisons d'utiliser Equiv au lieu de
RechercheTruc
Ca il y a "berlurette" que je le clame en ce lieu ...
Ma question s'adressait à AnonymusA qui signalait un cas de figure (mélange de
données "apparemment numériques" (format texte et num mélangés))dans lequel
RechercheTruc se plantait
C'est cette chose que je n'arrive pas à reproduire et j'ai même précisé "à mon
grand regret"
Le dit-regret étant celui de ne pouvoir garnir mon argumentaire
anti-Recherche-Truc

Pffff...
quand je pense qu'à la lecture de ton texte (remarquable) qu'un passant pourrait
croire, un seul instant, que je suis un utilisateur/défenseur de RechercheTruc,
ça me "bouleversifie" complètement !
;-)
AV




Avatar
AV
M'en souviens plus trop bien.


Quel dommage ! ;-)

AV

Avatar
Daniel.M
Bigre de bigre... il en avait gros sur la patate ! ;-))


:-))) Mais pas vraiment.

Je voulais faire ressortir la différence de comportement en fonction des valeurs
des derniers arguments aux fonctions RECHERCHEV et EQUIV. C'est une subtilité
intéressante.

Je crois que tu as mal compris le sens de ma question :
Il ne s'agit pas du tout de chercher des raisons d'utiliser Equiv au lieu de
RechercheTruc
...
Ma question s'adressait à AnonymusA qui signalait un cas de figure (mélange de
données "apparemment numériques" (format texte et num mélangés))dans lequel
RechercheTruc se plantait
C'est cette chose que je n'arrive pas à reproduire et j'ai même précisé "à mon
grand regret"


Ah Ok. J'avais pas vu ... et donc mal compris ta question.
Par ma faute, tu auras été mal compris une fois de plus. :-)
Bon, ça restera pour le schmibick!

quand je pense qu'à la lecture de ton texte (remarquable) qu'un passant
pourrait

croire, un seul instant, que je suis un utilisateur/défenseur de
RechercheTruc,

ça me "bouleversifie" complètement !


Je suis bien au courant de ton opinion là-dessus. Du reste, ta réponse vient de
rassurer ledit passant. ;-)

Salutations,

Daniel M.