Navigator SQL empfindlicher als STRSQL, wo ist der Fehler

[Robi]

dieses sql bringt im STRSQL ein ergebnis und im
Navigator den Fehler

 select substr(MR1REFK, 1, 3) as was1,                           
          substr(MR1REFK, 5, 11) as was2,                          
          mr1dtlg, substr(MR1REFK, 5, 15) as was3,                 
          MR1USER, MR1DIFF-MR1DIFE as std,                         
          (select dec(max(substr(nttext, 1, 11)), 11, 2) from pntm1
           where nttabl = 'PWE' and nttabw = mr1user and           
                 ntadat <= mr1dtlg group by nttabw) as stds        
   FROM  PPTL/MR1M1                                                
   WHERE MR1DTLG >= 20160101  AND MR1DTLG <= 20161031

SQL-Status:01565 Vendorecode 420 
Zeichen in cast-Argument ungültig

Wie kann ich die Ursache suchen?
Es gibt zu JEDEM MR1USER mind. 1 PNTM1 NTTABW Satz mit 20010101 als datum
In NTTEXT steht
00000015,06 oder
00000017,33

Wie gesagt, STRSQL geht, Navigator nicht

alle Ideen wilkommen

[Robi]

Bin etwas weiter ...
select dec(substr(nttext, 1, 11)), 11, 2) from pntm1
where nttabl = 'PWE' and nttabw <> ' '

bringt STRSQL ein Ergebnis, im Navigator nur +++++++

select dec(substr(replace(nttext, ',', '.'), 1, 11)), 11, 2) from pntm1
where nttabl = 'PWE' and nttabw <> ' '
genau umgekehrt

Im Navigator erwartet er also ein dezimal-Punkt, im STRSQL ein Komma

Habe den DEC nun so
dec(substr(nttext, 1, 11), 11, 2, ',')

das ging

Robi

Danke

[Fuerchau]

Ich vermute mal, in den Verbindungseigenschaften im Navigator wird als Dezimaltrenner ein Punkt definiert. Wenn dann in den Daten ein Komma vorkommt, knallt es halt.
Prüfe die Dezimaleinstellungen in der Verbindung.

Anmerkung:
In einem skalaren Subselect macht ein Group By keinen Sinn, da du per direktem Bezug zu deinem übergeordneten Satz mit dem NTTABW den Maxwert erhälst.

[B.Hauser]

Du kannst sowohl beim IBM i Navigator als auch beim STRSQL das Dezimal-Trennzeichen einstellen.
Beim STRSQL ist das Trennzeichen per Default ein Komma (vermutlich System-Wert) im IBM i Navigator standardmäßig ein Punkt.

Einstellen im IBM i Navigator:
Connection/Verbindung --> JDBC Einstellungen --> Format --> Decimal Separator/Trennzeichen

... übrigens wenn Du Dezimal-Trennzeichen Komma verwendest, musst Du immer ein Leerzeichen nach dem Komma-Separator innerhalb einer Funktion oder eines SQL-Statements angeben.

Birgitta

[Fuerchau]

Aber nur bei Zahlen...

[B.Hauser]

Aber nur bei Zahlen...

Warum?
Bei Trennzeichen kann man eigentlich nie zuviel Blanks angegeben, nur zuwenig!

[Fuerchau]

Mir ging es ja nur um das "muss".
Bei Zahlen muss man, bei allem anderen kann man.
Wichtig ist ja nur, dass man das Blank nach der Zahl angeben muss.

[BenderD]

Warum?
Bei Trennzeichen kann man eigentlich nie zuviel Blanks angegeben, nur zuwenig!

... bei ordentlichen Programmiersprachen nicht, bei free RPG schon, mach mal ein Semikolon am Anfang der nächsten Zeile, da kriegt der Compiler die Vogelgrippe.

D*B

[Fuerchau]

Nun ja, wenn die vorherige Zeile nicht mit Semikolon aufhört, funktionierts.
Das mache ich gerne bei längeren SQL's und Prozeduraufrufen.
Nur "leere" Zeilen, also 2 auf einander folgende Semikolons, mag der Compiler nicht.

[BenderD]

Nun ja, wenn die vorherige Zeile nicht mit Semikolon aufhört, funktionierts.
Das mache ich gerne bei längeren SQL's und Prozeduraufrufen.
Nur "leere" Zeilen, also 2 auf einander folgende Semikolons, mag der Compiler nicht.

... das Problem fängt an, wenn hinter dem Semikolon in der selben Zeile was anderes wie Kommentar kommt...

[camouflage]

... bei ordentlichen Programmiersprachen nicht, bei free RPG schon, mach mal ein Semikolon am Anfang der nächsten Zeile, da kriegt der Compiler die Vogelgrippe.
D*B

Grundsätzlich richtig, aber bevor die Vogelgrippe ausbricht, hustet dir RDi noch was.

[B.Hauser]

... bei ordentlichen Programmiersprachen nicht, bei free RPG schon, mach mal ein Semikolon am Anfang der nächsten Zeile, da kriegt der Compiler die Vogelgrippe.
D*B

Was soll denn schon wieder der Seitenhieb auf RPG in einem Thread in dem es um SQL (noch nicht einmal embedded SQL!) ging?