Discussion :

[Le Sage]

Bonjour.

J'ai construit un formulaire permettant d'alimenter une liste de critères de catégorisation automatique de mes dépenses.

Imaginons l'import d'un relevé bancaire :

Libelle	Montant	Categorie
PRELEVEMENT DE Orange SA .... facture: XXX9323A9	50
ACHAT CB L ORANGER	40
ACHAT CB ORANGE SA	30

On voit bien qu'il est impossible de baser la discrimination du libellé sur une égalité (le numéro de facture Orange change à chaque mouvement, il peut y avoir des prélèvements et des achats, ...)
Je passe donc par une table de correspondance et un LIKE :

Critere	Categorie
Orange	Internet
Oranger	Resto

Categorie est donc déterminé sur la base de [Libelle] LIKE "*" & [Critere] & "*"

Ca fonctionne très bien... Si ce n'est que, dans la table comme dans le formulaire, l'espace final dans le critère " Orange " est automatiquement supprimé, que la saisie soit faite dans la table ou dans le formulaire !ez
En d'autres termes, Access m'impose une correction de type TrimR() à la saisie !

Le problème ?
Ben avec le critère " Orange" (sans espace final) :

"PRELEVEMENT DE Orange SA .... facture: XXX9323A9" LIKE "*" & " Orange" & "*" = VRAI (Correct)
"ACHAT CB L ORANGER" LIKE "*" & " Orange" & "*" = VRAI (Incorrect)
"ACHAT CB ORANGE SA" LIKE "*" & " Orange" & "*" = VRAI (Correct)

Alors qu'avec le critère " Orange " (avec espace final) :

"PRELEVEMENT DE Orange SA .... facture: XXX9323A9" LIKE "*" & " Orange " & "*" = VRAI (Correct)
"ACHAT CB L ORANGER" LIKE "*" & " Orange " & "*" = FAUX (Correct)
"ACHAT CB ORANGE SA" LIKE "*" & " Orange " & "*" = VRAI (Correct)

J'ai eu beau chercher dans tous les sens, je ne trouve ni pourquoi, ni comment faire cesser cette aberration !

Merci d'avance pour votre aide.

[tee_grandbois]

bonjour,

J'ai eu beau chercher dans tous les sens, je ne trouve ni pourquoi, ni comment faire cesser cette aberration !

ce n'est pas un aberration, c'est le choix de Microsoft: la mémorisation d'un espace en fin de texte dans Windows n'est pas possible, c'est "trimé" systématiquement, donc à moins de tomber sur une astuce trouvée au fin fond du web, tu ne pourras donc pas contourner ce que t'impose le système.

[Le Sage]

Merci pour ta réponse.

Ceci étant, je maintiens : c'est une aberration que de l'imposer. Une option activée par défaut, je veux bien, mais l'imposer pose par exemple le problème que je viens d'évoquer, qui lui, me semble-t-il, n'est ni si bizarre ni si rare que ça.

Au cas où ça intéresserait quelqu'un, et puisque Microsoft a décidé de nous obliger à bricoler au lieu de bosser selon nos besoins, le contournement (et non la solution, puisqu'il n'y en a pas) que j'ai utilisé est de mettre un caractère improbable à la place de l'espace final et de le remplacer lors de la construction du critère en VBA (en l'occurrence le caractère "¤")

Encore merci.

[tee_grandbois]

Ceci étant, je maintiens : c'est une aberration que de l'imposer.

comme ça l'est d'imposer de la publicité (un peu) partout où on ne souhaite pas l'avoir ou la voir... mais chacun son point de vue sur ses propres aberrations.

Mais je reviens sur ce que j'ai dit: c'est possible de garder l'espace de fin à condition de passer par un type de champ à caractère: fixe le type CHAR qui n'est pas accessible via l'interface de création de table mais uniquement en SQL

tu peux exécuter cette requête après création de la table:

Code SQL :

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

alter table ta_table alter column tonchamp char(30);

