all
 
Voilà, sous Access j'ai deux tables qui contiennent des entrées salariées, avec un champ adresse dans chacune d'elle. Une table est de référence, càd les données qu'elle contient sont valides. La seconde provient d'une autre base de données, mise à jour un peu n'importe comment...
Ce que je dois faire, c'est trouver les entrées dans la seconde table qui ne correspondent pas à la première niveau adresse. Si c'était formaté correctement ok pas de souci mais là, c'est un peu du n'importe quoi : par exemple d'un côté j'ai
 

en un seul champ, et de l'autre
[fixed]
0063  R. XXXXXX
 
 
31300
TOULOUSE
[fixed]
dans 5 champs différents!
 
Bref c'est la pagaille... Ya 16000 enregistrements d'un côté et 36700 de l'autre, donc je peux pas trop faire à la main
 
Même en faisant des concaténation, ya plein de cas ou ya juste une petite bricole qui change et donc l'adresse est "correcte"... Qqun a une solution?  

Y'a pas de solution à ton problème.
C'est pour cette raison qu'on saisi généralement les adresses dans autant de champs distincts qu'il y a d'éléments dans une adresse :
 
numéro_rue
type_de_voie
nom_rue
code_postal
ville
centre_postal (pour les adresses en CEDEX)
 
Là, t'es baisé, les seules données à priori que tu puisse récupérer pour la comparaison c'est le code postal, le nom de la ville et à la limite ne numéro dans la rue...
 
exemple :
 
Ensuite, tu peux jouer avec des like (rechercher le champ "ville" dans la chaîne de l'adresse, et ainsi pour le CP)
Pour le numéro de ville, faut que tu retrouves la sous-chaîne composée du premier mot de la ville et que tu la compares avec ne numéro de la rue converti en numérique pour perdre les 0
 
pour le nom de la rue, et le type de voie, t'es baisé, tu trouveras rien d'acceptable comme algo, car déjà pour le localiser dans la chaîne de l'adresse, tu vas pleurer.

bah je sais c'est un peu la m****
 
Après avoir comparé un petit nombre d'entrées à la main, ce que j'ai trouvé comme solution pas trop mal, c'est de récupérer le nom de la rue dans ma table mal mise à jour, et de chercher ce nom via un like dans la table de référence    
 
J'ai donc écrit ça:
 

 
(Paie est la table de référence, Extraction la table mal fichue)
 
Mais apparement, il n'aime pas la dernière partie

J'ai droit à un beau 'Appel de procédure incorrect' bien mystérieux
Qu'est ce qui cloche? Une idée?

bon finalement j'ai comparé par rapport aux villes vu que c'était impossible de faire autrement:
 

 
C'est pas terrible, mais bon la base est mal foutue

bah c'est surtout la base "propre" qui est mal foutue.
 
si ton volume d'infos est important, à ta place j'en aurai profité pour faire évoluer le modèle afin de stocker ça proprement dans des champs distincts.

 
Je sais bien
En fait la table "propre" provient d'une appli de paye, et la 2eme (la plus grosse) d'un systeme de base de données. Le but c'était de repérer dans ma grosse table les salariés qui ont changé d'adresse (dans l'appli de paye).
J'ai montré ça à mon chef, ça a l'air de lui convenir !