Exception Handling bei Satzsperre in SQLRPGLE

[Albrecht_Ch]

Diese Antwort habe ich schon fast befürchtet . Die Informationen in der Struktur SQLCA sind leider nicht so aussagekräftig. Es steht in der SQLERM eigentlich nur die Lib und die Datei.

Für mich wichtig wäre der User wo den Satz gerade im zugriff hat.

Trotzdem vielen Dank für die Info zum SDS.

[Fuerchau]

Da hilft dir wohl leider nur ein Serviceprogramm, in dem du den normalen Zugriff auf die Datei kapselst um im Fehlerfall die Sperre abzufragen, was allerdings durch die Zeitverzögerung ggf. negativ beantwortet würde.

[andreaspr@aon.at]

Hallo Albrecht_Ch,

es gibt eine recht mächtige funktion in SQL (Get Diagnostics).
mit diesem tool, kannst du alle möglichen informationen zu deinem letzten (oder die letzten) sql-aufrufe holen.

D vsqlstt         S             512A
/Free
  Exec Sql Get Diagnostics CONDITION 1
        :vsqlstt = MESSAGE_TEXT;    
  dsply (sqlstt);                     
/End-Free

es gibt 2 sehr gute handbücher in denen du auf jedenfall genug informationen finden kannst.

hoffe es hilft dir weiter!

System i
Database
Embedded SQL programming
Version 6 Release 1
5761–SS1

IBM Systems - iSeriesDB2 for i5/OS SQL Reference Version 5 Release 4
5722–SS1

lg andi

[B.Hauser]

... nur leider gibt Get Diagnostics auch nur die Fehlermeldung, dass in der Datei eine Satz-Sperre vorliegt, aber nicht welcher Job bzw. welcher User welchen Satz blockiert.

Hier sind übrigens die Links zu den Online-Books:
SQL Reference - Release 6.1
Embedded SQL Programming - Release 6.1

Birgitta

[dabeda]

Du kannst über die API QGYOLJBL das Joblog auslesen und dir die Meldung holen die du brauchst. Leider ist das dann einfach ein ganzer Textstring ohne Variablen.

Alternativ kannst du bei einem Lock die relative Satznummer auslesen (select rrn(datei) from datei where ) und dann mit der API QDBRRCDL den Benutzer usw. auslesen. Das Ganze dann noch schön in einem Serviceprogramm verpackt und man merkt gar nicht mehr, dass SQL das eigentlich gar nicht kann. ;-)

MfG

[Fuerchau]

Wobei der Select RRN ganz schön dauert, da hier grundsätzlich kein Index verwendet wird.
Eine schnelle und vor allem gute Lösung ist das nicht.

Was ich mich allerdings frage, wieso der SELECT gesperrte Sätze nicht liest ?
Einen Fehler gibts eigentlich erst beim UPDATE/DELETE oder der gesperrte Satz wird einfach überlesen.

[dabeda]

So schnell wie im RPG ist das natürlich nicht, man kann aber beim declare cursor gleich die relative Satznummer mit auslesen, dann erspart man sich das nachher. Obwohl ich eingentlich nicht so viele Locks erwarte dass es zeitlich ein Problem wird die relative Satznummer auszulesen.
Glaube das Überlesen von gelockten Sätzen funktioniert erst bei V6.1, kann mich aber täuschen.

[Fuerchau]

Das Überlesen ist ja nicht das Problem.
Ich kann durchaus gesperrte Sätze lesen!

Allerdings darf ich den Cursor nicht als "for update" deklarieren, da im Falle des Lesens genau dann ein Sperre gesetzt wird und es ggf. zum Fehler kommt.

SQL-Like ist das nicht.
MS-Access / ADO.NET geht den "normalen" Weg, dass vor dem Update / Delete die aktuelle Information erst noch mal gelesen und mit dem vorherigen Zustand verglichen wird. Ist der Inhalt noch unverändert, wird geändert an sonsten ein Fehler ausgelöst.

Dies wäre das korrekte Anwendungsverhalten, denn eine potentielle Satzsperre ohne den tatsächlichen Wunsch einer Veränderung sollte nicht erfolgen.

[mwithake]

Wobei der Select RRN ganz schön dauert, da hier grundsätzlich kein Index verwendet wird. Eine schnelle und vor allem gute Lösung ist das nicht.

Das Stimmt nicht, Indexe werden auch zur Ermittlung von RRN() verwendet.

[Fuerchau]

Wenn du einen
select ... where rrn() = 1234
verwendest, kann SQL keinen Index verwenden, da es keinen Index über RRN gibt.
Schränkst du natürlich auf weitere Schlüssel ein, werden für diese natürlich Indizees verwendet.

[mwithake]

Wenn du einen
select ... where rrn() = 1234
verwendest, kann SQL keinen Index verwenden, da es keinen Index über RRN gibt.
Schränkst du natürlich auf weitere Schlüssel ein, werden für diese natürlich Indizees verwendet.

Es ging ja in dem Beitrag davor darum, die relative Satznummer zu ermitteln und Du hattes geschrieben, es würde sehr lange dauern.
Die Ermittlung geht durch einen entsprechenden Index sehr schnell und ich denke, das der Zugriff bzw. die Auswahl über relative Satznummer auch sehr schnell geht.

Die von dabeda angegeben Methode mittels QDBRRCDL nutzt ich übrigens für Java, um auf der Java-Oberfläche den zu blockierenden Benutzer anzeigen zu können. Das geht sehr fix.

[Fuerchau]

Dazum muss ich aber grundsätzlich den Schlüssel mit abfragen um einen Index zu benutzen.