View Full Version : Listagg fügt Zeichen dazu
Moin zusammen
Feldgrößen:
xxkey1 7,0
xxsunr 7,0
xxsun2 1,0
xxmk 3,0
xxmst 3,0
name 24A
ich habe hier ein
select substr(listagg(digits(xxKey1), ', ' on overflow truncate), 1, 53) as xxkeys,
substr(listagg(digits(dec(xxsunr*10+xxsun2, 8, 0))
concat digits(xxmk) concat digits(xxmst)
concat (select substr(name, 1, 18)
from FILE2
where sunr=xxsunr and sun2=xxsun2), ''
on overflow truncate), 1, 203) as DATEN,
count(*) as anzahl
from FILE1 where ...
im STRSQL
ist xxkeys
1234567, 8901234, 5678901, ....
im embeddet sql ist das
1234567,08901234,05678901, .... Immer eine 0 statt ein Blank
Daten hat in dem Abschnitt der den Namen beinhaltet
STRSQL
im ersten Namen
ABCD11111111111
alle anderen
ABCD ABCD ABCD
und im embeddet SQL
ABCD111111111111 und ABCD00000000000 ABCD00000000000 usw.
Fehler im meiner Syntax?
Oder im SQL
Es geht um eine Schnittstelle, die Daten hole ich mittlerweile native mit lesen in Schleife.
Das war halt eine einfache Umsetzung mit dem Listagg
Eine Erklärung habe ich nicht! Vermutlich kommt er durch die Numerischen Felder ins Schleudern.
Wenn anstatt eines *BLANKS eine Null (0) eingefügt wird, sieht das wie ein Bug aus.
Ich würde mal bei der IBM nachfragen.
Mit STRSQL würde ich das nicht vergleichen wollen. Hier wäre eher die Verwendung von SQL-Script (via ACS) zu verwenden um vergleichbare Ergebnisse zu embedded zu erhalten.
Ggf. ist zu prüfen, ob "substr(name, 1, 18)" ein Char-Ergebnis hat und ggf. noch mit "trim(...)" von Leerzeichen am Ende entfernt werden muss, was eben zusätzliche Leerzeichen erklären könnte.
Auch verstehe ich deine Ergebnisdarstellung ABCD111111111 nicht, da der Name im Listagg ja erst am Ende angefügt wird.
Im Ergebnis müsste also eine 14-stellige Zahl (8+2*3) von einem 18-stelligen Namen (substr) gefolgt sein.
Moin,
Vorab: Es scheint ein 'Speicherfehler' zu sein.
Das Ergebnis ist immer anders bei gleichen abgefragten Werten.
Heute Ist XXKEY im embeddet richtig und in DATEN ist nur der 2. Name mit 111111 aufgefüllt.
@Birgitta : das habe ich befürchtet. Leider als Externer für einen Konzern mit outgesourster Hardware so einfach wie im Lotto zu gewinnen ...
@Baldur
Trim und Trim mit concat ' ' und substr drumherum habe ich alles versucht, das funktioniert nicht
Der DATEN String sieht so aus: (diesmal alle Stellen ausgezählt)
12345678001001abcBBBBBBBBBBBBBBB12345778001001abc1 1111111111111177745678002123abc000000000000000
Die BBB sind Leerzeichen
Die Darstellung sieht zumindest zu deinem LIST_AGG passend aus, da ohne Trennzeichen.
12345678001001 = 14 stellig
abcBBBBBBBBBBBBBBB = 18 stellig
Bei "abc1111..." und "abc0000...." stellt sich die Frage, was denn in "name" wirklich drinsteht um von einem Fehler auszugehen.
Kannst du dir denn die Rohdaten, also nur list_agg, mit den concats native ansehen?
Na ja, das ist schon so wie ich schrieb
(wir haben in den Testumgebungen mannipulierten Daten.)
einer der Testkunden heist mit Nachnamen abc (dsgvo lässt grüßen)
und im xxKEY habe ich beim 3. Aufruf nun auch wieder
12345678,012345678,012345678 anstatt
12345678, 12345678, 12345678
Dann bleibts wohl bei der Meldung an die IBM.
@Birgitta : das habe ich befürchtet. Leider als Externer für einen Konzern mit outgesourster Hardware so einfach wie im Lotto zu gewinnen ...
Versteh' ich, geht mir ähnlich! Da hilft auch mein direkter Draht ins Lab in Rochester nicht. Von dort bekomme ich höchstens die Bestätigung, dass es sich um einen Bug handelt. ... melden muss ich den dann "irgendwie" selber.
Vielleicht heißt es auch, den List_agg zu überlisten.
Versuche mal, den "digists .... concat ...." in einen char(digits.... concat ....) zu casten.
Alternativ auch als cast(digits .... as char(32)) versuchen.
Ggf. passt nur was in der Operatorfolge nicht.
Auch ein
digts(decimal( (( xxsunr*10+xxsun2 ) * 1000 + xxmk) * 1000 + xxmst, 14, 0)) concat (select ...)
Statt des operators concat gibts auch die Funktion concat(a, b), die dann geschachtelt werden muss.
Vielleicht stört auch die unnötige Multiplikation
digits(xxsunr) concat digits(xxsun2)
so dass du den cast auf dec() nicht benötigst.
also das 'Beste' Ergebnis habe ich nun mit dem
digits(xxsunr) concat digits(xxsun2) ...
anstatt
digits(dec(xxsunr*10+xxsun2, 8, 0)) bekommen
aber leider ist das nich wirklich aussage kräftig.
Das Ergebnis ist jetzt im embeddet immer noch in einem 'Namen' falsch.
Bei mehreren aufrufen mit verschiedenen selektionen
Aber es war ja vorher auch mal mehr mal weniger falsch.
Also kann ich nicht mit Sicherheit bestätigen das es 'besser' ist.
Falsch ist falsch, ob ein bisschen oder komplett.
mal sehen ob ich eine Meldung an IBM raus bekomme.
Vielen Dank Euch