Fehler bei Left Join

[Ykcim]

Hallo Zusammen,

ich habe eine Query über mehrere Tabelle mit Left Join. Eigentlich klappt auch alles. Allerdings ist jetzt nach ein paar Wochen aufgefallen, dass zwei Werte, die summiert werden, falsch sind.

Delphi-Quellcode:

SELECT    a.zynrefkl AS 'Artikelnummer', 
         a.afg_oms1 AS 'Artikelbezeichnung 1', 
         concat('VPE:',a.per__chk,' Stück') AS 'Artikelbezeichnung 2',
         '' AS 'Artikelbezeichnung 3', 
         '' AS 'Artikelbezeichnung 4',
         '' AS 'Artikelbezeichnung 5',
         '' AS 'Artikelbezeichnung 6',
         b.in__vrrd AS 'Bestand',
         a.per__chk AS 'Abgreifmenge',
         a.minstock AS 'Mindestbestand',
         CASE WHEN b.in__vrrd < a.minstock then 'Mindestmenge unterschritten' ELSE '' END AS 'Bestandskommentar',
         '' AS 'Kommentar', 
         COALESCE(SUM(c.b_aantal),0) AS 'Rückstand',
         COALESCE(SUM(d.aant_uit), 0) AS 'Gesamtverbrauch'
FROM afgart__ a 
LEFT JOIN afgant__ b ON b.afg__ref = a.afg__ref 
LEFT JOIN bstlyn__ c ON c.afg__ref = a.afg__ref AND c.levv_dat<GETDATE() AND c.lbn__ref = '' 
LEFT JOIN hisafg__ d ON d.afg__ref = a.afg__ref 
LEFT JOIN gegdet__ e on e.det__ref = a.afg__ref AND e.vrg__ref = '000002' and tabname_ = 'afgart__'
WHERE a.kla__rpn = 'MEYLE'
AND   a.zynrefkl <> ''
AND   (e.antw_txt <> '1' or e.antw_txt is NULL) 
AND c.zynrefkl='108470001'
GROUP BY a.zynrefkl, a.afg_oms1, b.in__vrrd, a.per__chk, a.minstock
order by a.zynrefkl

Das Problem tritt durch die Zeile

Delphi-Quellcode:

LEFT JOIN hisafg__ d ON d.afg__ref = a.afg__ref

Ohne die Tabelle d wird der Rückstand (Tabelle C) korrekt berechnet. Aber mit der Tabelle D kommt eine viel zu hohe Summe für den Rückstand raus und auch der Gesamtverbrauch ist viel zu hoch.

Sieht jemand, was ich falsch mache?

Vielen Dank
Patrick

[DeddyH]

Bist Du Dir sicher, dass ein LEFT (OUTER) JOIN hier die richtige Wahl ist? Was kommt denn bei einem INNER JOIN heraus?

[Papaschlumpf73]

Wenn Tabelle hisafg__ d hier mehrere Treffer für einen Datensatz aus Tabelle a liefert (d.afg__ref = a.afg__ref) werden auch für alle anderen Tabellen so viele Datensätze wie Treffer in d angezeigt. Also wenn d 3 Treffer für einen Datensatz aus a hat, wird auch der eine Datensatz aus a, b, c usw. 3 mal angezeigt. Somit können Berechnungsergebnisse komplett aus dem Ruder geraten.

[Ykcim]

Mit INNER Join habe ich leider das gleiche Ergebnis bekommen...

Ich versuche es gerade so zu lösen.

Delphi-Quellcode:

SELECT    a.zynrefkl AS 'Artikelnummer', 
         a.afg_oms1 AS 'Artikelbezeichnung 1', 
         concat('VPE:',a.per__chk,' Stück') AS 'Artikelbezeichnung 2',
         '' AS 'Artikelbezeichnung 3', 
         '' AS 'Artikelbezeichnung 4',
         '' AS 'Artikelbezeichnung 5',
         '' AS 'Artikelbezeichnung 6',
         b.in__vrrd AS 'Bestand',
         a.per__chk AS 'Abgreifmenge',
         a.minstock AS 'Mindestbestand',
         CASE WHEN b.in__vrrd < a.minstock then 'Mindestmenge unterschritten' ELSE '' END AS 'Bestandskommentar',
         '' AS 'Kommentar', 
      (SELECT COALESCE(SUM(c.b_aantal),0) FROM bstlyn__ c WHERE c.afg__ref=a.afg__ref 
                                                          AND c.levv_dat<GETDATE() 
                                                          AND c.lbn__ref = '') AS 'Rückstand',
      (SELECT COALESCE(SUM(d.aant_uit),0) FROM hisafg__ d WHERE d.afg__ref=a.afg__ref) AS 'Gesamtverbrauch'
