Teildatei- Satzsperren bei SQLRPGLE obwohl Programm zu

[andreaspr@aon.at]

... nochmal: die database engine betreibt einiges an caching - und das ist auch gut so!!!

Sicher? Soviel ich weis wird die Aktivierungsgruppe *NEW automatisch vom System bereinigt, sobald das Programm beendet wird. Selbst wenn z.B. noch ein Commit offen ist.

[B.Hauser]

Sicher? Soviel ich weis wird die Aktivierungsgruppe *NEW automatisch vom System bereinigt, sobald das Programm beendet wird. Selbst wenn z.B. noch ein Commit offen ist.

Sie Database Engine versucht die ODPs solange offenzuhalten wie möglich. Sobald die Aktivierunggruppe geschlossen wird, werden die zugeordneten Ressourcen bereinigt. Das gilt auch für die in der Aktivierungsgruppe geöffneten ODPs. Commit oder nicht Commit hat mit den geöffneten ODPs wenig zu tun. Ein Update erfolgt immer auf die Echt-Daten und nicht Daten, die in irgendwelchen temporären Objekten gespeichet sind.

Was mich allerdings bei der ganzen Sache stört ist das Wort Teildateien:

und zumindest die Satzsperren sind verschwunden, jetzt blieben nur noch die Teildateien geöffnet.

Werden hier Overrides oder Aliases verwendet um auf echte Teildateien zuzugreifen.
Ansonsten, wenn du wirklich die Datei bereinigen willst, solltest Du die Daten mit dem SQL Delete herausfegen. Sofern keine Locks bestehen wird Under the Cover ein CLRPFM ausgeführt, ansonsten werden lediglich die Datensätze gelöscht.

Ich werde es so machen, das ich die Objekte als Batchjob in die QTEMP

Batchjob in QTEMP!!! Bist Du sicher, das das klappt???

Birgitta

[BenderD]

... immer diese Mythen:
@CLOSSQLCSR: F1 macht schlau!
Gibt an, daß SQL-Cursor implizit geschlossen, mit SQL vorbereitete
Anweisungen implizit gelöscht und Sperren, die mit LOCK TABLE
erfolgten, freigegeben werden. SQL-Cursor werden explizit
geschlossen, wenn der Benutzer die SQL-Anweisung CLOSE, COMMIT oder
ROLLBACK (ohne HOLD) ausgibt.
Schlußfolgerungen:
1.) das sind alles logische close Operationen, ob wirklich geschlossen wird, obliegt der Database Engine (kann sich also auch jederzeit ändern!)
2.) Wer mit Commit arbeitet, hat es hier einfacher!

@caching: Was die Database Engine wirklich cached, ist nicht dokumentiert und kann sich damit selbst mit einem PTF ändern. Applikationen dürfen nur auf dokumentierte Eigenschaften vertrauen, alles andere ist ein klassischer Kunstfehler.
Schlussfolgerungen:
1.) Wer alles mit SQL macht, hat mit den vom OP angesprochenen Sperren kein Problem.
2.) Wer Mix mit Altlasten hat, muss bei den Altlasten ansetzen. Der korrekte Weg dazu ist vor CLRPFM, RGZPFM und ähnlichem einen ALCOBJ CONFLICT(*RQSRLS) abzusetzen.

D*B