SQL und Displayfile

[Xanas]

Komisch nur, dass wenn ich den Feldnamen kürze

create table test (verladedokumentation_kat_id bigint)

dann wird der kram erstellt.

Ich habe auch noch eine andere ID in der Datei die verladedokumentation_api_id auch als BIGINT und das Feld wird ohne Problem akzeptiert.

Und das hat doch was mit den langen Feldnamen zu tun, die legt die DDS nämlich als ALIAS an.
Das stellt man dann fest, wenn auf Felder aus zwei verschiedenen Dateien referiert und die zufälligerweise beide ID heißen, dann muss man eins der beiden Felder mit den Schlüsselwort ALIAS umbenennen.

[B.Hauser]

Versuch mal folgends:

CREATE TABLE Test
(verladedokumentation_kat_id For VDKID bigint) 

Referenziere auf VDKID (oder wie immer der kurze Name sein soll, er darf nur maximal 10 Stellen enthalten).

Für SQL erstellte Tabellen mit Feldnamen länger als 10 Stellen wird automatisch ein System-Name erstellt (Stelle 1-5 des langen Namens + 5-stelliger laufender Zähler z.B. VERLA00017), es sei denn man gibt wie oben gezeigt einen kurzen Namen vor (LangerName FOR SystemName). Für die Referenzierung, wie auch für den Native I/O muss immer der (kurze) System-Name verwendet werden.

Birgitta

[Fuerchau]

SQL-Namen können max. (ich glaube) 120 Stellen umfassen, DDS-ALIAS aber nur 30 Stellen.
Das wird wohl der Grund sein.

[B.Hauser]

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

[Xanas]

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]

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