> I take it that no answer means that this is a strange problem,
> and within the last 24 hours or so it has turned even stranger...
>
> Doing a backup and restore make the fields from the dropped table
> disappear from RDB$RELATION_FIELDS and apparently the database
> works correctly for a while. CREATEing and DROPping a new table a
> couple of times, then makes IB_SQL complain about multiple rows
> in singleton select when attempting to browse the database,
> whereas FlameRobin doesn't complain at all. A bit further
> investigation reveals that whilst the fields are gone from
> RDB$RELATION_FIELDS, they are still present in
> RDB$RELATION_CONSTRAINTS (i.e. we have a PK constraint that
> doesn't belong to any table!). gfix doesn't report anything.
> After another restore of the backedup database, the records in
> question can be deleted from RDB$RELATION_CONSTRAINTS (by now,
> we're working on a test database) and after this deletion
> everything appears to work as desired.
>
> Now for the real question which I hope someone can answer within
> the next 36 hours (Thursday we intend to try it on our production
> database unless advised otherwise): Is it safe to simply delete
> stray records from RDB$RELATION_CONSTRAINTS???
>
> Hoping for someone to enlighten us,
> Set
>

I know you said that no manual deletion from system tables was carried out
but it sure as hell sounds like someone did do this.
I wouldn't have gone this far fiddling with system tables but since you have
already, I would definitely now, do an extract of metadata, re-create a new
database, and pump the data across.
That wold be the cleanest and safest way to ensure that all system tables
are back the way they should be.
Alan