Issue Details (XML | Word | Printable)

Key: CORE-961
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Maxim
Votes: 1
Watchers: 1

If you were logged in you would be able to see more operations.
Firebird Core

Free external tables

Created: 23/Oct/06 01:12 AM   Updated: 19/Jan/16 05:11 AM
Component/s: Engine
Affects Version/s: 2.0 RC4
Fix Version/s: 2.1 Beta 1

Environment: Windows XP, athlon xp 64, sata 80 gb, 512 RAM
Issue Links:

QA Status: No test

Sub-Tasks  All   Open   

 Description  « Hide
Firebird don't free external tables (files) after end transaction, where they was uses.
I need features, where firebird unlock external tables (files) after commit transaction which they was uses.
Thank you.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Fergus McDonald added a comment - 05/Jan/07 02:29 PM
This would make external tables far more useful, particularly if you're using them as a way to import external data.. for example, if you want some other process ont he server to create the file, and then have firebird access it via external table.

Vlad Khorsun added a comment - 19/Mar/07 11:54 PM
External table's file will be closed when relation is not used by the engine.
I.e. when all requests referencing this relation are freed

Robert Gilland added a comment - 10/Dec/07 08:14 PM
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 Firebird 2.1 beta to test with

Vlad Khorsun added a comment - 11/Dec/07 04:32 AM
Read coment above - "External table's file will be closed when relation is not used by the engine". And this is worked as written.
But procedure's request is not closed by the engine until procedure is in metadata cache.
We'll look at it in v2.5

And don't post the same comment in two tickets, please

Robert Gilland added a comment - 11/Dec/07 05:16 PM
No one is using the external file because the stored procedure is finished it's task.
Not sure what you mean by metadata cache.

So then how can I delete the original external file?
Currently I have a work around thankfully I can truncate the external file and rebuild upon it.

Vlad Khorsun added a comment - 11/Dec/07 05:37 PM
When you execute procedure first time engine reads it metadata from disk, compiles BLR into execution tree and remembers (cached) this info as compiled request. This compiled request remains in metadata cache until shutdown or drop\alter procedure. Therefore this request didn't release its interest in used resources (tables, indexes, procedures etc) and engine don't closed external table's file.

If you would work with external tables not via procedures, engine (since v2.1) will close external table's file as soon as all interested requests are closed by your application.

So as workaround you may use EXECUTE BLOCK instead of stored procedures for work with external tables in v2.1.
Not perfect, i know, but we can't improve this in v2.1 as it is at near release candidate state.

If you did this report at beta1 stage i sure we would fix it at that time.