Subject Re: [firebird-support] Re: Problem altering a column
Author Thomas Steinmaurer
> --- In, 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?

RDB$TYPE = 3 is a computed by column, so are you referencing LASTNAME in
a computed by column somewhere?

Try to execute:

select * from rdb$relation_fields where rdb$field_source = 'RDB$1230'

Does anything show up?

> 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:
> Is this a 'safe' thing to be doing?

You are playing with fire here, manipulating system tables directly. It
might work, but you could end up with a logical corrupted database.

> 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...

I would do some kind of diff on the table to see what has been removed
after a restore. Perhaps this gives an idea what happened.

With regards,

Thomas Steinmaurer
Upscene Productions

Download LogManager Series, FB TraceManager today!
Continuous Database Monitoring Solutions supporting
Firebird, InterBase, Advantage Database, MS SQL Server
and NexusDB!