--- In [email protected], Thomas Steinmaurer <ts@...> wrote:
>
> > Thanks... I think I already did but I may be wrong. If RDB$DEPENDENCIES
> > doesn't expose RDB$1230, any other ideas? (I'm just trying to preempt the
> > worst-case scenario because I'm not back in the office for 9 hours ;-) )
>
> Hmm. It also might be a bug in the engine, if e.g. in your case after a
> backup/restore things are back to normal. As far as I recall, there have
> been a few dependency bugs fixed across Firebird versions.
>
> Still, RDB$... is something system generated, so perhaps a field without
> using a DOMAIN, including computed by fields, which uses LASTNAME in
> their expression, or constraints, indices ... using system-generated names.
>
Firstly a big thanks - select * from RDB$DEPENDENCIES does indeed expose a
RDB$1230 dependency:
Dependent_Name=RDB$1230
Depended_On_Name=Person
Field_Name=LastName
Dependent_Type=3
Depended_On_Type=0
Does Dependent_Type or Depended_On_Type indicate how this RDB$ dependency came
about? I've looked at RDB$TYPES and there seems to be multiple rows for
RDB$TYPE=3 so I don't know how this all works (or whether RDB$TYPES is even
relevant...)
Or - as you suggest if this is a bug in older Firebird versions - I should just
assume this is something I need to work around?
Anyway back on topic, the above query exposes RDB$1230 and 2 others! Of course
dropping that dependency means that the update fails on the next dependency, so
I need to drop all 3. So I did this:
delete from RDB$DEPENDENCIES where RDB$DEPENDENT_NAME IN (select
RDB$DEPENDENT_NAME from RDB$DEPENDENCIES where RDB$DEPENDED_ON_NAME = 'PERSON'
and RDB$FIELD_NAME = 'LASTNAME')
Is this a 'safe' thing to be doing?
I can partially answer this - after fixing the above dependencies I found an
update of another column fails for similar reasons. i.e where there are RDB$...
dependencies on a column I want to update. But in this case there are also
valid dependencies listed (like triggers), so I will have to add to the where
criteria " and RDB$DEPENDENT_NAME like 'RDB$%' ". So again I'm not sure if this
is 'safe'...?
In all when I run select * from RDB$DEPENDENCIES there are 643 rows returned
but after a backup/restore only 245, and all RDB$... dependencies disappeared.
So I wonder of I should simply drop all of them in one go...? Hmmm...
Cheers
