SQL UPDATE ändert sperrstatus

**Fuerchau** · 06-05-14, 16:05

Prüfe mal, ob die Datei per SHARE(*YES) definiert ist.
Dies ist ACTGRP-übergreifend!
Und ich vermute, dass du ohne CMTCTL (also auch ohne Journal) arbeitest.

Wenn dein SQL ohne Commit arbeitet, kann die Sperre dann aufgehoben werden.
Wenn beide ACTGRP's mit Commit arbeiten, kann das nicht passieren.

**Robi** · 06-05-14, 16:15

Ohne CMTCTL, das ist richtig.

Share = YES habe ich hier grade erfolgreich abgeschafft ! Das ist es nicht.
Kein Scheiß, ich schaue mit auf einer Sitzung die Sperren an, stehe auf der anderen Sitzung mit debug vor dem /exec sql update file set feld = wert where key1 = :Key1
Der update wird gemacht (sqlcode 0) und der Sperr- Status springt auf "lesen"

Robi

**Fuerchau** · 06-05-14, 16:34

Dann wird die Datei aber nicht 2 Mal geöffnet!
Jede ACTGRP sollte einen eigenen Open haben.
Prüfe mal Überschreibungen nach, manchmal macht noch ein CLP irgendwo mucken mit OVRDBF SHARE(*YES) und OPNDBF!

**Robi** · 07-05-14, 09:00

Lt offene Dateien anzeigen ist die Datei (einmal PF mit Key einmal LF) je ACTGRP offen.
CL oder QCMDEXE / System sind da nicht zwischen.
Mal sehn was IBM sagt
(melde mich später wieder, jetzt ist erst Urlaub)
Robi