Requête de recherche de doublons à améliorer

Bonjour.

Je suis en train de corriger une table qui contient environ 10000 lignes. Il y a eu pas mal d'erreurs de saisie, ce qui fait qu'elle comporte un nombre important de doublons que je dois supprimer (la table n'avait pas de contrainte d'unicité).

VAC_ID (clé primaire auto-incrémentée)
VAC_DATE
D1_ID
D2_ID

Il ne doit y avoir qu'un seul "couple" D1_ID et D2_ID par VAC_DATE. J'ai donc créé cette requête pour trouver les doublons :

Code:

---

1 2 3 4 5

SELECT COUNT(*) AS VAC_DOUBLON, D1_ID, D2_ID, VAC_DATE FROM T_VACATIONS GROUP BY D1_ID, D2_ID, VAC_DATE HAVING COUNT(*) > 1 ORDER BY VAC_DATE ASC, D1_ID ASC

---

Elle fait le boulot mais comme il y a beaucoup de lignes à supprimer, j'aimerais savoir comment faire pour afficher également la colonne VAC_ID afin que je puisse créer un script pour supprimer en un clic tous les doublons (et même certains "triblons" et "quadrublons").

Merci.

Tu peux faire comme ça :

Code:

---

1 2 3 4 5 6 7 8 9

SELECT ALL VAC_ID, D1_ID, D2_ID, VAC_DATE FROM T_VACATIONS WHERE (D1_ID, D2_ID, VAC_DATE) IN ( SELECT ALL D1_ID, D2_ID, VAC_DATE FROM T_VACATIONS GROUP BY 1, 2, 3 HAVING COUNT(*) > 1 ) ORDER BY 2 ASC, 3 ASC, 4 ASC;

---

Non, erreur de syntaxe.

Qu'est-ce qui t'empêche de la communiquer ou de la corriger ? ;)

Je relis, je ne vois pas d'erreur de syntaxe. Quel est ton SGBD ?

Il s'agit d'HSQLDB dans LO Base. J'ai testé en remplaçant le GROUP BY 1, 2, 3 par le nom des colonnes mais rien n'y fait (table dupliquée en T_VACATIONS2 pour les tests) :

Pièce jointe 632917

Et en exécutant en SQL direct :

Pièce jointe 632919

Citation:

---

HSQLDB dans LO Base

---

Inconnu au bataillon.

Le seul truc un peu inhabituel est le (cols) IN (SELECT cols), sais-tu si la syntaxe est supportée ? Pour savoir tu peux essayer ces 2 requêtes :

Code:

---

1 2	SELECT (123, 234) IN ((123, 234)); -- 1/TRUE SELECT (123, 234) IN (SELECT ALL 123, 234); -- 1/TRUE

---

Sinon tu peux reformuler la requête proposée précédemment en :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

SELECT ALL VAC_ID, D1_ID, D2_ID, VAC_DATE FROM T_VACATIONS AS t1 INNER JOIN ( SELECT ALL D1_ID, D2_ID, VAC_DATE FROM T_VACATIONS GROUP BY 1, 2, 3 HAVING COUNT(*) > 1 ) AS t2 ON TRUE AND t1.D1_ID = t2.D1_ID AND t1.D2_ID = t2.D2_ID AND t1.VAC_DATE = t2.VAC_DATE ;

---

Je ne sais pas si c'est supporté (je ne comprends d'ailleurs pas ce que signifie ces deux lignes, si ce n'est la numérotation des colonnes).

