Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1730 connectés 

  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [Access] Comparaison de données "hasardeuse"

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[Access] Comparaison de données "hasardeuse"

n°477054
freds45
Posté le 04-08-2003 à 15:33:34  profilanswer
 

:hello: 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 :D mais là, c'est un peu du n'importe quoi : par exemple d'un côté j'ai
 


63 rue XXXXXX 31300 toulouse


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?  :sweat:


---------------
Filmstory : gardez trace des films que vous avez vu ! :D
mood
Publicité
Posté le 04-08-2003 à 15:33:34  profilanswer
 

n°477464
MagicBuzz
Posté le 04-08-2003 à 20:23:29  profilanswer
 

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.

n°477787
freds45
Posté le 05-08-2003 à 10:36:59  profilanswer
 

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  :sleep:  
 
J'ai donc écrit ça:
 

SELECT paie.secu, paie.nomprenom, paie.adr,Trim( Right(Extraction!adr2, Len(Extraction!adr2)-5))
FROM paie, extraction
WHERE paie.secu=[extraction].[compte]
AND paie.adr like Trim( Right(Extraction!adr2, Len(Extraction!adr2)-5));


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


AND paie.adr like Trim( Right(Extraction!adr2, Len(Extraction!adr2)-5))

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


---------------
Filmstory : gardez trace des films que vous avez vu ! :D
n°478021
freds45
Posté le 05-08-2003 à 14:06:44  profilanswer
 

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

SELECT paie.secu, paie.adr, extraction.adr2, extraction.cp, extraction.bureaudistrib
FROM paie, extraction
WHERE (paie.secu=[extraction].[compte] AND paie.adr not like "*" & extraction.bureaudistrib & "*" );


 
C'est pas terrible, mais bon [:spamafote] la base est mal foutue :o


---------------
Filmstory : gardez trace des films que vous avez vu ! :D
n°478385
MagicBuzz
Posté le 05-08-2003 à 16:47:33  profilanswer
 

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.

n°478407
freds45
Posté le 05-08-2003 à 16:55:41  profilanswer
 

MagicBuzz a écrit :

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 :) !


---------------
Filmstory : gardez trace des films que vous avez vu ! :D

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [Access] Comparaison de données "hasardeuse"

 

Sujets relatifs
[Résolu] formulaire => données envoyés à fonction php ?[VBA/ACCESS] Equivalent a addslashes en vba
[Access][VBA]Recup la clef autoincrémenté de l'enregistrement en cours[ACCESS][SQL] Questions sur des requêtes avec Group by
Créer un lien dans XSL en fonction de données dans XMLACCESS | Probleme de date HELPPPP
[ACCESS]Questions sur la multi utilisation[SGBD] Cherche équivalent ('%query%') pour Access !!!
[ACCESS] Affecter une valeur à un composant d'un formulairePhpbb et base de données
Plus de sujets relatifs à : [Access] Comparaison de données "hasardeuse"


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR