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

[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?

[Fuerchau]

Das müsstest du mir näher erklären:
Ich starte via 5250-Sitzung=>Aktion=>SQL-Script ausführen.
Dann öffne/erstelle ich eine Textdatei "xxx.sql" auf meinem Client.
Hier probiere ich den SQL via "Select ...." aus, bis er funktioniert.
Nun lege ich ein Member in einer SRC-PF QSQLSRC via RDi an und erfasse den Rahmen mit "Create or replace MyView as ...; Label on ..." und kopiere den Select aus dem SQL-Script in den Create-Befehl.
Anschließend lasse ich CMOne die View-Erstellung übernehmen, die via RUNSQLSTM durchgeführt wird.
CMOne ergänzt i.Ü. den SQL um spezifische Lib-Angaben.

Quellen dürfen beim Kunden derzeit nicht im IFS liegen.

Ich wüsste nun nicht, wie ich dem SQL-Editor beibringen kann, eine SRC-PF zu bearbeiten.
Zusätzlich müsste ich die View immer erst erstellen (da der Create ja in der Quelle enthalten ist) und via 2. Sitzung mit einem "Select * " abzufragen.

Da finde ich nun meinen Weg schneller und effektiver.

[malzusrex]

Hallo Baldur,

das bietet der ACS doch beim Speichern mit an.


Gruß
Ronald