Unterabfrage

[Christian Marquardt]

Wo steht da in der Fehlermeldung was von Belegnummer?

Was mich wundert, In der Fehlermeldung steht eine m.BELEGNUMMER die nach Auswahl gar nicht stehen dürfte.

Sofern deine Informationen zutreffend sind und der Subselect (
(select (CASE WHEN s.kommnr like '1%' THEN CAST(s.kommnr AS INTEGER) ELSE -1 END) as id , sum(s.gesamt) as sumup from belegpos s group by s.kommnr) n) funktioniert, kann doch nur noch cast(m.belegnr as integer) das Problem sein )

[ronin269]

Es sollte doch kein Ausdruck ein String sein, da Beide explizit umgewandelt werden.

[Christian Marquardt]

Wenn m.belegnr ein String ist, kann dort der Fehler sein

[ronin269]

Es stimmt, wenn ich Cast(m.Belegnr as Integer) weg lasse, kommt die Meldung:

SQL-Fehler in Schritt 1:
TA_SQL.SelectQuery: Arithmetic overflow or division by zero has occurred.Arithmetic exception, numeric overflow, or string truncation.
String right truncation.

Bei ersetzen mit Cast(m.belegnr as Char)

kommt

SQL-Fehler in Schritt 1:
TA_SQL.SelectQuery: Overflow occurred during data type conversion.Conversion error from string "135658".

Die Nummer 135658 ist zumindest eine die Korrekt ist

[Christian Marquardt]

Und da ist kein Leerzeichen oder Schmierzeichen drin....

sinnvoll ist eine Prüfung der Spalte der Tabelle, um erstmal zu sehen was drin ist.

Erstmal eine Abfrage machen, die alle Datensätze ausgibt, deren Spalte belegnr nicht in einen Integer gecastet werden kann

[ronin269]

Ich habe ein Lösung (für mich) gefunden.

Ich habe in der programmeigenen UDF eine StrtoInt gefunden, welche nur Zahlen zulässt. So klappt meine Abfrage.

Danke für Eure Hilfe!

[ronin269]

Hallo noch einmal,

ich habe noch ein Problem festgestellt.

Ich erhalte nur Ergebnisse, bei welchen in der join Anweisung ein Wert ist. Ist der Wert Null, wird die Zeile vom äußeren Select nicht dargestellt.

select m.Belegnummer,  m.Name , m.DATUM, m.WERT, n.sumup                                                                    
from Beleg m    
 join (select    strtoint(s.kommnr) as id , sum(s.gesamt) as sumup from belegpos s group by s.kommnr) n
on cast(m.belegnr as integer)  =  n.id  where DATUM between '01.05.2019' and '31.05.2019'    group by m.BELEGNUMMER, m.Name ,  m.WERT , m.DATUM, n.sumup

Nochmals am Beispiel:

Es erscheinen bei oben genannter Abfrage nur Zeilen, welche einen Wert bei Summe haben, die durchgestrichen Zeilen sind Ergebnismenge der m Abfrage und liegen im Bereich Datum between.

m.Belegnummer	m.Name	m.Datum	m.Wert	n.Sumup
135337	Meier	14.05.2019	3000	500
135338	Karl	16.05.2019	2500	0
135339	Schmidt	16.05.2019	3500	500

(mittlere Zeile sollte durchgestrichen sein)

[Christian Marquardt]

Dann einen full outer join wählen...den MySQL wohl nicht kann

https://stackoverflow.com/questions/...-join-in-mysql

[ronin269]

Bin auch in Firebird unterwegs. Dort scheint es mit left outer join zu klappen. Wenn es auch sehr lange dauert.

[defo2]

Wenn es auch sehr lange dauert.

Könnte am Group by am Ende dieses Statements liegen, in meinen Augen völlig unnötig und macht der DB doppelte Arbeit.
Vielleicht solltest Du Dich mal etwas mit SQL Grundlagen beschäftigen.

select m.Belegnummer, m.Name , m.DATUM, m.WERT, n.sumup
from Beleg m
join (select strtoint(s.kommnr) as id , sum(s.gesamt) as sumup from belegpos s group by s.kommnr) n
on cast(m.belegnr as integer) = n.id where DATUM between '01.05.2019' and '31.05.2019' group by m.BELEGNUMMER, m.Name , m.WERT , m.DATUM, n.sumup

Bin auch in Firebird unterwegs. Dort scheint es mit left outer join zu klappen.

"Scheint" ist bei beliebig unübersichtlichen Datenmengen vielleicht nicht das richtige Vorgehen. Du kannst mit SQL alles prüfen, plausibilisieren, absichern, was in Deinen Daten drin steht (oder nicht).
Es ist z.b. dringend zu empfehlen, die fragwürdige Spalte auf ihren Inhalt zu untersuchen! Denn welchen Sinn machen die Summen, wenn bei jeder Belegnummer ein paar Werte nicht mitgerechnet werden? Ein vollständige Bereinigung würde das LEFT mglw. obsolet machen, das gecaste könnte vielleicht raus. Alles würde schneller. (bei dem derzeitigen Statement hilft selbst ein existierender Index nicht)

Vielleicht kann man sogar die Spaltentypen angleichen, aber das sollte man nur machen, wenn man weiß, was man tut.

[Christian Marquardt]

Hatte bereit mit #20 auf die Untersuchung der Spalte hingewiesen.
Nicht nur untersuchen, Fehler feststellen und korrigieren

Denn welchen Sinn machen die Summen, wenn bei jeder Belegnummer ein paar Werte nicht mitgerechnet werden?

Joo, sonst sind die Daten murks

[ronin269]

Alles Klar! Danke für Eure Hinweise und Hilfe!

I