SQL und Displayfile

[andreaspr@aon.at]

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. 

[Fuerchau]

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]

ja schade.
ich habe das mit V5R4 getestet und vielleicht ist es bei V6R1 anders. glaube aber ehe weniger.

[Fuerchau]

DDS wird wohl nie SQL-Kompatibilität errreichen.

[B.Hauser]

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

[BenderD]

... 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