SUPPRIMER LES DOUBLONS D'UNE TABLE (VBA ACCESS)

Commentaire de Warny le 28/07/2005 09:17:09

La même chose sans code VB... en 4 lignes

SELECT DISTINCT * INTO TA_TABLE_TEMP FROM TA_TABLE
DELETE FROM TA_TABLE
INSERT INTO TA_TABLE SELECT * FROM TA_TABLE_TEMP
DROP TA_TABLE_TEMP

puis sauvegarde de ta base de données si tu es sur sql server en mode complet.
Si tu veux enlever des clefs en doublon il faut créer la table temp explicitement avec une clef primaire et enregistrer les éléments dedand un par un en ignorant les erreurs.

Commentaire de dragon le 28/07/2005 23:06:37

en vba add existe pas, en tout cas pas tout seul

Commentaire de dragon le 28/07/2005 23:25:10

oups je croyais l'avoir écris
c'est quand même sous-entendu "tout le code doit-être dans un module dans la base de donnés access "

Commentaire de dragon le 09/08/2005 19:47:48

ça dépend toujours du type de table. certaine table peuvent avoir des valeurs identique.

exemple une table avec id du numéro de l'employé et une heure de poinçon. tu aura pas de clé proprement dit dans ce cas la

Commentaire de dragon le 11/08/2005 05:16:00

elle est ou ta clé primaire la dedans ??? Il y en a pas, c,est un clé étrangère ou une clé qui peut avoir des doublons. Sauf que je veux pas 2 employé identique avec l'heure identique. Donc la le code va servir pour les enlever. en entreprise faut s'attendre a tout

10:2005-08-01 07:00
10:2005-08-01 17:00
11:2005-08-01 07:05
11:2005-08-01 16:58

Commentaire de dragon le 11/08/2005 12:17:09

eh ... c'est ça que j'ai dit. ça s'appel une clé étrangère, un clé constitué de 2 champs. Sauf que je développe en entreprise sous acces 97 (par obligation) et il supporte pas les clés étrangère. Donc je dois géré les doublons par moi-même vu que je développe pas en vba, mais en vb.net. Donc 100% des requête SQL sont créé par moi. Mais si un employé va chercher 2 fois le même fichier, tu as beau mettre un protection pour pas que des doublons s'écrire, mais acces97 fini toujours par en faire passer 1 ou 2 sur des millions d'inscription (fait des tests, sur des millions d,inscription, access97 retourne pas toujours le même nombre de réponse. c'est un bug de 97)

en plus, dans les 2 exemple que j'ai donné
Tb_Horaire_Enr_AVG
Tb_Horaire_Enr_AVG_calculer

les clé étrangère sont constitué de 4 champs et désoler, je veux réellement pas qu'Access gère ça sinon tu viens de tout ralentir l'application. donc je le gère moi-même, mais même la, si l'application bug ou l'usager fait n'importe quoi, il peut réussir a doubler certaines donner et la le nettoyage peut-être pratique. Bien que mon code supporte les doublons, mieux vaut pas en avoir pour avoir une base de données optimal et avoir une perte de vitesse minimal.

