Skip to main content
Version: 10.1

Store-record event overview

The table below affords an overview of all the possible constraint validations that could take place at store-record event time.

  • It shows the default order in which these potential validations take place.
  • It shows the Reason listed for the validation in BenchMark Profiler output.
  • Finally, it shows which validation steps potentially apply when the record manipulation is INSERT, when it is UPDATE, and when it is DELETE.
OrderValidationReason inBenchMark ProfilerINSERTUPDATEDELETE
1Lock record and subtype recordsLOCK_RECORDYY
2Set default valuesY
3Foreground authorizationAUTHORIZATIONYYY
4Productive domain constraintsDOMAIN_CONSTRAINTYY
5Sequence numbersSEQNOY
6Update On Self constraintsSELECT_FOR_UPDATENEWVALUESYY
7Mandatory columnsYY
8Domain constraintsYY
9Columns updatable(Yes, No, Only if Null)Y
10Restrictive domain constraintsDOMAIN_CONSTRAINTYY
11Foreign keys updatable(Yes, No, Only if Null)Y
12Unique keysUNIQUE_KEYYY
13Restrictive Update/Delete RulesRESTRICTEDYY
14Restrictive, non-transitional,single-record constraintsROW_CONSTRAINTYY
15Restrictive, transitional,single-record constraintsROW_CONSTRAINTYYY
16Restrictive, transitional,multi-record constraintsROW_CONSTRAINTYYY
17Immediate subtype definitions (totality, exclusivity)YY
18STORE-RECORD,first subtype, then supertype.MANIPULATIONYYY
19

For restrictive, non-transitional, multi-record constraints,

the primary key of the driving table record is determined.

In some cases, a constraint key query is needed.

CONSTRAINT_KEYQUERYYYY
20Cardinality checks are generated for relationships in which the current record is a child.CARDINALITYYYY
21Cascading or nullifying Update/Delete RulesCASCADINGYY
22Productive, non-transitional multi-record constraints (not deferred)SELECT_FOR_<manip>NEWVALUESor OLD_NEWVALUESYYY
23Productive, transitional, multi-record constraints (not deferred)SELECT_FOR_<manip>NEWVALUESor OLD_NEWVALUESYYY