> --- 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?
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!