FROM afgart__ as a 
LEFT JOIN afgant__ b ON b.afg__ref = a.afg__ref 
LEFT JOIN gegdet__ e on e.det__ref = a.afg__ref and vrg__ref = '000002' and tabname_ = 'afgart__'
WHERE a.kla__rpn = 'MEYLE'
AND   (e.antw_txt <> '1' or e.antw_txt is NULL) 
AND   a.zynrefkl <> ''
AND a.zynrefkl='108470001'
GROUP BY a.zynrefkl, a.afg__ref, a.afg_oms1, b.in__vrrd, a.per__chk, a.minstock 
order by a.zynrefkl

Das klappt zwar in HeidiSQL, aber leider zickt mein Programm damit rum...
Irgendwie stelle ich mich gerade ziemlich doof an...

[Ykcim]

@PapaSchlumpf: Es gibt mehrere Datensätze in der Tabelle. Aber werden die nicht durch sie Summierung gruppiert?

[Uwe Raabe]

Lass mal die SUM und GROUP BY Anweisungen weg und analysiere die tatsächlich zurückgegebenen Datensätze.

[Delphi.Narium]

Was willst Du damit erreichen?

SQL-Code:

COALESCE(SUM(d.aant_uit),0)

Soll hier 0 geliefert werden, wenn die Summe aller d.aant_uit = Null ist oder soll hier, wenn d.aant_uit = null ist, bei der Summenbildung anstellte von Null 0 genommen werden?

Bei mir sähe es jedenfalls so aus:

SQL-Code:

SUM(COALESCE(d.aant_uit,0))

Je nach Datenbank kann es (soweit ich mich erinnere) passieren, dass die Summe mehrere Zahlen = null ist, wenn mindestens eine Zahl = Null ist.
Quasi sowas:

SQL-Code:

SUM(1 + 1 + 1) = 3
SUM(1 + Null + 1) = Null

Prüfe bitte mal nach, wie sich MSSql in einer derartigen Situation verhält.

[Papaschlumpf73]

Zitat:

Zitat von Uwe Raabe (Beitrag 1494694)

Lass mal die SUM und GROUP BY Anweisungen weg und analysiere die tatsächlich zurückgegebenen Datensätze.

Das ist eine gute Idee. Du wirst sehen, dass die Datensätze doppelt und dreifach sind. Und SUM() rechnet die dann auch doppelt und dreifach zusammen. GROUP BY bezieht sich nur auf die Datenfelder, die nicht summiert werden.

[Ykcim]

Also es ist tatsächlich so, dass ich dann jeden Datensatz 4 mal bekomme...
Kann ich beim LEFT JOIN irgendwie gruppieren?

Ich habe gerade bemerkt, dass nur die Kombination aus

Delphi-Quellcode:

LEFT JOIN bstlyn__ c ON c.afg__ref = a.afg__ref AND c.levv_dat<GETDATE() AND c.lbn__ref = ''

und

Delphi-Quellcode:

Left JOIN hisafg__ d ON d.afg__ref = a.afg__ref

zu Fehlern führt.

Egal welches ich entferne, das andere wird dann korrekt berechnet...

[Blup]

In #4 warst du schon auf dem richtigen Weg.
Allerdings wurde dort plötzlich die Bedingung verändert:

Code:

AND a.zynrefkl <> ''
AND (e.antw_txt <> '1' or e.antw_txt is NULL)
AND c.zynrefkl='108470001'

Code:

AND (e.antw_txt <> '1' or e.antw_txt is NULL)
AND a.zynrefkl <> ''
AND a.zynrefkl='108470001'

"a.zynrefkl='108470001'" ist falsch.
Die Bedingung "c.zynrefkl='108470001'" gehört in die Abfrage von c.
Zumindest wenn das orginale SQL richtig war.