For example, the OrderEntity procedure has this sample validation procedure, which based on its name, will be executed whenever a row in the ttOline table in the ProDataSet is modified:

PROCEDURE ttOlineModify:
  DEFINE INPUT PARAMETER DATASET FOR dsOrder.

  /* If customer doubled quantity ordered, then increase discount by 20%. */
  IF ttOline.Qty >= (ttOlineBefore.Qty * 2) AND 
    ttOline.Discount = ttOlineBefore.Discount THEN
    ttOline.Discount = ttOlineBefore.Discount * 1.2.
  ELSE IF ttOline.Qty <= (ttOlineBefore.Qty * .5) THEN
    ASSIGN 
      BUFFER ttOline:ERROR = TRUE
      BUFFER ttOline:ERROR-STRING = 
        "Line " + STRING(ttOline.LineNum) + 
        ": You can't drop the Qty that much!".
  RETURN.
END PROCEDURE. /* ttOlineModify */

The basic principles of writing procedures such as this one are:

  • You can pass in the entire ProDataSet BY-REFERENCE from another procedure in the same session without the cost of copying it, so that the validation logic can examine any part of the ProDataSet that it needs to.
  • The current rows in the buffers will be those that were current in the caller. In particular, the current row in the table that triggered the event is the one that was modified, so you can examine its values without having to FIND it.

Validation procedures can set the ERROR and/or ERROR-STRING attributes for the row to communicate status information. Setting ERROR-STRING without setting ERROR lets you return an informational or warning message without causing an actual error.