Subject RE: [firebird-support] Table with no name
Author Svein Erling Tysvær
>I have managed to create a table with no name and possibly no fields!
>There is a record in RDB$RELATIONS where all of the fields are null except RDB$OWNER_NAME
>and RDB$DEFAULT_CLASS both of which have values in them. Validating the database finds no
>errors and trying to mend the database indicates that it does not need mending. Backup
>works but restore produces this message
>'This operation is not defined for system tables.unsuccessful metadata update. TABLE .
>Can't have relation with only computed fields or constraints.'
>Any idea how to delete this table?

First, if this is anything but a test database, then wait for some of the system table gurus (i.e. not me) to tell you whether or not it is safe to delete such a table directly from rdb$relations.

I think I would try running the following EXECUTE BLOCK to see which system tables you should check (maybe the non-existing table exists in other system tables as well):

execute block returns (Statements varchar(500))
declare variable TblName char(31);
declare variable s char(500);
for select trim(cast(rdb$relation_name as varchar(31))) from rdb$relations
where rdb$system_flag = 1
into :TblName do
s = 'select ''' || TblName || ''' from rdb$database where exists('||
'select * from rdb$relation_fields where rdb$relation_name = ''' || TblName ||
''' and rdb$field_name = ''RDB$RELATION_NAME'')';
TblName = '';
execute statement S into :TblName;
if (TblName > '') then
s = 'SELECT ''' || TblName || ''' from rdb$database where exists(select * from '||TblName||' where rdb$RELATION_NAME = '''' or rdb$relation_name is null)';
execute statement s into :Statements;
if (Statements > '') then

I'd generally be very careful to directly update the system tables and I think we've only done it once a few years ago. I think we had removed some key or index from a table the 'normal' way, but for some reason it still existed in one or two system tables and we didn't see any other alternative than directly updating the system table(s). So we tried (having a file copy of the database of course, in case it didn't work) and after having updated rdb$..., we did backup/restore and hoped everything would be back to normal. For us, it seemed to work.

One wild idea, maybe the table was created case sensitive? You could try DROP TABLE ""