
|
If you were logged in you would be able to see more operations.
|
|
|
| Planning Status: |
Unspecified
|
|
Test case:
-- with Firebird 1.5 or 2.0
create domain state smallint;
create table tab (col state, check (col in (0, 1, 2)));
commit;
-- backup / restore
-- with Firebird 2.5
alter domain state set default 0;
commit;
-- ERROR
action cancelled by trigger (1) to preserve data integrity.
Cannot update trigger used by a CHECK Constraint.
The problem is that MET_change_fields() schedules the validation for dependent procedures/triggers. The CHECK constraint has two underlying triggers depending on the domain. During validation, RDB$VALID_BLR is going to be set to TRUE. But its prior value is NULL, as this field didn't exist in ODS 11.0. System trigger RDB$TRIGGER_22 considers that being a meaningful change and throws an exception (its purpose is to disallow modifications of check constraints).
I can think of a few possible solutions:
a) don't validate system triggers (thus not maintaining RDB$VALID_BLR for them)
b) remove comparison for RDB$VALID_BLR from RDB$TRIGGER_22 making this field irrelevant for the check
c) always reset the RDB$VALID_BLR flag during restore (don't preserve its backed up value)
|
|
Description
|
Test case:
-- with Firebird 1.5 or 2.0
create domain state smallint;
create table tab (col state, check (col in (0, 1, 2)));
commit;
-- backup / restore
-- with Firebird 2.5
alter domain state set default 0;
commit;
-- ERROR
action cancelled by trigger (1) to preserve data integrity.
Cannot update trigger used by a CHECK Constraint.
The problem is that MET_change_fields() schedules the validation for dependent procedures/triggers. The CHECK constraint has two underlying triggers depending on the domain. During validation, RDB$VALID_BLR is going to be set to TRUE. But its prior value is NULL, as this field didn't exist in ODS 11.0. System trigger RDB$TRIGGER_22 considers that being a meaningful change and throws an exception (its purpose is to disallow modifications of check constraints).
I can think of a few possible solutions:
a) don't validate system triggers (thus not maintaining RDB$VALID_BLR for them)
b) remove comparison for RDB$VALID_BLR from RDB$TRIGGER_22 making this field irrelevant for the check
c) always reset the RDB$VALID_BLR flag during restore (don't preserve its backed up value)
|
Show » |
|