j'ai pas dit que ce code était une base de mon programme, moi je m'en sert pour nettoyer mes base de données aprèes qu'un problème soit survenu. c'est pour ça que c'est développer sous Access et non sous vb.net. C'est des outils de nettoyage. Comme j'en ai un autre qui vérifie les liens voir s'il y a pas des données perdu avec plus aucune référence avec une autre table (genre l'application a planté entre 2 enregistrements). çca m'affiche un rapport et çca me permet de les supprimer ou de rétablir les liens. Mais vu que c'est trop personnel a l'application en cour, ça donne rien de poster ça ici celui-la.

Commentaire de dragon le 11/08/2005 18:55:24

garde la théorie est bien beau. j'ai un dec en infromatique de gestion plus je suis en BAC en génie logiciel.

je travail pour 3 compagnies depuis plus de 3 ans

tu apprendra que la théorie est pas toujours applicable dans certaine situation et du code de maintenance est très normal. Intégré ce code dans l'application elle même, je suis totallement d'accord avec toi, ça va pas là et ça ralentie le code. Mais externe quand l'application plante, avoir une façon de maintenir ses tables ou les épurer est une méthode normale. Mes tables respectes les 5 première loies normales SQL. Mais une tables où la clé est continuer de tout les champs, ça donne rien. Surtout quand un des champs est une date et une heure, puisque pour avoir une valeur on fait notre id plus une between pour avoir les heure dans cet intervale. Ta clé sur plusieurs champs va rien faire.

mais je suis d'accord avec toi que 99% du temps tu as des clés sur un ou deux champs. Mais tu as toujours un 1% que tu dois lacher la théorie parce que tu as pas 1 semaine a faire dequoi, mais 1 heure. J'ai du construire un serveur SQL au complet en 1 heure. Donc faut tourner les coins rond et c'est normal. Si on est chez microsoft ou une grosse boite, on tourne les coin moins rond a cause du budget immense. Mais dans les petite boite, les coin sont tourné beaucoup plus rond et faut s'arranger avec les outils et le temps qu'on a. Donc c'est bien beau la théorie, mais c,est pas toujours applicable dans toutes les situations.

En plus, le but de vbfrance, je crois pas que tu l'as bien compris, est d'aider les autres. Beaucoup de monde on demander comment supprimer les doublons. Alors mon code viens les aider. Toi tu arrives et tu fais juste dire ben c'est mal programmer. Désoler ça aide pas pentoute. Sinon comme moi, le code que je dois maintenir a pas été fait par moi. en tout cas pas cette partie. Donc désoler, mais je dois faire avec et m'arranger que ça marche.

J'immagine que c'est toi qui m'a donner un  2/10 sur ma source. Tu l'as tester ??? est ce qu'elle fait la job qu'elle devrait faire. Oui. alors tu as beau pas aimer la source, tu peux pas mettre des notes faibles sur des sources qui fond ce pourquoi elle a été programmé.

Petite correction que tu as dit sur les tables de mon exemple

Dans ta table tu as  au moins 2 champs : n°employé, heure
Dans ta clef primaire tu as deux champs : n°employé, heure
Tu as une contrainte de clef étrangère : n°employé pointant vers la clef primaire de la table employé

faux

je connais pas les dates que ça va me retourné, cette table sert justement a ça. Donc si on connait pas le réultat a obtenir, on peut pas mettre ce champs comme clé. Souvent c'est tables sert pour les intervales de temps. Genre les heures de poinçon d'un employé. Ton champs date ne peux pas être dans la clé, on connais pas à la seconde près le poinçon, puisque c'est cette table qui le dit. On peut juste lui demander un intervale de temps pour un employé bien précie.

En passant, une nouvele philosophie commence a arriver en ingénérie logiciel. ça va peut-être te faire chier, mais on tend de moins en moins d'utiliser des bases de donner, puisque la RAM est plus rapide. Donc ta certification risque de pas servir a grand chose d'ici quelques année, sauf pour les programmes fait en entreprise qui possède pas d'ingénieur. Un bon singleton bien construit est plus rapide que n'importe configuration de n'importe sorte de SQL, si le serveur est bien construit.

Commentaire de dragon le 12/08/2005 01:32:23

un utilitaire est vite fait pour faire une réparation vite fait. Pour les commentaire, je te l'accorde. Pour les variable globale, j'avou que c'est pas super, je déteste le vba, je préfère et de loin vb.net, java et C sharp (orienté objet quoi)

pour ce qui est de la ram, on voit de plus en plus de monde prendre une base de donner pour stocker, mais lire la base de donner, la mettre en RAM et quand il y a des modification a faire, mettre ça dans une liste (first in first out) et avec un thread a faible priorité écrire dans la base de données les modification. si on ferme le serveur, la priorité du thread tombe au plus haut pour tout écrire. On redémarre l'application et tout retombe en RAM en moins de 5 secondes. Comme ça, on a la vitesse de la RAM, la sauvegarde de la base de données et la priorité au modification en RAM avant celle sur le disque dur.

En passant, as tu déja vu un employé poinçcon 4 fois dans la même heure ??? J'en ai pogner un aujourd,hui même.

entré a 6H57
début du quart a 7H30
sortie de l'usine a 7H45
revenu a 10H15
repartie a 15h35
revenu a 16h00
fini son quart a 17h30
partie de l'usine a 18h45

t'essaira mettre ça en clé primaire pour le fun. Ça c'est juste 1 employé pour une journée. Et compte pas ceux qui arrive 1 heure avant ou après le début du quart si c'est pas plus et ceux qui sont de nuit. Comme je disais c'est impossible prédire la clé exact. On peut juste prédire l'ID de l'employé et un range d'heure ou il devrait arriver sinon donner la possibilité d'allonger le range lorsqu'on valide.

Commentaire de dragon le 12/08/2005 13:16:16

je crois que tu as manqué un bout. j'ai jamais parlé de pile. Mais l'utilisation de la RAM pour les donner live et une sauvegarde dans une base de donnée pour garder en mémoire quand on ferme le serveur. Qaund on redémarre on va chercher les donner dans la base de donnée puis on remet en RAM.

"mais lire la base de donner, la mettre en RAM et quand il y a des modification a faire, mettre ça dans une liste (first in first out) et avec un thread a faible priorité écrire dans la base de données les modification"

Lit des livre sur l'optimisation des données en software engeneering. Tu vas voir qu'avec le rpix de la RAM, on préfère très souvent ajouter plus de RAM sur un serveur et beaucoup plus stocker de la mémoire. la RAM est quand même plus de 100 fois rapide qu'un disque dur. Une base de donnée complète fait rarement plus de 100mo et si elle est optimiser avec des tables pour stocker le texte a lieu d'avoir le texte mis dans presque dans toutes les tables (j'en ai souvent vu dans des logiciels professionnel qui coutaient plus de 30 000$ US qui utilisait du texte comme clé primaire et du texte de 255 caractères), alors la base de donnée peut-être très souvent en bas du 50mo.

En résumer, le software engineering préfère utiliser la RAM plus rapide pour les donner live et stocker dans une bd quand le serveur travail moins pour garder en mémoire lors d'une fermeture du serveur.

pis je voie réellement pas pourquoi tu parle de clé primaire gandalfgris ??? Est ce que tu as toute lu la discution ???

Commentaire de NeoMetaller le 16/08/2005 17:28:40

Une autre solution avec une requête SQL sans création/suppression de table, mais il faut des ID uniques (moi j'ai une colonne ID en auto incrément) :

DELETE FROM Cible WHERE ID < ANY (SELECT c.ID FROM Cible c WHERE Cible.ID <> c.ID AND Cible.Nom = c.Nom AND Cible.Prenom = c.Prenom AND Cible.Adresse1 = c.Adresse1 AND Cible.Adresse2 = c.Adresse2 AND Cible.CodePostal = c.CodePostal AND Cible.Ville = c.Ville)

ça marche nickel chez moi avec Access et MSDE

Commentaire de Warny le 16/08/2005 22:28:34

100% des tables peuvent (et devraient) avoir des clefs uniques. Même si c'est un identifiant qui n'a rien à voir avec les données.
Il n'existe AUCUNE bonne raison pour qu'une table de production n'ait pas de clef primaire. Il faut toujours pouvoir identifier une ligne de la table de façon unique.

La solution du ANY est très jolie, chapeau bas.
Perso, je préfère avoir un guid en clef, c'est plus simple si on doit fusionner des lignes venant de 2 tables différentes (là ca se discute vraiment).

Commentaire de emixame le 28/06/2007 09:10:01

Ce code me parait tres interressant, le seul hic, c'est que j'ai une erreur a cette ligne :

Set rst = CurrentDb.OpenRecordset("select count(*)," & champs & " from " & table & " GROUP BY " & champs & " having count(*) > 1")


Le compilateur me met :

Run-time error 3141

The select statement includes a reserved word or an argument name that is misspelled or missing, or the ponctuation is incorrect

Si quelqu'un peut m'aider, ca serait sympa.

(PS: desole pour les fautes d'accents et autres mais je suis sur un qwerty)

Commentaire de Jean_Marc_1968 le 27/09/2007 17:39:28

Je trouve cette discussion pour le moins intéressante, et j'ai un cas typique de doublons à supprimer qui ne peut pas ne pas se générer grâce à une indexation unique.

Soit une relation plusieurs à plusieurs en Access. Il me faut définir plusieurs points pouvant chacun se trouver dans différents secteurs. Chaque secteur peut, lui aussi, contenir différents points. Dans la table de points, le numéro de point est indexé sans doublons. Dans la table de secteurs, le numéro de secteurs est indexé sans doublons.
Je pense que même les super diplômés seront d'accord avec moi qu'en Access il n'y a pas moyen d'éviter la table intermédiaire indexée avec doublons pour reprendre le numéro de point versus les différents numéros de secteurs et inversement.

Régulièment, des importations externes doivent être faites parce que des fournisseurs externent envoient des données à introduire.
Il se peut donc que des doublons se créent dans la table intermédiaire, le même point étant dès lors lié plusieurs fois au même secteur. Ceci engendrant bien entendu des erreurs de comptage de point par secteur, pour reprendre un exemple trè simple.

La suppression de doublons me paraît fort intéressant, du moins dans ce cas particulier.

Si toutefois quelqu'un à la clé qui permettrait de crééer des liaisons plusieurs à plusieurs, et donc d'éviter les tables intermédiaires, je suis preneur.

@+
Jean-Marc

Commentaire de allopeck le 20/11/2007 06:58:16

Bonjour,
J'ai un gros problème avec les doublons et j'ai trouvé ton code seulement je connais absolument rien en VB.
voila ce que j'ai écrit
Option Compare Database
Option Explicit
Dim tableau() As String
Dim typeChamps() As String
Private Sub Tb_Horaire_Enr_AVG()
    'initlise les tableaux
    ReDim tableau(0)
    ReDim typeChamps(0)
    
    'On écris les champs de la requête
    add "date"
    add "GPSX"
    add "GPSY"
    
    'Puis on enlève
    EneleverDoublons "Tb_Horaire_Enr_AVG"
    MsgBox "terminé"
End Sub


Private Sub add(champ As String, Optional typ As String = "")
    If champ <> "date" Then
        ReDim Preserve tableau(UBound(tableau) + 1)
        ReDim Preserve typeChamps(UBound(typeChamps) + 1)
    End If
    tableau(UBound(tableau)) = champ
    typeChamps(UBound(typeChamps)) = typ
End Sub
Private Sub EneleverDoublons(table As String)
    Dim rst As Recordset
    Dim i As Integer
    Dim champs As String
    Dim where As String
    Dim valeur As String
    'On construit la requete
    For i = 0 To UBound(tableau)
        champs = champs & " , " & tableau(i)
    Next i
    champs = Mid(champs, 4)
        
    Set rst = CurrentDb.OpenRecordset("select count(*)," & champs & " from " & définitive & " GROUP BY " & champs & " having count(*) > 1")
    While Not rst.EOF
        where = ""
        valeur = ""
        For i = 0 To UBound(tableau)
            
            If typeChamps(i) = "bool" Then
                where = where & " and " & tableau(i) & " = " & IIf(rst(i + 1).Value, "true", "false")
                valeur = valeur & "," & IIf(rst(i + 1).Value, "true", "false")
            Else
                If IsNull(rst(i + 1).Value) Then
                    where = where & " and " & tableau(i) & " = null"
                    valeur = valeur & ",null"
                Else
                    where = where & " and " & tableau(i) & " = " & typeChamps(i) & rst(i + 1).Value & typeChamps(i)
                    valeur = valeur & "," & typeChamps(i) & rst(i + 1).Value & typeChamps(i)
                End If
            End If
        Next i
        where = Mid(where, 6)
        valeur = Mid(valeur, 2)
        CurrentDb.Execute "delete * from " & définitive & " where " & where
        CurrentDb.Execute "insert into " & définitive & " values(" & valeur & ")"
        rst.MoveNext
    Wend
End Sub
Voila j'ai une table avec quatre colonne sans clés primaire. et je ne dois jamais avoir 2 fois les même coordonnée pour 1 jour. donc mes trois première colonne sont "date" "GPSX" et "GPSY" ce que j'ai mis ci-dessus. Et le nom de ma table est définitive.
Problème lorque que je veux tester si cela fonction il me dit d'enregistrer le macro. Je mets un nom et aprés jai Sub lenomdumacro et endsub. Pouvez me guider pour faire fonctionner votre code ? sachant que je travaille sous access 2003.
Merci beaucoup, je suis ouvert à toute autre proposition pour supprimer mes doublons.
Bonne journée