You can test these new procedures with a window procedure very much like dsOrderWinUpd.w.

To update the code:

  1. Copy dsOrderWinUpd.w to dsOrderWinAdv.w (adv for "advanced").
  2. Add this new Definition to it. This is the handle of the Order entity. This is now a persistent procedure, rather than running OrderSupport.p as a standalone .p: 
    DEFINE VARIABLE hOrderSupport AS HANDLE NO-UNDO.
  3. Change the Main Block to run OrderEntity.p as a persistent procedure: 
    MAIN-BLOCK:
DO ON ERROR   UNDO MAIN-BLOCK, LEAVE MAIN-BLOCK
   ON END-KEY UNDO MAIN-BLOCK, LEAVE MAIN-BLOCK:
  RUN enable_UI.
  RUN OrderEntity.p PERSISTENT SET hOrderSupport.
  . . .
  4. Change the CLOSE trigger in the Main Block to give the Order entity procedure a chance to clean up: 
    ON CLOSE OF THIS-PROCEDURE DO:
  APPLY "CLOSE" TO hOrderSupport.
  RUN disable_UI.
END.
  5. In the LEAVE trigger for iOrderNum, change the run of OrderMain.p to run fetchOrder in the Order entity procedure. For example: 
    TEMP-TABLE ttOline:TRACKING-CHANGES = FALSE.

DATASET dsOrder:GET-RELATION(1):QUERY:QUERY-CLOSE().
DATASET dsOrder:GET-RELATION(2):QUERY:QUERY-CLOSE(). 
DATASET dsOrder:EMPTY-DATASET.

RUN fetchOrder IN hOrderSupport 
  (INPUT iOrderNum, OUTPUT DATASET dsOrder).

    Note that the OUTPUT DATASET dsOrder parameter is not passed BY-REFERENCE, and should not be. If OrderEntity.p were running in a separate session, it would be ignored and would make no difference. But when it is running in the same session, you want the ProDataSet that is initialized, attached, and returned by fetchOrder to be the one the client uses, not the client's locally defined ProDataSet, which is not attached to any Data-Sources.

  6. In the CHOOSE trigger for BtnSave, remove the code that is now in clientChanges.p so that the trigger is reduced to this: 
    DO:
  DEFINE VARIABLE hDSOrder AS HANDLE NO-UNDO.

  TEMP-TABLE ttOline:TRACKING-CHANGES = FALSE.
  cStatus = "".
  hDSOrder = DATASET dsOrder:HANDLE.
  
  RUN clientChanges.p (hDSOrder, hOrderSupport, OUTPUT cStatus).
  
  DISPLAY cStatus WITH FRAME dsFrame.
  /* Re-enable the Order Number to select another Order. Also, set
     TRACKING-CHANGES back to TRUE to capture any further changes made
     to this Order. */
  ASSIGN 
    iOrderNum:SENSITIVE IN FRAME dsFrame = TRUE
    SELF:SENSITIVE                       = FALSE
    TEMP-TABLE ttOline:TRACKING-CHANGES  = TRUE.
END.

    You can see how much of what this trigger does has been replaced by the generic support procedure clientChanges.p.

    That is it. If you save this and run it, it should work exactly as it did before, with much less code in the client procedure and much less code in the support procedures because of clientChanges.p and commitChanges.p. Also, your Order support logic has been better organized into procedures that do specific parts of the job in ways that you can use as a standard for other ProDataSets.