You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The DDL statement like the following:
ALTER TABLE DROP COL1, ADD COL2 INT;
may fail because of "found dependancies", if database
was just restored from a backup.
The reason is simple. The engine executes parts of this
statement in order of declaration, i.e. firstly COL1 will be
dropped and then COL2 will be created. But restore
initializes all system generators with zero, so when a
system domain for COL2 is being created, there's a
chance that it will have exactly the same name as just
removed domain for COL1 had (first unused position from
RDB$0).
So we have (for example):
1) domain RDB$17 is deleted for COL1
2) domain RDB$17 is inserted for COL2
3) DFW manager checks for dependencies on RDB$17
and... we're in trouble, because such a dependency
already exists.
A current workaround is changing the order of
modifications in ALTER TABLE clause, placing ADD
commands before DROP ones, e.g:
ALTER TABLE ADD COL2 INT, DROP COL1;
The text was updated successfully, but these errors were encountered:
Submitted by: @dyemanov
Votes: 1
SFID: 765844#
Submitted By: dimitr
The DDL statement like the following:
ALTER TABLE DROP COL1, ADD COL2 INT;
may fail because of "found dependancies", if database
was just restored from a backup.
The reason is simple. The engine executes parts of this
statement in order of declaration, i.e. firstly COL1 will be
dropped and then COL2 will be created. But restore
initializes all system generators with zero, so when a
system domain for COL2 is being created, there's a
chance that it will have exactly the same name as just
removed domain for COL1 had (first unused position from
RDB$0).
So we have (for example):
1) domain RDB$17 is deleted for COL1
2) domain RDB$17 is inserted for COL2
3) DFW manager checks for dependencies on RDB$17
and... we're in trouble, because such a dependency
already exists.
A current workaround is changing the order of
modifications in ALTER TABLE clause, placing ADD
commands before DROP ones, e.g:
ALTER TABLE ADD COL2 INT, DROP COL1;
The text was updated successfully, but these errors were encountered: