How The Driving Table is Determined
The driving table never depends on what the user does (the initial row event). It only depends on how the constraint SQL statement is formulated. For each constraint, the Rules Engine determines the driving table using the following rules:
Usually this is the highest parent table that occurs within the constraint.
If the statement contains a RELATE clause, this is a placeholder for the normal WHERE clause expressing the relationship. The driving table is identified as if joined primary and foreign key column names appeared explicitly in the statement.
Consider the business rule: "The time between the start date and return date of a scheduled tour must equal the preset number of days for the tour." This business rule is implemented by a restrictive constraint:
SELECT '' violation
FROM schedtour st
AND t.num_days <> st.return_date - st.start_date + 1
The driving table of this constraint is TOUR, because only the TOUR table has all of its primary key columns mentioned in the statement.
Therefore, in the constraint test statement issued at commit time, row binding is applied to the TOUR table, independently of whether the original manipulation was on TOUR or on SCHEDTOUR:
FROM OPS$CP1.SCHEDTOUR t1
WHERE ( :1 = t1.DESTINATION
AND :2 = t1.TOUR_TYPE
AND TO_NUMBER(:3) <> t1.RETURN_DATE - t1.START_DATE + 1
In this constraint test SQL statement:
In other words: only one record in the TOUR table matters, so values of this record can be substituted instead of mentioning the whole table.