j'ai aussi modifié la propriété "Compression Unicode" en la mettant à Non car cela n'a pas fonctionné du premier coup ou alors j'ai merdouillé quelque part.
Inconvénient: ton champ aura une longueur de 30 caractères (ou plus ou moins selon ton choix) pour chaque enregistrement créé: par exemple, (len(tonchamp) renverra toujours 30 quelque soit le nombre de caractères saisis.

On ne voit strictement rien à l'écran du formulaire, donc il faut être attentif au moment de la saisie mais cela fonctionne.

[loufab]

Bonjour,

Il faut peut-être abandonner le Like au profit du Regex qui est plus performant.
Le /b permet d'utiliser le concept de Mot. Où Orange et Oranger ne seront jamais la même chose.

ACE n'intègre pas le Regex à la différence d'autres moteurs SGBD. Il faut donc passer par une biblio comme VBS Scripting.

Cordialement,

[marot_r]

Bonjour, le point de loufab me paraît correct.
C'est le fonctionnement de habituel de like qui n'est pas capable de distinguer "Orange" de "Oranger" vu que quand on met "Orange*" on dit de prendre tous les textes qui commencent par Orange donc on ramasse aussi "Oranger" et "Orange " et n'importe quoi d'autre comme "Orangeade".

Si tu ne veux pas aller avec un RegEx, (qui est selon moi assez imbuvable :-) ) tu pourrais découper tes textes en mot avec Split, et associer ces mots à l'enregistrement concerné puis faire une recherche sur cela.
Ça te donne un truc du genre.

tblDonnees
ClefDonnees
Texte

tblMotDonnees
ClefMotDonnees
ClefDonnees
MotDansTexte

ou

tblDonnees
ClefDonnees
Texte

tblMot
ClefMot
Mot

tblMotDonnees
ClefMotDonnees
ClefMot
ClefDonnees


Bon ça va être pas mal lourd donc le RegEx est quand même selon moi la bonne solution.
Il va falloir que tu te créer une fonctions VBA publique pour pouvoir appeler l'interpréteur de RegEx depuis une requête.

A+

[micniv]

Bonjour, sans passer par une biblio Regex (que je respecte énormément), tu peux mettre les mots de la phrase à rechercher dans un tableau. Et tu fais une loop sur les mots du tableau (si l'un est = à "oranger").
Personnellement, j'aime bien la fonction Split

[Le Sage]

Ouahou !

Je vois que la question suscite des passions !

En tout cas je vous remercie tous beaucoup pour vos réponses et vos idées toutes aussi intéressantes les unes que les autres.

Concernant les RegEx, je m'y suis intéressé un temps, j'ai créé mes fonctions de recherche et de remplacement en VBA (avec la bibliothèque addhoc), mais j'avoue qu'à chaque fois que je dois y retourner, je suis séduit par leur puissance, et dégoûté des heures qu'il me faut passer pour une expression "toute simple".
Je retiens l'idée qui est indiscutablement efficace.

Pour ce qui est du split, c'est pas idiot non plus, mais beaucoup plus fastidieux du point de vue du traitement car il devrait alors être itératif (mon critère peut être composé de plusieurs mots, justement pour éviter les confusions).

J'avais tenté de désactiver la compression unicode, sans résultat.

Du coup, ma solution d'ajouter un "¤" à la fin du critère et de le remplacer par un espace dans mon code m'oblige à y penser, mais comme c'est une base personnelle, je n'aurai qu'à faire attention lors de ma saisie (ce qui ne va pas trop mal en général). Pour l'instant elle fonctionne, mais je pense que lorsque j'aurais le temps de m'y pencher je jetterai un coup d'oeil aux RegEx (dont il n'est pas impossible qu'elles soient déjà activée dans ce projet ).

En tout cas, encore merci pour vos idées qui sont toujours de nature à éclaircir les miennes

Bonne continuation !

[marot_r]

Il m'est venue une idée cette fin de semaine.

Tu pourrais faire plusieurs recherches combinées

Code :

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

1
2
3
4
TonChamp="TonMot"
or TonChamp like "TonMot *"
or TonChamp like "* TonMot"
or TonChamp like "* TonMot *"

Si tu n'as que des espaces qui séparent tes mots ça devrait faire ce que tu veux.

A+

[micniv]

Ou encore saisir ton critère comme :

Code :

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

instr(1, Chaine_a_inspecter, space(1) & trim(tonMot) & space(1))

utilisation :
si instr(1, Chaine_a_inspecter, space(1) & trim(tonMot) & space(1)) > 0 alors space(1) & trim(tonMot) & space(1) est présent dans Chaine_a_inspecter
sinon
' = 0
la chaine space(1) & trim(tonMot) & space(1) est absente dans Chaine_a_inspecter