View Full Version : SQL und Displayfile
SQL-Namen können max. (ich glaube) 120 Stellen umfassen, DDS-ALIAS aber nur 30 Stellen.
Das wird wohl der Grund sein.
30 Stellen vor V5R4, ab V5R4 128 Stellen
Birgitta
30 Stellen vor V5R4, ab V5R4 128 Stellen
Birgitta
wir haben V5R4 dann sollte es doch mit mehr als 30 Stellen gehen, tut es aber nicht, kann man das Verhalten nicht abstellen irgendwie? Ich brauche das blöde Alias nicht.
andreaspr@aon.at
12-01-10, 08:35
Versuch mal folgends:
CREATE TABLE Test
(verladedokumentation_kat_id For VDKID bigint)
ich hab das mal probiert, aber das problem bleibt das gleiche
60 A VEKAT R O 5 4REFFLD(TESTXXX/VEKAT TESTLIB/TESTXX-
* CPD7534-.
* CPD7616-*
70 A X)
ID Bewertung Anzahl
* CPD7534 20 1 Nachricht . . . : Länge des Schlüsselwortwerts ungültig.
* CPD7616 30 1 Nachricht . . . : Schlüsselwort wegen Fehlers in Werteliste ignoriert.
DDS-Alias wird wohl bei 30 Stellen bleiben.
Ansonsten musst du wohl die Länge trotz "R" für die DSPF reduzieren.
andreaspr@aon.at
12-01-10, 10:47
ja schade.
ich habe das mit V5R4 getestet und vielleicht ist es bei V6R1 anders. glaube aber ehe weniger.
DDS wird wohl nie SQL-Kompatibilität errreichen.
Laut IBM ist DDS (Physische/Logische Dateien, Printerfiles, DisplayFiles) ebenso wie PDM, SEU, SDA &RLU "Stabilized", sprich "Rien ne va plus", sprich "so gut wie TOT"!!! und das schon seit mehreren Releasen.
Was physische und logische Dateien angeht, da wurden mit Release 6.1 sogar die Indices aufgebohrt, so dass neue Spalten definiert werden können, Spalten ausgewählt werden können, Skalare Funktionen für die Spalten-Definition verwendet werden können, die neu geschaffenen Spalten als Keys angegeben werden können und sogar Where-Bedingungen in die Indices aufgenommen werden können.
SQL Indices können wie DDS beschriebene logische Dateien mit native I/O verarbeitet werden. Damit kann fast alles (außer Join) und sogar einiges mehr, was in den DDS beschriebenen logischen Dateien hinterlegt werden konnte auf SQL Indices übertragen werden.
DDS beschriebene logische Dateien sind ab 6.1 nur noch dann erforderlich, wenn Join-LF mit native I/O verarbeitet werden müssen.
(Join in logischen Dateien wird wahrscheinlich nie in SQL übertragen werden!)
Birgitta
... wieder mal ein typisches Beispiel, dass diejenigen die da an rpg rumbasteln weit vom Geschehen entfernt sind.
Hier wird wieder einmal an der falschen Stelle repariert, SQL kriegt wider den Standard Erweiterungen auf die Indexe aufgelastet, anstatt Views im RPG verwendbar zu machen (man bräuchte lediglich die Möglichkeit eine Sortierung per Keywort ORDER angeben zu können); da bräuchte es auch keine 2 Query Engines und widersinnige Erweiterungen für SQL.
D*B
Laut IBM ist DDS (Physische/Logische Dateien, Printerfiles, DisplayFiles) ebenso wie PDM, SEU, SDA &RLU "Stabilized", sprich "Rien ne va plus", sprich "so gut wie TOT"!!! und das schon seit mehreren Releasen.
Was physische und logische Dateien angeht, da wurden mit Release 6.1 sogar die Indices aufgebohrt, so dass neue Spalten definiert werden können, Spalten ausgewählt werden können, Skalare Funktionen für die Spalten-Definition verwendet werden können, die neu geschaffenen Spalten als Keys angegeben werden können und sogar Where-Bedingungen in die Indices aufgenommen werden können.
SQL Indices können wie DDS beschriebene logische Dateien mit native I/O verarbeitet werden. Damit kann fast alles (außer Join) und sogar einiges mehr, was in den DDS beschriebenen logischen Dateien hinterlegt werden konnte auf SQL Indices übertragen werden.
DDS beschriebene logische Dateien sind ab 6.1 nur noch dann erforderlich, wenn Join-LF mit native I/O verarbeitet werden müssen.
(Join in logischen Dateien wird wahrscheinlich nie in SQL übertragen werden!)
Birgitta