|
For the application, you can
set the Update Supertype on Insert Deployment Configuration
parameter in the Authorizer.
This parameter determines what
happens to an existing record constellation when the user adds new
subtype data to it:
|
·
|
By entering this data in a subtype window. |
|
·
|
Indirectly, when a corrective constraint is evaluated
containing a statement of the following type: |
INSERT INTO <subtype> ...
If Update Supertype on Insert
is set to No (the default), inserting new subtype data as described
above is handled internally as an INSERT even if a record
constellation already existed.
If Update Supertype on Insert
is set to Yes, the manipulation is handled internally as an UPDATE
to the existing record constellation.
NOTE:
If the user adds new subtype data to an existing record
constellation by selecting the corresponding subtype indicator in
an info window and then filling out the fields in the subtype
window, this is always handled as an UPDATE to the record
constellation. Update Supertype on Insert has no relevance in this
case.
The Update Supertype on Insert
Deployment Configuration parameter has no relevance to the
application user.
For the application developer,
the only relevant aspects of this parameter are:
|
·
|
If the type of subtype insert described above is traced in
BenchMark or in a native database monitoring tool: |
|
·
|
If Update Supertype on Insert is set to No, it will show up as
an INSERT command. |
|
·
|
If Update Supertype on Insert is set to Yes, it will show up as
an UPDATE command. |
|
·
|
If the type of subtype insert described above occurs and
transitional constraints are defined on the record
constellation, |
|
·
|
If Update Supertype on Insert is set to No, they are evaluated
depending on the Fire on Insert flag. |
|
·
|
If Update Supertype on Insert is set to Yes, they are evaluated
depending on the Fire on Update flag. |
|