Ta deuxième requête est fonctionnelle (en mode SQL direct) mais le résultat n'est pas bon : elle n'affiche que la dernière ligne de la table (qui n'est pas doublonnée).

Citation:

---

Envoyé par Nerva

Je ne sais pas si c'est supporté (je ne comprends d'ailleurs pas ce que signifie ces deux lignes, si ce n'est la numérotation des colonnes).

---

Ce sont 2 requêtes qui testent le support de (...) IN (...)

Citation:

---

Ta deuxième requête est fonctionnelle (en mode SQL direct) mais le résultat n'est pas bon : elle n'affiche que la dernière ligne de la table (qui n'est pas doublonnée).

---

Donne un jeu de test.

Voilà un jeu partiel de 1579 lignes (fichier texte zippé) :

Pièce jointe 632956

Plus haut j'ai oublié de préfixer le nom de colonnes sélectionnées, correction :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

SELECT ALL t1.VAC_ID, t1.D1_ID, t1.D2_ID, t1.VAC_DATE FROM T_VACATIONS AS t1 INNER JOIN ( SELECT ALL D1_ID, D2_ID, VAC_DATE FROM T_VACATIONS GROUP BY 1, 2, 3 HAVING COUNT(*) > 1 ) AS t2 ON TRUE AND t1.D1_ID = t2.D1_ID AND t1.D2_ID = t2.D2_ID AND t1.VAC_DATE = t2.VAC_DATE ;

---

J'obtiens les 69 lignes suivantes :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69

227 102073 101024 2022-02-01 228 102073 101024 2022-02-01 229 102017 101033 2022-02-01 230 102018 101031 2022-02-01 231 102093 101045 2022-02-01 232 102104 101022 2022-02-01 233 102017 101033 2022-02-01 234 102018 101031 2022-02-01 235 102093 101045 2022-02-01 236 102104 101022 2022-02-01 368 102003 101050 2022-04-01 379 102021 101063 2022-04-01 396 102046 101068 2022-04-01 397 102047 101021 2022-04-01 423 102078 101063 2022-04-01 444 102103 101063 2022-04-01 449 102111 101046 2022-04-01 461 102124 101057 2022-04-01 464 102128 101037 2022-04-01 466 102130 101003 2022-04-01 467 102131 101050 2022-04-01 469 102133 101039 2022-04-01 473 102139 101064 2022-04-01 474 102141 101040 2022-04-01 476 102143 101066 2022-04-01 493 102169 101061 2022-04-01 497 102021 101063 2022-04-01 498 102046 101068 2022-04-01 499 102047 101021 2022-04-01 500 102078 101063 2022-04-01 501 102103 101063 2022-04-01 502 102124 101057 2022-04-01 503 102128 101037 2022-04-01 504 102130 101003 2022-04-01 505 102131 101050 2022-04-01 506 102133 101039 2022-04-01 507 102139 101064 2022-04-01 508 102143 101066 2022-04-01 509 102162 101051 2022-04-01 510 102169 101061 2022-04-01 511 102021 101063 2022-04-01 512 102047 101021 2022-04-01 513 102078 101063 2022-04-01 514 102103 101063 2022-04-01 515 102124 101057 2022-04-01 516 102128 101037 2022-04-01 517 102130 101003 2022-04-01 518 102131 101050 2022-04-01 519 102133 101039 2022-04-01 520 102139 101064 2022-04-01 521 102141 101040 2022-04-01 522 102143 101066 2022-04-01 523 102162 101051 2022-04-01 524 102169 101061 2022-04-01 525 102021 101063 2022-04-01 526 102047 101021 2022-04-01 527 102111 101046 2022-04-01 528 102124 101057 2022-04-01 529 102131 101050 2022-04-01 530 102133 101039 2022-04-01 531 102143 101066 2022-04-01 532 102162 101051 2022-04-01 533 102169 101061 2022-04-01 534 102162 101051 2022-04-01 535 102003 101050 2022-04-01 1332 102031 101040 2022-11-01 1444 102031 101040 2022-11-01 1486 102031 101040 2022-12-01 1532 102031 101040 2022-12-01

---

Même chose avec la requête proposée initialement.

Ça ne fonctionne pas dans mon système, je n'obtiens là aucun retour. Je ne saurais pas dire d'où ça vient (pas du surnommage en lui-même puisque c'est parfaitement pris en charge, ça doit être quelque chose de plus global qui n'est pas accepté dans ce SGBDR).

Merci encore.

Je ne vois pas trop ce qui pourrait bloquer, la 2nde version est une requête ultra-basique.

Ton SGBD accepte-t-il les CTE ? Les fonctions d'analyse comme "ROW_NUMBER() OVER (...)" ?

Que donnaient les 2 requêtes test de https://www.developpez.net/forums/d2.../#post11914021 ?

La première requête de test sortait uniquement la dernière ligne.

Pour ce qui est des CTE et des fonctions d'analyse, j'ai un peu cherché sur le net et apparemment c'est géré mais la syntaxe ne doit pas être standard. Enfin je ne suis sûr de rien et je n'ai pas creusé puisque je n'ai jamais utilisé ces fonctions. Et il faut tenir compte aussi qu'il y a des différences entre la version standard du SGBDR et celle intégrée dans LO Base (je n'ai jamais trouvé de document qui énonce clairement les différences).

Il y a bien un guide utilisateur mais je ne sais pas dans quelle section chercher pour avoir des réponses précises concernant ces fonctions (le PDF est corrompu) :

https://hsqldb.org/doc/guide

Citation:

---

Envoyé par Nerva

Il ne doit y avoir qu'un seul "couple" D1_ID et D2_ID par VAC_DATE.

---

Attention à ce point, ce n'est pas ce que vous avez codé.
Un seul couple (D1_ID, D2_ID) par VAC_DATE signifie que ceci doit être considéré comme un doublon :

Code:

---

1 2 3 4

D1_ID D2_ID VAC_DATE ----- ----- ---------- 1 2 2023-01-23 1 3 2023-01-23

---

Or, votre requête n'identifie pas ce cas.

L'erreur pouvant venir de la phrase citée, je préfère simplement que vous vérifiez ce point.

Oui, il ne s'agit pas d'un couple mais d'un triplet. Un doublon = 2 fois (ou plus) D1_ID D2_ID VAC_DATE