PDA

View Full Version : Create or replace function schlägt fehl - Datentyp "numeric" nicht erlaubt?



Seiten : [1] 2 3

RobertSchneider
17-07-20, 17:00
Moinsen,

beim RUNSQLSTM bekomme ich Stelle 22 auf Zeile 3 um die Ohren gehauen.
Ich seh' den Fehler nicht. Oder ist "numeric" nicht (mehr) erlaubt? - Eigentlich hat das statement doch schon mal funktioniert...

Kann jemand helfen? Vielen Dank!
Robert


Satz *...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 FLGNR. Letzte Änderung

1 create or replace function RTVFAXSTS
2 (
3 INTNBR numeric(7,0),
4 XCHABT char(10),
5 XCHAVG decimal(3,0),
6 XCHBOX char(1),
7 XCHBST char(2),
8 XCHCCC char(1),
9 XCHGFN decimal(7,0),
10 XCHKZ2 char(1),
11 XCHKZ8 char(1),
12 XCHMX2 char(1),
13 XCHPTY char(1),
14 XCHRST numeric(7,0),
15 XCHSDT numeric(8,0),
16 XCHSPY char(1),
17 XCHSTM numeric(4,0),
18 XCHSTS char(1),
19 XCHUSR char(10)
20 )
21 returns char(19)
22 language rpgle
23 deterministic
24 no sql
25 external name FAXSTSUDF(RTVFAXSTS)
26 parameter style general
27 program type sub
28

* * * * * E N D E D E R Q U E L L E * * * * *
5770SS1 V7R3M0 160422 SQL-Anweisungen ausführen RTVFAXSTS 17.07.20 17:49:20 PAGE 3

Satz *...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 FLGNR. Letzte Änderung

MSG ID WTK SATZ TEXT
SQL0104 30 3 Position 22 Token ( ungültig. Gültige Token: ) ,.



Nachrichtenzusammenfassung
Gesamt Info Warnung Fehler Wertigk. Beendigung
1 0 0 0 1 0


Fehler der Wertigkeitsstufe 30 in Quelle gefunden.

* * * * * E N D E D E R L I S T E * * * * *

B.Hauser
17-07-20, 17:25
Ich nehme mal an, dass Du mit Dezimal-Trennzeichen Komma arbeitest.
Dann mach mal bei allen Numerischen Definitionen nach dem Komma ein Blank.
7,0 ist wahrscheinlich als eine einzige Zahl und nicht als 2 Zahlen (7 und 0) definiert.
(Man kann eigentlich nie zuviele Blanks, sondern höchstens zu wenig Blanks haben)

Wenn man mit Dezimal-Trennzeichen Punkt arbeitet passiert das nicht, da kann eindeutig unterschieden werden!

Birgitta

Fuerchau
18-07-20, 16:42
Da SQL inzwischen Punkt und Komma erlaubt, sollte man sich bei Parametertrennung grundsätzlich ", " verwenden. Das ist auch leichter lesbar.

B.Hauser
18-07-20, 17:54
Da SQL inzwischen Punkt und Komma erlaubt, sollte man sich bei Parametertrennung grundsätzlich ", " verwenden. Das ist auch leichter lesbar.

Hä?!
SQL hat schon immer Dezimal-Punkt und Dezimal-Komma für Zahlen erlaubt.
Welches Trennzeichen verwendet wird, hängt von der Einstellung im Job oder der Connection ab.

Parameter wurden schon immer durch ein Komma getrennt! Versuch' es doch mal mit einem Punkt!

SQL erlaubt bei der Trennung von Bibliothek und Objekt unter System-Naming seit Release 7.1 TR 5 sowohl den Slash als auch den Punkt (aber das ist etwas völlig anderes und wurde an dieser Stelle auch nicht gefragt!)

Birgitta

Fuerchau
19-07-20, 22:45
Dass du mich immer gerne Missverstehst.
Noch mal zur Klarstellung.
Inzwischen akzeptiert SQL Dezimalpunkt oder -komma unabhängig von der Einstellung. Nur bei Komma kann SQL 4,5 dann nicht von Parameter oder Zahl unterscheiden.

RobertSchneider
20-07-20, 07:31
Jo, mit einem Leerschritt nach dem Komma hat's funktioniert :-)

create or replace function RTVFAXSTS
(
INTNBR numeric(7, 0),
XCHABT char(10),
XCHAVG decimal(3, 0),
XCHBOX char(1),
XCHBST char(2),
XCHCCC char(1),
XCHGFN decimal(7, 0),
XCHKZ2 char(1),
XCHKZ8 char(1),
XCHMX2 char(1),
XCHPTY char(1),
XCHRST numeric(7, 0),
XCHSDT numeric(8, 0),
XCHSPY char(1),
XCHSTM numeric(4, 0),
XCHSTS char(1),
XCHUSR char(10)
)
returns char(19)
language rpgle
deterministic
no sql
external name FAXSTSUDF(RTVFAXSTS)
parameter style general
program type sub

Den Punkt als Trennzeichen habe ich auch probiert, das ging nicht.

Komisch, ich hatte gedacht, dass das mit dem Leerschritt nach dem Komma bei V7R1 noch erforderlich war, später dann aber nicht mehr. Habe mich offensichtlich geirrt, ich arbeite hier auf einer Maschine mit V7R3, TR4.

Besten Dank für Eure Unterstützung!!

Fuerchau
20-07-20, 08:24
Da scheint es auch gewisse Unterschiede zu geben.
Bei der Ausführung via SQL-Script über ACS (Java, QZDASOINIT) habe ich kein Leerzeichen benötigt.
Nachdem ich dann den SQL in eine SRCPF kopiert hatte um eine View zu erstellen wurde das entsprechend angemeckert.
Also ein uneinheitliches Verhalten.

Außerdem habe ich auch nie behauptet, dass ein Punkt also Parametertrennung erlaubt wäre.

B.Hauser
20-07-20, 09:03
Das liegt daran, dass Du mit den "bunten Bildern" mit SQL Naming arbeitest und im Schwarz/Grünen mit System Naming.

camouflage
20-07-20, 09:06
Wenn man doch nur das olle Query400 zu Rate gezogen hätte...

Fuerchau
20-07-20, 10:40
Was hat das Naming mit der Syntax von SQL zu tun außer, dass das Schema/die Lib statt mit "/" mit "." getrennt wird?
Außerdem muss ich im ACS mit Naming *SYS arbeiten, da die spätere View auch in einer entsprechenden Umgebung läuft. Schließlich kann man das in den Connection-Eigenschaften einstellen.

Auch hier gibts noch eine Erweiterung:
Auch bei Naming *SYS ist nun das Format "SCHEMA.TABLE" erlaubt.