|Subject||Re: [firebird-support] Re: Problem altering a column|
> --- In firstname.lastname@example.org, Thomas Steinmaurer<ts@...> wrote:RDB$TYPE = 3 is a computed by column, so are you referencing LASTNAME in
>>> 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:
> 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?
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:You are playing with fire here, manipulating system tables directly. It
> 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?
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'...?I would do some kind of diff on the table to see what has been removed
> 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...
after a restore. Perhaps this gives an idea what happened.
Download LogManager Series, FB TraceManager today!
Continuous Database Monitoring Solutions supporting
Firebird, InterBase, Advantage Database, MS SQL Server