Subject | Drop Table errors after sytem table access |
---|---|
Author | bmckenna6 |
Post date | 2006-05-30T18:17:52Z |
In a single user system, I'm getting the following error messages
when I attempt DROP TABLE on the last table of a group of tables:
no current record for fetch operation
unsuccessful metadata update
object <TABLENAME> is in use
Some background:
Before adding a node for a table to a Virtual Treeview, I need
to test that at least one record exists in that table so the following
code processes TABLE1, TABLE2, and TABLE3:
qryExistsRec.Close;
qryExistsRec.SQL.Clear;
qryExistsRec.SQL.Add('SELECT ''Table is not empty'' FROM
RDB$DATABASE ');
qryExistsRec.SQL.Add('WHERE EXISTS(SELECT 1 FROM '+aTableName+' ');
qryExistsRec.SQL.Add('WHERE (RecType = :RecType))');
qryExistsRec.ParamByName('RecType').AsInteger := RecType;
qryExistsRec.Open;
Result := qryExistsRec.RecordCount;
qryExistsRec.Close;
tnExistsRec.Commit;
I can drop TABLE1 or TABLE2. Attempts to DROP TABLE3 return the
above errors.
If I comment out the above system table query on startup, then
I have no problem deleting TABLE3.
So ISTM that the (last) call to the (Firebird) system table is
the issue here.
I'm using v1.0.0794
Barry
when I attempt DROP TABLE on the last table of a group of tables:
no current record for fetch operation
unsuccessful metadata update
object <TABLENAME> is in use
Some background:
Before adding a node for a table to a Virtual Treeview, I need
to test that at least one record exists in that table so the following
code processes TABLE1, TABLE2, and TABLE3:
qryExistsRec.Close;
qryExistsRec.SQL.Clear;
qryExistsRec.SQL.Add('SELECT ''Table is not empty'' FROM
RDB$DATABASE ');
qryExistsRec.SQL.Add('WHERE EXISTS(SELECT 1 FROM '+aTableName+' ');
qryExistsRec.SQL.Add('WHERE (RecType = :RecType))');
qryExistsRec.ParamByName('RecType').AsInteger := RecType;
qryExistsRec.Open;
Result := qryExistsRec.RecordCount;
qryExistsRec.Close;
tnExistsRec.Commit;
I can drop TABLE1 or TABLE2. Attempts to DROP TABLE3 return the
above errors.
If I comment out the above system table query on startup, then
I have no problem deleting TABLE3.
So ISTM that the (last) call to the (Firebird) system table is
the issue here.
I'm using v1.0.0794
Barry