| Subject | Re: Problem altering a column |
|---|---|
| Author | phil_hhn |
| Post date | 2011-08-09T22:02:43Z |
--- In firebird-support@yahoogroups.com, Thomas Steinmaurer <ts@...> wrote:
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
>Firstly a big thanks - select * from RDB$DEPENDENCIES does indeed expose a RDB$1230 dependency:
> > 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.
>
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