Try OpenEdge Now
skip to main content
Data Access and Business Entity Objects : Business Entity object : Elements of a Business Entity : Validation procedures for the generic update API
Validation procedures for the generic update API
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:

  /* 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
      BUFFER ttOline:ERROR = TRUE
        "Line " + STRING(ttOline.LineNum) +
        ": You can't drop the Qty that much!".
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.