Eviter les doublons

**hilander** · 09/12/2019, 11h54

Bonjour,

J'ai une requête INSERT INTO ….. SELECT DISTINCT
Cette requête je l'ai mise dans l'initialisation de ma table, mais à chaque fois que j'ouvre ma table cela crée des doublons.
En sachant qu'un même produit X peut être saisie et n'a pas forcément pour les mêmes informations.
J'ai consulté les explications sur internet afin de trouver une solution, mais le problème persiste.
Pourriez-vous me dire comment éviter ces doublons
Merci beaucoup

**Voroltinquo** · 09/12/2019, 12h34

Une requête INSERT c'est pour ajouter des données, pas pour les afficher

**tbc92** · 09/12/2019, 13h41

DISTINCT ne devrait jamais être utilisé.
Dans 99.99% des cas, quand un programmeur débutant utilise DISTINCT, c'est pour masquer un bug.
Mais masquer un bug, ça ne corrrige pas le bug.

A la place de distinct, il faut utiliser GROUP BY.
L'avantage de GROUP BY, c'est que ça oblige le programmeur à comprendre ce qu'il dit.

Ici, je ne suis pas sûr que remplacer DISTINCT par GROUP BY suffise à y voir clair.

**padbrain** · 09/12/2019, 14h21

Bonjour Hilander,

Comme d'habitude, tu ne donnes pas suffisamment de détail...

**hilander** · 09/12/2019, 15h48

Envoyé par Voroltinquo

Une requête INSERT c'est pour ajouter des données, pas pour les afficher

Oui ça j'avais compris, y a-t-il une autre solution

**tatayo** · 09/12/2019, 18h26

Bonjour,
Il ne faut pas confondre le champ table, et la table dans la base de données.
Pour ajouter des données en base (dans un fichier en langage WinDev), il faut effectivement une requête INSERT.
Pour ajouter des donnes dans un champ table, il faut regarder les fonctions Table*.

Ici il faudrait que tu nous expliques ce que tu veux faire exactement: pourquoi ajouter systématiquement des donnes en base dans l'initialisation d'un champ table ?
J'avoue ne pas comprendre la logique.

Tatayo.

**tbc92** · 09/12/2019, 18h46

Envoyé par hilander

Oui ça j'avais compris, y a-t-il une autre solution

Pour qu'il y ait une solution, il faut qu'il y ait un besoin exprimé.
Tu ne présentes pas ton besoin, tu présentes ta façon de solutionner ce besoin.

On devine que tu veux afficher des données dans une fenetre.
On imagine que l'utilisateur pourra modifier ces données.

Et on voit gros comme une maison le bug qui se profile :

* Insert into Fichier 2 select données from fichier 1
* Affichage des données qui sont dans fichier 2
* Modification des données ; sauvegarde dans fichier 2

Puis quand l'utilisateur ouvre à nouveau la fenêtre, il écrase le contenu du fichier 2 en le remplaçant par fichier 1, et il pleure parce que ses modifications ont été écrasées.

**Voroltinquo** · 09/12/2019, 18h50

Maintenant on se méfie:
-Quelle analyse utilises-tu ?
-Quelle est ta requête ?

**hilander** · 09/12/2019, 19h13

Bonsoir,
J'ai une Table 1 dans laquelle il y a des champs table col1, col2, col3 dans lesquels il y a des données différentes A, B, C, ...
J'ai une Table 2 dans laquelle il y a des champs table identiques col1, col2, col3

Ce que je souhaiterais c'est copié les données de la table 1 vers la table 2 car ce sont des données identiques (A, B, C, …) ce qui m'éviteras de les ressaisir au risque de faire des erreurs.
Et à chaque fois que j'ajouterais des données dans la Table 1, elles seront automatiquement copiées dans la Table 2

C'est la raison pour laquelle je m'étais orienté vers une requête INSERT INTO … FROM. Mais le problème avec cette requête c'est que les données sont dupliquées.
Mais en vous lisant, je vois bien que ma piste n'est pas la bonne.

J'espère que mon explication vous apportera plus de précision, je sais bien que j'ai du mal à m'expliquer, mais la logique informatique n'est pas ce que je souhaite faire

Bonne soirée à tous et encore merci pour votre patience

**Voroltinquo** · 09/12/2019, 19h24

Nous sommes fatigués de te dire qu'il n'y a jamais de rubriques identiques dans 2 tables (justement pour éviter de se casser la tête avec la synchro.)
Ces données sont soit dans l'une soit dans l'autre soit, et c'est le cas le plus fréquent dans une troisième.
Nom : screenshot_09-12-2019 19h33_n°01.png
Affichages : 620
Taille : 3,4 Ko

Nom : screenshot_09-12-2019 19h33_n°01.png
Affichages : 620
Taille : 3,4 Ko

Dans le premier cas, on est en face d'une relation très forte ((0,1)-(1,1)), ce qui signifie qu'on ne peut pas créer d'enregistrement dans Table2 avant d'avoir créé un enregistrement dans Table1.
Les données communes sont alors récupérées via FK_Table1

**hilander** · 09/12/2019, 20h46

Il y a une chose que j'ai un peu de mal à comprendre, mais c'est vous les experts.
Pourquoi avec Excel, Access, MySQL ou d'autres ce que je souhaite faire est possible en lisant divers forum, sachant que WinDev est bien plus performant.
Mais bon ce n'est qu'un simple commentaire d'un débutant.

**Yusep** · 10/12/2019, 01h11

Bien sur que c'est possible.
Mais ce n'est pas le mieux.
Lisez bien les conseils.

**Voroltinquo** · 10/12/2019, 02h39

On peut aussi tenter de construire un immeuble sur un terrain marécageux sans fondations correctes.
Par ailleurs, EXCEL N'EST PAS UN SGBD ce qui est obligatoire dans excel est prohibé dans un SGBD bien construit.

**tbc92** · 10/12/2019, 09h48

Comparer Excel et Windev, ou comparer MySQL et Windev, c'est comme comparer un vélo et une perceuse.

**hilander** · 10/12/2019, 12h06

Bonjour,

En parcourant ce forum, j'ai trouvé une chose qui me conviendrait, solution donnée par Tatayo.
Est_ce possible de l'adapter à mon projet pour n'afficher les données sans doublons, je ne sais pas.

Pièce jointe 523199

Merci

**Voroltinquo** · 10/12/2019, 20h24

S'il y a des doublons non souhaités en affichage, c'est que les même données existent dans les tables concernées. Le problème ne vient pas de l'affichage des données mais de l’enregistrement de ces données (un contrôle qui n'a pas été fait avant le HEnregistre/HModifie/HAjoute par exemple.) Comme le précisait tbc92, le DISTINCT dans ce cas n'est qu'un cache misère. Le même problème va survenir ultérieurement.