Discussion :

[Delioneras]

Bonjour à tous et à toutes.

Je fais face à un "petit" soucis. Je dois comparer les champs de plusieurs tables, notamment sur un pivot Num_Serie.
Le problème étant que ce pivot est généralement saisi manuellement par les utilisateurs (fichier comptable, inventaire, etc etc).

Je dois établir des liens entre mes informations, mais un problème vient d'apparaitre, les utilisateurs sont, semble-t-il, des experts en anagrammes.

Je m'explique, j'ai, par exemple, un Num_Serie qui vaut "FNCOO9146O5369".
Son équivalent sur mon autre table est "FCNOO9146O5369".

A première vue identique, pourtant Access me les identifie comme différents, après examen des chaines de caractère, il apparait que le NC au début du premier a été inversé dans le second.

Un autre exemple: "FCNOO81555O8783" pour "FCNOO8155O8783" en face.
Dans la deuxième, il manque un 5 en plein milieu.

Je ne parle pas non plus des "O" qui sont des "0", et inversement.
(Encore que pour ce point, un coup de replace, on uniformise le tout, ça marche).

Tout cela montre des erreurs d'inattention/de frappe des utilisateurs, ce qui arrive à tout le monde.
Mais du coup, je ne sais plus comment gérer mes données.

Visuellement, je sais identifier qu'il s'agit de la même information ... Mais SQLement, je bloque.

Et je ne suis même pas sûr que ce soit faisable / fiable (risque de doublon qui augmente exponentiellement dès lors que je modifie l'arrangement des caractères, je le sens venir de très loin).

Si quelqu'un a une idée à me soumettre, je suis preneur.

Merci d'avance,
Cordialement,
Delioneras

[anthurBB]

Pourquoi doivent-ils rentrer 2 fois la même donnée ? Ne serait-il pas plus simple d'appeler lors de la 2ème entrée un menu déroulant reprenant les n° déjà entrés dans l'autre table, afin d'éviter de faire rentrer une 2ème fois avec erreurs ... Le but des BdeD est justement d'éviter les doublons de ce style ...
Je prends un peu en amont, désolée cela ne résoudra pas le pbe des données déjà rentrées, mais peut-être pour l'avenir ...
Quant aux données déjà entrées, cela ne marche pas avec 'like' ou les recherches phonétiques (??pas regardé de près) http://access.developpez.com/sources...quete#Soundex1?

[philben]

bonjour,

y'a combien de lignes à vérifier ?

Philippe

[Delioneras]

Bonjour, et merci à vous deux pour vos réponses.

@anthurbb
La saisie est faite 2 fois car il s'agit d'une gestion et vérification d'inventaire.
Il y a l'existant dans la base, et ce que note la personne en charge de l'inventaire terrain. Les deux pouvant donc se contredire et/ou entrainer des erreurs de saisie.

Je suis bien d'accord sur le principe de saisir deux fois. Je vais même plus loin, pour moi, un pivot doit être obligatoirement être une clé système, unique et fortement indexée. Et non soumise à la saisie d'un utilisateur.
Littéralement, une clé primaire.
Mais ils ne font pas comme ça, et ce n'est pas à moi à refaire tout le système.

@philben
En tenant compte des restrictions que j'ai placé sur mes requêtes (localisation, année 2012, etc), ça concerne environ une trentaine de ligne (31 pour être précis).
Mais ça peut monter dès lors que les critères de sélection changent.

[f-leb]

bonsoir,

peut-être quelques pistes dans un article de sqlpro:
Comparaison de motifs avec SQL Server 2000 - Fonctions pour le rapprochement de données

évidemment tout reste à faire pour adapter à Access

[philben]

bonjour,

une solution en VBA ici.

Philippe