Commented by: Robert Gilland (robert.gilland_basx.com.au)

There is an equivalent issue in Interbase

http://qc.codegear.com/wc/qcmain.aspx?d=7952

Commented by: @hvlad

Does you tried FB 2.1 against this isuues ?

Commented by: @hvlad

Look also at CORE961

Commented by: @hvlad

> It is not possible to empty an external table or to delete the file associated with an external table without first disconnecting all users.
> This makes reuse of an external table for routine data export difficult or impossible.
>
> While it is possible to drop the external table using DROP TABLE, this does not close the external ASCII file and it still cannot be deleted.

This must be fixed in FB 2.1

> Two new features should be added. 1) DELETE FROM EXTERNAL_TABLE should delete all records.
> 2) DROP TABLE EXTERNAL_TABLE should close the external file so it can be deleted or renamed.

For this create feature request

I recommend to close this ticket

Commented by: Robert Gilland (robert.gilland_basx.com.au)

We should also fix the GBAK and restore service falling over whenever a external table is defined in the metadata.
This is a must otherwise we will have to conrinue dropping external tables.

Commented by: @hvlad

Again, does you tried FB 2.1 ?

Commented by: Robert Gilland (robert.gilland_basx.com.au)

There is no FB2.1 released.

Is there a schedule for a release of FB2.1 ?

Commented by: @hvlad

There are two betas of v2.1 released. Download beta2 or current snapshot and test it

Commented by: Robert Gilland (robert.gilland_basx.com.au)

The external file is not being released.

steps to reproduce

1. Create External file
2. Create External table
3. create stored procedure to import the external table
4. run stored procedure ( wait till finished )
5. call Windows.Deletefile to the original external file

result windows error

The process cannot access the file because it is being used by another process

This task should mean when the external table is not being accessed there should be no file handle open on it. But
firebird still has a file handle on it.

Using latest Firebird 2.1 beta to test with

Commented by: @hvlad

Sub-task CORE1647 was created for cached statement case.
I still see no value to duplicate CORE961 here and recommend to close this ticket

Commented by: Sean Leyne (seanleyne)

This is a duplicate case.

Unfortunately, this wasn't caught earlier. This case will be closed and a comment added to the earlier case to refer to this case for details.