Hallo,

es tut mir ja leid, dass ich ausgerechnet einem der Moderatoren widersprechen muss, aber ...

Commit *NONE heisst, dass SQL keine Sätze sperrt, weder gelesene, noch geschriebene, gelesen wird alles, was share read zulässt. Hierfür ist keine Journalisierung erforderlich

Commit *CHANGE heisst auch *UC für uncommited read, liest also alles, was share read zulässt und sperrt nur geschriebene Sätze bis Commit oder Rollback. hiermit kann man also nicht verhindern, dass ein Satz zwischen lesen und schreiben nicht von anderen verändert wird. Journal erforderlich!!!

*CS wird auch read committed genannt, hier gibt es keine dirty reads mehr, beim Lesen über Cursor wird der aktuelle Satz beim Lesen gesperrt und beim Schreiben oder nächstem Lesen freigegeben. Ist dem Sperren in RLA ähnlich. erfordert ebenfalls Journalisierung.

*ALL sperrt alle Sätze, egal ob gelesen oder geschrieben, bis Transaktionsende, keine dirty reads, Journal erforderlich.
*RR entspricht ANSI Serializable, das heisst es wird so geschrieben, als ob man alleine auf der DB wäre; sperrt alles gelesen und geschriebene und legt einen Write Lock auf alle Tables, auf die geschrieben wurde, Sperren werden auch hier beim Commit/Rollback freigegeben, erfordert Journal. Das ist auf einer AS/400 normalerweise nicht einsetzbar, wegen RLA (Dateien mit update geöffnet) und idiotischer defaults beim CREATE TABLE bzw. CRTPF (waitfile *immed).

Wenn wir denn bei idiotischen defaults sind; wait record 60 sec, das ist auch so einer.

Ein Blick ins SQL Handbuch, oder in die Bedienerhilfe beim STRSQL oder CRTSQLxxx, wäre hier hilfreich!!!

Dieter Bender

******************************************

<BLOCKQUOTE><font size="1" face="Verdana, Arial">Zitat:</font><HR>Original erstellt von Fuerchau:
Dieses Problem habe ich auch schon bei V4R5.
Bei COMMIT(*NONE) ist SQL nun mal so definiert, dass keine "schmutzigen" Read's ermöglicht werden.

siehe oben!!!

Wenn also auf einem Satz ein Lock vorliegt, kann SQL diesen Satz nun leider nicht lesen.

siehe oben!!!

Versuchen Sie es mit einem höheren Commit-Level, COMMIT(*CHG), so dass gelockte Daten auch gelesen werden können.

IBM hat wohl diesen "Fehler" seit V4R5 korrigiert, so dass nun einige SQL's jetzt fehlschlagen.

hier gab es keinen Fehler!!! allenfalls damages im OS (Gruppen PTFs einspielen!!!)


COMMIT(*CHG) kann auch ohne Journalisierung verwendet werden.[/quote]

siehe oben!!!