> --- In firebird-support@yahoogroups.com, 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:
> 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?

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
http://www.upscene.com
http://blog.upscene.com/thomas/

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