Row Checks

Within one row event, the Rules Engine can handle some restrictive constraints pre-store, that is, before the actual storage of the record. This is quicker and easier to control.

These constraints are classified as row checks. Row checks occur at record validation time, before the Store-Record operation, and are identified in BenchMark profiler output as ROW_CONSTRAINT. For row checks, the constraint evaluation is part of the row event.

Restrictive constraints can be handled as row checks if they apply to the current row event:

•Restrictive, single-record constraints.

•Restrictive, transitional, multi-record constraints for which the row event is within the transition table.

Example 1

Here is an example of a single-record constraint that can be handled as a row check:

SELECT    '' violation

FROM      reservation

WHERE     cancel_date < book_date

Example 2

Consider the business rule: "The number of days between start date and return date of a scheduled tour must equal the number of days set for the tour". This business rule is implemented by a restrictive constraint:

SELECT    '' violation

FROM      tour t

,         schedtour st

WHERE     t.destination = st.destination

AND       t.tour_type=st.tour_type

AND       st.return_date - st.start_date + 1 != t.num_days

Transition Table:    SCHEDTOUR

Fire On Insert:      Always

Fire On Delete:      Never

Fire On Update:      Used Columns

For row events on the SCHEDTOUR table, this constraint can be handled as a row check. For row events on the TOUR table, it will not be evaluated.