Öffnungsauswahlkrit. für gemeins. Öffnung von Teildatei xx ignoriert.

[votch]

Hallo,

ich habe folgendes Problem:

Eine PF, die es in mehreren Libs gibt, muss upgedatet(bzw. write) werden. PF ist im WWS schon als input geöffnet(von dort wird auch mein Prg aufgerufen). Beim Aufruf aus dem WWS bekomme ich zuerst die Fehlermeldung s. Titel(Artencode 1 - Auswahlkriterien zum Fortschreiben stimmen nicht überein...), danach "Fortschreibungsauswahl ungült. ..." und dann "E/A-Fehler CPF5125"

Ohne Vorsystem(Direktaufruf) funktioniert alles und er macht mir die Updates und Writes in allen Lib's.

OVRDBF kann ich wegen des Vorsystems keinen machen.

hier die Definitionen, die ich gemacht hab:

Fxx UF A E K Disk UsrOpn
F extfile(OV#File)


D ov#file s 21 inz('*LIBL/xx')


If not %Open(xx);
Open xx;
endif;
OV#File = %Trim(Lib) + '/xx';
If %Open(xx);
Close xx;
endif;

Wie kann ich es ändern, dass meine Auswahlkriterien nicht ignoriert werden, ohne OVRDBF(darf ich wegen WWS nicht) und SQL ist nicht erwünscht.

Vorab vielen Dank

LIB ist ein Dateifeld, in welchem die Bibliothek steht und die in einer Schleife durchgelesen wird.

Beim ersten chain Abbruch, chain(n) funktioniert noch

[cbe]

Hallo votch,

ich tippe darauf, dass die Datei im Vorsystem mit SHARE(*YES) geöffnet wurde. Dann kann die Datei, wenn sie mal nurLesend geöffnet wurde, in tieferen Programmen nicht mehr für Update geöffnet werden


Dazu fällt mir ein:

- Evtl darf kein OVRDBF gemacht werden, weil vorher schon OVRDBFs gemacht wurden? Wie wäre es mit
OVRDBF ... SECURE(*YES)?
Der lässt vorige OVRDBFs in Ruhe und sollte in Ordnung sein.

- Ansonsten SQL, soll ja aber nicht

- oder vielleicht je Datei eine LF, finde ich aber nicht sehr elegant


Und bestimmt gibt es im Forum noch andere Ideen.

Gruß, Christian

[andreaspr@aon.at]

Probier mal beim erstellen des PGMs Aktivierungsgruppe *NEW.

[votch]

Danke an alle,

Problem ist gelöst.

Es lag an der LF. Aus irgendeinem Grund kann man nicht alle LF's vom Vorsystem für Update/Write benutzen, obwohl ich nirgends einen Grund dafür sehen kann, warum dies so ist. Es gab zum Glück noch ein anderes LF mit genau dem gleichen Key und Aufbau, mit dem funktionierte es direkt auf Anhieb.

@cbe

genau, die Dateien sind mir Share *Yes geöffnet und es wurden schon OVRDBF's gemacht.

OVRDBF sollen keinesfalls eingebaut werden, leider auch nicht mit *secure, warum auch immer. Hätte es auch lieber schnell mit SQL gemacht, dass ist aber auch leider nur in Ausnahmefällen erwünscht. 1. wegen der Performance und 2. weil nicht alle mit embedded SQL zurecht kommen.

@andreas

Hatte es auch schon mit share *no und Aktivierungsgruppe *new versucht, leider wurde das auch ignoriert.

[Fuerchau]

Aktivierungsgruppe *NEW hat mit SHARE(*YES) einfach nichts zu tun.
Du hast nur 2 Möglichkeiten (ohne SQL):

a)
Eigene benannte Aktivierungsgruppe, Aufruf QCMDEXC mit "OVRDBF ... SHARE(*NO) OVRSCOPE(*ACTGRPDFN)" und dann den Open machen. Wenn deine Aktivierungsgruppe beendet wird ist auch der OVR weg.

b)
Obigen Vorschlag verwenden und einfach eine neue LF erstellen.
Wenn der Key identisch zu einer bestehenden LF ist, kostet die weder nennenswert Platz noch Performance.