Create or replace function schlägt fehl - Datentyp "numeric" nicht erlaubt?

[B.Hauser]

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]

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]

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]

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]

Das liegt daran, dass Du mit den "bunten Bildern" mit SQL Naming arbeitest und im Schwarz/Grünen mit System Naming.

[camouflage]

Wenn man doch nur das olle Query400 zu Rate gezogen hätte...

[Fuerchau]

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.

[holgerscherer]

Was hat das Naming mit der Syntax von SQL zu tun außer, dass das Schema/die Lib statt mit "/" mit "." getrennt wird?

Wenn wir schon so beim Diskutieren sind, könnte man ja noch darüber sinnieren, wie man einen SQL-Code auf eine andere Datenbank bekommt. Ich persönlich kriege immer mehr den Vogel, welche unterschiedlichen Schreibweisen sich mit der Zeit etablieren und welche möglich sind. Dem Durchblick förderlich ist das auf Dauer nicht...

Man sollte sich auf jeden Fall nur auf das einlassen, was der iACS beim Ausführen von SQL-Statements unterstützt. Wenn was im STRSQL nicht geht, interessiert das bei der IBM keinen mehr.

[Fuerchau]

Wenn dem nur so wäre. Wie ich oben schon schrieb, erstelle ich einen komplexen SQL via ACS.
Wenn ich dann mit dem Ergebnis (Struktur und Performance) zufrieden bin, kopiere ich den SQL in RDi für eine View-Erstellung.
Und genau dann bekam ich einen Umwandlungsfehler bei einer Definition "Feld decimal(5,0)", da ich das Leerzeichen mal wieder vergessen habe.
Im ACS lief der SQL problemlos.

[B.Hauser]

Und warum kopierst Du das Ganze überhaupt nach RDi?
Views kannst Du direkt mit ACS erstellen und auch die Quelle kann wahlweise als PC-Datei, IFS-Datei oder als klassisches Source-Member gesichert werden!

[Fuerchau]

Das liegt in der verwendeten Quellverwaltung mit Versioning CMOne.
Hierfür müssen die Quellen auf der IBM i vorliegen und werden von CMOne verwaltet.
Also kann ich ACS nicht für die Erstellung sondern nur für's testen verwenden.
Das ist aber immer noch besser als STRSQL;-).

[B.Hauser]

Hierfür müssen die Quellen auf der IBM i vorliegen

Liegt ein klassisches Source-Member nicht auf der IBM i?
Also warum kopieren, anstatt einfach zu sichern?