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

[Delioneras]

Bonjour, et merci à f-leb et philben

La distance de Levenshtein ... C'est ce que j'ai trouvé de plus approchant/précis pour l'instant oui.
J'ai une version implémentée sur Excel, mais le traitement est assez ... conséquent.

Je vais regarder vos articles, sur SQL Server et Access, concernant l'implémentation de ces distances.

Ca me donnera des pistes à suivre pour optimiser l'analyse des quelques 6 millions d'infos (88000 lignes dans le fichier comptable, et 785 informations à compléter dans mon inventaire. Risque d'erreur de saisie sur le numéro de saisie, il faut donc tout analyser. 88000 * 785 = 6 908 000, Excel aime pas. Pas du tout).

Je vais regarder ça sur les moteurs de base de données, merci

[Delioneras]

Rebonjour,

J'ai regardé les deux articles. J'ai déjà testé le levenshtein, mais le temps de traitement est trop important.

J'ai cru comprendre que l'Inférence Basique était plus performante, notamment en terme de vitesse ?
Si oui, j'ai une question pour f-leb. Au début de l'algo en transact-sql, la fonction renvoie 0 si source ou cible valent ''.

Ne serait-ce pas plus logique de renvoyer la longueur de la chaine autre ?

Code :

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

1
2
IF source = '' RETURN LEN(cible)
IF cible = '' RETURN LEN(source)

En tout cas, merci, je cherchais justement à optimiser mes boucles

Je vais tester ce que donne mon adaptation de l'inférence basique, avec tous mes remerciements.

Delioneras