-
ovrdbf und sql
Hallo Forum!
Stehe vor einem Problem.
Wir sind gerade dabei unsere ganze Datenbasis von DDS auf DDL umzustellen, viele alte Programme sollen aber noch genauso weiterlaufen wie bisher.
In einigen Listen-Programmen wird mit Workfiles gearbeitet, diese werden im CL in die QTEMP kopiert, danach ein OVRDBF gemacht und dann eine logische Datei dazukopiert auf die ebenfalls ein OVRDBF gemacht wird. Jetzt hab ich das Problem dass ständig der Zugriffspfad auf die Originaldatei die nicht in QTEMP liegt verweist. Hab auch schon versucht die Dateien in QTEMP anders zu benennen, aber ohne Erfolg.
"Gemeinsame Zugriffspfadbenutzung durch Datei WRKLGBE2 in QTEMP".
Bitte wie kann ich das abstellen??
Will nicht jedes Programm umbauen müssen, zumal ich gar nicht weiß wo das überall eingebaut ist.
Danke!
Wer andren eine Bratwurst brät, hat ein Bratwurstbratgerät!
-
Wie wird denn die logische Datei dazukopiert?
-
Mit einem CRTDUPOBJ.
Hab auch schon ein CRTLF über DDS versucht im CL, geht aber auch nicht.
Wer andren eine Bratwurst brät, hat ein Bratwurstbratgerät!
-
Liegt die zu kopierende logische Datei in der selben Bibliothek wie die zu kopierende physische Datei? Dann müßte der CRTDUPOBJ die kopierte logische Datei eigentlich an die kopierte physische Datei hängen (das steht zumindest so im Hilfetext zum CRTDUPOBJ).
-
Die Dateien heißen fast gleich, die physiche WRKLGEWP, die logische WRKLGBE2.
Der Bezug ist aber immer noch auf die physiche in der falschen Bibliothek. Nicht einmal ein OVRDBF hilft da.
@Fuerchau:
Wir haben für die alten Programme logische Dateien erstellt die gleich heißen wie die alten Physischen.
Programme die auf die neuen Dateien losgehen schreib ich gerade alle um. Haben Gott sei Dank ein Testsystem auf dem ich alles ausprobieren kann. ;-)
Wer andren eine Bratwurst brät, hat ein Bratwurstbratgerät!
-
Liegen die logischen Dateien vor dem Kopieren in der selben Bibliothek wie die physischen Dateien?
-
Nein, die liegen in 2 unterschiedlichen Bibliotheken, eine für DDL eine für DDS. Wollten da eine Trennung.
Hab jetzt die original Logische gelöscht und im CL ein CRTLF über DDS gemacht, geht aber auch nicht.
Ich versteh nicht ganz warum ein OVRDBF hier nicht zieht ...
Wer andren eine Bratwurst brät, hat ein Bratwurstbratgerät!
-
Ist die QTEMP in der Bibliotheksliste?
Eventuell hilft es, die QTEMP vor die eigentliche Quellbibliothek in die Bibliotheksliste zu setzen.
Gruß
-
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.
-
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 ;-))
-
 Zitat von RobertMack
Was spricht eigentlich gegen einen OPNQRYF mit Schlüsselfeldangaben auf die PF in der QTEMP
Um Gottes Willen! ;-)
Wer andren eine Bratwurst brät, hat ein Bratwurstbratgerät!
-
so jetzt weiß ich woran es gelegen ist.
 Zitat von Pikachu
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.
Recht herzlichen Dank!!
Wer andren eine Bratwurst brät, hat ein Bratwurstbratgerät!
Similar Threads
-
By christian_lettner in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 16-11-06, 10:15
-
By FNeurieser in forum NEWSboard Programmierung
Antworten: 3
Letzter Beitrag: 11-10-06, 14:53
-
By malzusrex in forum IBM i Hauptforum
Antworten: 8
Letzter Beitrag: 19-09-06, 11:04
-
By Kaufmann in forum IBM i Hauptforum
Antworten: 11
Letzter Beitrag: 28-06-06, 14:11
-
By loeweadolf in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 01-06-06, 09:43
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks