View Full Version : ovrdbf und sql
so jetzt weiß ich woran es gelegen ist.
Liegen die logischen Dateien vor dem Kopieren in der selben Bibliothek wie die physischen Dateien?
Genau das ist das Problem, die logischen müssen vorher in der selben Bibliothek liegen, sonst geht es nicht.
Mir ist das unterm schreiben der Antwort gedämmert. :o
Recht herzlichen Dank!!
RobertMack
11-09-09, 09:25
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 ;-))
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!
Ein OVRDBF gilt nur für einen Open.
Der CRTLF öffnet aber nicht die Datei sondern stellt den Bezug über LIBL her.
@Pikachu
Wird eine logische Datei in eine andere Bibliothek kopiert, gibt es
zwei Möglichkeiten zur Festlegung der Basisdatei.
1. Wenn die logische Datei und die physische Basisdatei sich
ursprünglich in derselben Bibliothek befinden, muss zuerst die
physische Datei in der neuen Bibliothek dupliziert werden,
bevor die logische Datei dupliziert wird. Nach der
Duplizierung der beiden Dateien wird die neue physische Datei
als Basisdatei für die logische Datei benutzt.
2. Wenn sich die logische Datei und ihre physische Basisdatei
ursprünglich in unterschiedlichen Bibliotheken befinden, ist
es nicht erforderlich, die physische Datei vor der logischen
Datei zu duplizieren. In diesem Fall haben die duplizierte
logische Datei sowie die ursprüngliche logische Datei dieselbe
physische Basisdatei. Im Gegensatz zum ersten Fall dient die
ursprüngliche physische Datei als Basisdatei für die
duplizierte logische Datei und nicht die duplizierte physische
Datei, selbst wenn die physische Datei vor der logischen Datei
in der neuen Bibliothek dupliziert wurde.
Es ist also wichtig, das als Ursprung die PF und LF in der selben Lib liegen.
Ein CRTDUPOBJ der PF aus LIBA und der LF aus LIBB stellt keinen Zusammenhang zwischen PF und LF fest.
RobertMack
11-09-09, 10:37
Was spricht eigentlich gegen einen OPNQRYF mit Schlüsselfeldangaben auf die PF in der QTEMP?
In der nächsten Entwicklungsstufe würde ein FNDSTRPDM alle für SQLRPGLE prädestinierten Programme offenbaren ;-))
Was spricht eigentlich gegen einen OPNQRYF mit Schlüsselfeldangaben auf die PF in der QTEMP
Um Gottes Willen! ;-)