Hallo Jörg, das sind deine Daten und deshalb solltest Du darüber auch den Überblick haben. Meine Fernhypothese wäre: In TableK sind zu einer KundenId mehrere Sätze mit unterschiedlicher Kundennummer und/oder Straße. Deswegen liefert `DISTINCT id, nummer, straße` mehr Rows als `DISTINCT id`. Die Query ~~~SQL SELECT xy.Kunden_ID, COUNT(*) FROM (SELECT DISTINCT Kunden_ID, Kundennummer, straße FROM tableK) xy GROUP BY xy.Kunden_ID HAVING COUNT(*) > 1 ~~~ sollte Dir die IDs liefern, für die das der Fall ist. Was mich zu der Frage führt: Warum Kunden_ID **und** Kundennummer? Reicht die Kundennummer nicht als eindeutiger und unveränderlicher Key? Hast Du eine Vorgabe, dass fachliche Attribute keine technischen Keys sein dürfen? Es ist jetzt sicherlich zu spät, um das zu ändern, aber neugierig bin ich schon. _Rolf_ -- sumpsi - posui - obstruxi

Hallo Jörg, das sind deine Daten und deshalb solltest Du darüber auch den Überblick haben. Meine Fernhypothese wäre: In TableK sind zu einer KundenId mehrere Sätze mit unterschiedlicher Kundennummer und/oder Straße. Deswegen liefert `DISTINCT id, nummer, straße` mehr Rows als `DISTINCT id` ~~~SQL SELECT xy.Kunden_ID, COUNT(*) FROM (SELECT DISTINCT Kunden_ID, Kundennummer, straße FROM tableK) xy GROUP BY xy.Kunden_ID HAVING COUNT(*) > 1 ~~~ sollte Dir die IDs liefern, für die das der Fall ist. Was mich zu der Frage führt: Warum Kunden_ID **und** Kundennummer? Reicht die Kundennummer nicht als eindeutiger und unveränderlicher Key? Hast Du eine Vorgabe, dass fachliche Attribute keine technischen Keys sein dürfen? Es ist jetzt sicherlich zu spät, um das zu ändern, aber neugierig bin ich schon. _Rolf_ -- sumpsi - posui - obstruxi