Try OpenEdge Now
skip to main content
Application Migration and Development Guide
Application Development with PAS for OpenEdge : Design and Implementation Considerations : Transaction and record management considerations : Managing conflicts between client and server : On the client
 
On the client
When a lock wait time out occurs on the server because of a lock conflict that exceeds the time specified by the Lock Wait Timeout (-lkwtmo) startup parameter, a STOP condition is raised on the client side.
You cannot trap this stop condition simply by checking ERROR-STATUS:ERROR for a RUN statement that executes a remote procedure. The only way to handle this situation is to use the ON STOP phrase, as shown in this code fragment, as shown:
RUN testlkwtmo.
MESSAGE RETURN-VALUE VIEW-AS ALERT-BOX.

PROCEDURE testlkwtmo:
  DO ON STOP UNDO, RETURN "STOP occurred":
    DEFINE VARIABLE hServer AS HANDLE  NO-UNDO.
    DEFINE VARIABLE lFlag   AS LOGICAL NO-UNDO.

    /* Invoke procedure on the server that locks records. */
    CREATE SERVER hServer.
    hServer:CONNECT("-URL http://localhost:8810/dbmanager/apsv").
    RUN lockrecords.p ON SERVER hServer (OUTPUT lFlag) NO-ERROR.

    MESSAGE "flag :" lFlag SKIP "ERROR-STATUS:ERROR :" ERROR-STATUS:ERROR
      VIEW-AS ALERT-BOX.
  END.
END PROCEDURE.
If lockrecords.p terminates on the server because of a lock wait time out, the server raises a STOP condition on the client. The client program flow never reaches the message following the RUN statement that executes lockrecords.p, However, the client can catch the STOP condition and handle character string returned in RETURN-VALUE.