Hi Woody!

Around 23 July, I wrote a message to this list with the subject "Fb 1.5.4 - RDB$RELATION_FIELDS not in RDB$RELATIONS". In short, the problem was that there were records in RDB$RELATION_FIELDS and RDB$RELATION_CONSTRAINTS (I think) that were referring to a deleted table. This occurred when we created a table and a stored procedure or trigger (I don't remember which of them), then deleted the table/procedure and recreated them with a new table name. It was done on a database with several users simultaneously doing DML, but no-one touching the table/procedure in question.

So we assumed that doing what you consider doing was safe, but got this problem. The users doing DML never noticed anything and could happily continue working. We are not aware of any loss of data and our quick and dirty fix only involved deleting a total of four records from these two system tables (after taking a file copy when no-one was connected to the database in case our "fix" didn't work). But I think we got sufficiently scared to avoid deleting tables while other users are doing DML to other tables in the database. We still have no idea how this could happen, and I doubt we could reproduce the error (at least, we're not willing to try on a live database).

I have no idea whether similar things can happen with Firebird 2 or not.

Set

Woody wrote:

> So far, I've always waited until all users are out of a system before
> applying metadata changes. However, there are times where I'm working on a
> new part of the system involving tables which the application is not yet
> using. At least, the application version that the users are using, anyway.
>
> Are there any dangers to doing metadata changes to tables which I know that
> no one is using except me? I haven't done it yet, because I don't want to
> risk the integrity of the live (users) database. But I would be interested
> to know if this is safe at all...

[Non-text portions of this message have been removed]