SUPPRIMER LES DOUBLONS D'UNE TABLE (VBA ACCESS)
cs_dragon
Messages postés
2336
Date d'inscription
samedi 14 juillet 2001
Statut
Membre
Dernière intervention
5 mai 2009
-
27 juil. 2005 à 22:22
allopeck Messages postés 23 Date d'inscription lundi 16 janvier 2006 Statut Membre Dernière intervention 3 décembre 2007 - 20 nov. 2007 à 06:59
allopeck Messages postés 23 Date d'inscription lundi 16 janvier 2006 Statut Membre Dernière intervention 3 décembre 2007 - 20 nov. 2007 à 06:59
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/32930-supprimer-les-doublons-d-une-table-vba-access
https://codes-sources.commentcamarche.net/source/32930-supprimer-les-doublons-d-une-table-vba-access
20 nov. 2007 à 06:59
20 nov. 2007 à 06:58
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
27 sept. 2007 à 22:42
27 sept. 2007 à 17:39
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
28 juin 2007 à 15:27
28 juin 2007 à 09:10
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)
24 août 2005 à 02:37
J'ai réalisé des pointeuses sous BP6 POO avec Turbo Vision.
C'est vrais que certains employés essayent de trafiquer les pointeuses ou directement de faire bugger les bases ou autres outils utilisés pour gérer ces temps!
Mois j'ai fait une table avec clef primaire unique auto incrémentée et sans récupération des entrées brûlés.
Puis en liaison une autre qui contiens les horaires d'entrée.
Enfin une troisième qui contiens les temps de présence!
Celas permet de gérer le temps de chaque employé de créer des alarmes et autres choses intéressantes.
Le tout sans se prendre la tête et HYPER simple.
Pour la sauvegarde et la maintenance il suffit de gérer deux sauvegardes des fichiers dont une porte l'extension « .Bak » et l'autre « .old » sachant que lors d'une sauvegarde de base le bak deviens old et la base courantes deviens bak, ainsi on pers riens.
Pour la vitesse je me méfie de la RAM car même un serveur ça plante et ça utilise l'électricité donc risque de coupure!
Alors de enregistrements de base périodiques c'est bien mais travailler sur des portions de base c'est mieux et moins risque mais il faut se creuser la tête.
Mois ça fait pas 50 ans que je fait de l'info car j'ai toujours cru que l'info a démarrée avec le microprocesseurs et les premiers que j'ai utilisés dataient des années 70-80 (8080, Z80, 6500, 6800 . . .) j'ai programmé mon premier système d'exploitation avec des Interrupteurs! pour les bas il y avait le papier et les crayons. . . . . .
Bon courage et bonne chance a tous et arrêtez de vous prendre la tête nous avons tous de connaissance et des expériences différentes alors partageons les sans mépriser celles des autres pour je ne sais quels études ou diplôme!
Tout ça c'est de la M... Ce ne sont que des connaissances acquises à la portée de tous!
Mais ayons au moins l'intelligence de le reconnaître!
bye bye.
16 août 2005 à 22:28
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).
16 août 2005 à 20:50
je dis que certaine table ont pas peut mettre de numéro automatique
99% des tableau ont des clé unique, mais dans certain cas non
16 août 2005 à 17:28
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
12 août 2005 à 19:04
Je ne crois pas que Microsoft ou Oracle s'amuseraient à sortir des SGBD si ceux-ci devenaient d'un seul coup inutiles.
JET (le moteur d'access) est parfaitement performant, il est utilisé sur encore quelques autres produits de microsoft (Exchange, ActiveDirectory). Il gère très bien les clefs primaires et étrangère et respecte sans problème les contraintes d'intégrité qui lui sont imposés.
Tous les SGBD un tant soit peu performants gèrent les caches mémoire tous seuls comme des grands (même JET). Ceci me permet de me concentrer sur les tables, les requêtes, les index et l'optimisation disque de ceux-ci.
Ca m'étonnerai aussi que cinquante ans de travail sur l'optimisation des bdd puisse être balayé du jour au lendemain. On arrive aujourd'hui à des systèmes particulièrement efficaces, cohérents et fiables.
Tes pseudos théories sur la mémoire vont faire quoi ? Ajouter une couche de gestion de données sur une couche de gestion de données. Libre à toi de le faire, mais ton système n'ira pas plus vite et ne sera pas plus fiable.
Ensuite on va resituer le contexte. Aujourd'hui les client mutualisent leur serveurs d'applications. Imagine sur un serveur que 30 personnes chargent toutes les données d'une base. Si on passe sur la charge que le serveur doit supporter, même si la base ne fait que 50mo, tu auras des problème de cohérence dues aux multiples entrées de ces utilisateurs. L'optimisation des accès disque est déjà une necessitée.
Ensuite, les bases les plus utilisés tendent à être les plus imposantes (une base de gestion peut atteindre quelques dizaines voire centaines de Go). La encore, c'est l'optimisation des mes accès disques qui va me sauver la vie. Je te jure que jamais je ne m'aventurerai à charger un grand livre en RAM... (cf. Comptabilité générale)
Maintenant voici quelques unes de mes références :
www.generationsroller.asso.fr (base access, serveur mutualisé donc mon appli doit rester discrète)
www.fncdg.com (base sql serveur avec index fulltext) (15000 visites/jours, 100000 pages recherche vues/jour, serveur dédié PIII 800 avec 700Mo de RAM, La base fait 1,2Go plus 800Mo d'index) (un traitement d'intégration de données provenant de presque tous les cdg de france tourne 24h/24 en tâche de fond)
Comme tu peux le constater, c'est pas la puissance foudroyante de mes serveurs qui me permet de tenir la charge. Pourtant les applis répondent au quart de tour. Je pense donc que ma façon de programmer n'est totalement dénuée de sens, ni d'un minimum de savoir faire.
12 août 2005 à 13:16
"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 ???
12 août 2005 à 11:52
Par contre .. Dragon .. revise un peu ce que peut etre une cle primaire .. et une BDD .. ou des cles.. enfin .. j'espere que je vais pouvoir vous lire encore un peu .. c'est plaisant les débats comme ça... ;-p
12 août 2005 à 01:32
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.
11 août 2005 à 19:16
Depuis quand tu connais les données que tu vas mettre dans une table ? tu ne connais que leur format et leur utilité. Pourtant je sais mettre une clef primaire sur ma table. Si tu n'arrive pas à prendre de recul sur les données que tu gères (en 1 heure c'est difficile je le reconnais) pour en comprendre le format c'est sûr tu auras des problèmes. Si ton employé ne peut poinçonner qu'une fois à une heure donnée, ton heure est dans la clef.
Sinon, oui je peux avoir une table où tout les champs sont dans la clef : une table de liaison 0n à 0n par exemple, où une table evenement comme celle que tu gères.
"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. "
Tant qu'on aura plus de disque que de RAM, on utilisera le disque. Tant que la RAM sera volatile on utilisera le disque. Si ma table est plus grosse que ma RAM, il faut que j'optimise ma table pour écrire vite, lire vite. Ca tombe bien, c'est mon job. Avec le nombre de clients gu... à cause de cette philosophie du tout en RAM, je ne suis pas prêt d'être au chômage.
Par contre je te donne raison sur un point : tu prépares tes données en RAM et tu écris tout d'un coup.
Oui j'ai mis 2/10, pour des problèmes de manque de commentaires, d'utilisation de variables globales (typeChamps, tableau), d'utilisation de tableaux à la place de collections
11 août 2005 à 18:55
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.
11 août 2005 à 12:51
Clef primaire : ensemble de champs non nuls qui permettent d'indentifier de façon unique un enregistrement.
Index : Copie ordonnée des données d'une table dont le but est d'accélerer la recherche desdites données indexées
Contrainte : s'applique sur un ou plusieurs champs d'une table et permet de guider la façon dont les données doivent être écrit dans ces champs. On a deux type de contraintes :
- Clef etrangère : ensemble de champs dont les valeurs proviennent d'un index
- unique : les valeurs dans les champs non nuls doivent être unique pour l'ensemble des champs représentés dans la contrainte
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é
Je te conseille très vivement d'ouvrir un bouquin sur les bases de données, voire spécifiquement sur access. Tu y apprendras qu'access est une base transactionnelle et que tu peux inscrire les enregistrements dans la base quand tu as fini de travailler dessus. Qu'une clef primaire ne ralenti ni la lecture ni l'écriture dans une table (au contraire, ça accélère les deux, ainsi que les statistiques sur les tables). Qu'une contrainte par contre ralenti l'écriture, surtout si elle est mal construite. Qu'access supporte les clefs étrangères depuis la version 2.0... Et j'en passe.
PS : ça fait dix ans que je travaille sur des bases de données, je suis en train de passer les certifications SQL Server, je sais travailler sur une liste assez impressionnante de BDD, les informations que je te donne ici ne sont donc pas de ma pure invention. Mon expérience personnelle me permet de savoir ce que je peux attendre d'un SGBDr. D'access je peux en attendre le travail sur une table avec une clef primaire et une clef étrangère sans aucune arrière pensée de performance ni de fiabilité.
11 août 2005 à 12:17
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.
11 août 2005 à 08:49
n_employe obligatoire
heure obligatoire
le couple n_employe, heure est unique
=> le couple n_employe, heure identifie l'enregistrement donc qu'on a
1 clef primaire avec 2 champs : n°employé et heure.
Tu as aussi la possibilité d'utiliser des index uniques, des contraintes uniques...
C'est pas les moyens qui manquent, par contre tu ferais bien de te pencher sur les bases exemples d'acces pour voir comment elles sont construites.
11 août 2005 à 05:16
10:2005-08-01 07:00
10:2005-08-01 17:00
11:2005-08-01 07:05
11:2005-08-01 16:58
10 août 2005 à 08:58
J'ose esperer que tes employés n'ont pas le don d'ubiquité.
Après tu auras certainement besoin de gérer les chevauchements d'horaire mais c'est un problème assez trivial.
9 août 2005 à 19:47
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
9 août 2005 à 19:45
Il suffit dans les tables Access de définir une clé primaire afin d'éviter les doublons.
28 juil. 2005 à 23:25
c'est quand même sous-entendu "tout le code doit-être dans un module dans la base de donnés access "
28 juil. 2005 à 23:23
28 juil. 2005 à 23:06
28 juil. 2005 à 19:49
Des problèmes en perspective ...
28 juil. 2005 à 09:17
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.
27 juil. 2005 à 22:22
Private Sub Tb_Horaire_Enr_AVG()
Private Sub Tb_Horaire_Enr_AVG_calculer()
Private Sub Tb_Horaire_Enr_Employe()