ovrdbf und sql

[RobertMack]

Stehen WRKLGEWP und WRKLGBE2 in der gleichen *LIB?
Steht die QTEMP zum Zeitpunkt des CRTDUPOBJ vorne?
=> CRTDUPOBJ F4, F1, F2

Nachtrag: da war ich wohl zu spät, sozusagen CRTDUPPST ;-))

[dabeda]

Das Problem ist dass die beiden Files nicht in der gleichen LIB stehen, aber das ändere ich jetzt gerade.

Wir wollten die DDL und DDS Dateien einfach in 2 Bibliotheken trennen, und dann sukzessive die DDS Dateien verschwinden lassen. War gut gemeint, aber ich leg die Files jetzt wieder zusammen.

Einen Versuch wars allemal wert, konnte wieder etwas dazulernen. ;-)

Wie immer, der Wille zählt. ;-)

Vielen Dank nochmal!

[Fuerchau]

Wenn eine PF mit LF kopiert werden soll, ist es erforderlich diese mit den gleichen Zeichen anfangen zu lassen wenn man CRTDUPOBJ machen will. In diesem Fall wird der Bezug der LF zu PF mitgenommen.
Beispiel:

MYFILE PF
MYFILE01 LF

CRTDUPOBJ MYFILE* ...

Wenn man den CRTLF per DDS macht, sollte man die QTEMP dann nach vorne in die LIBL stellen, da ja der PFILE-Bezug ohne LIB-Angabe ist, damit dies funktioniert.

Bei der Umstellung von DDS auf DDL kann es bei Altprogrammen zu massiven Problemen kommen.
1. Die Formatid wird auf jeden Fall anders.
2. Der Satzformatname ist per Default mit dem Dateinamen identisch, es sei denn man gibt diesen im CREATE TABLE explizit an (RCDFMT xxxx), was aber AS/400-spezifisch ist.
3. Ohne OVRDBF ... LVLCHK(*NO) funktioniert das aber nicht, was zu weiteren Risiken führt.
4. PF mit Key gibt es als TABLE nicht. Hier ist immer ein Index erforderlich auf den dann mit obigen Risiken überschrieben werden muss. Allerdings gibt's beim Index kein RCDFMT.

[Pikachu]

Wenn eine PF mit LF kopiert werden soll, ist es erforderlich diese mit den gleichen Zeichen anfangen zu lassen wenn man CRTDUPOBJ machen will. In diesem Fall wird der Bezug der LF zu PF mitgenommen.

Sicher? Im Hilfetext zum CRTDUPOBJ steht da aber was völlig anderes.