Subject | Re: [ib-support] Dropping table from application |
---|---|
Author | Helen Borrie |
Post date | 2002-10-24T10:01:06Z |
At 09:13 AM 24-10-02 +0000, you wrote:
is still using it. Firebird won't let you drop an object that is in
use. (Note that it will continue to be in use as long as there are any
uncommitted transactions containing statements that relate to it, either
directly or through dependencies).
[snipped code]
server is shut down.
Creating and destroying tables for temporary use is not a recommended
approach for IB/Fb. (You *can* do it but it's a bad idea; in some DBMSs
you *have* to have temp table creation and destruction readily available
because they are incapable of producing record sets from stored procedures
in any other fashion...)
If an application needs temporary storage on the server, one commonly
defines a persistent table of the required structure, including a key to
identify a set of rows written by a particular user for a particular
task. Cleanup is by deleting (or, preferably, disabling) that set of
rows; and regular housekeeping prior to backups can clear out obsolete rows.
If you *must* do this, about all I can recommend is that you ensure that
your cleanup code commits or rolls back *all* transactions before
attempting to delete the table. The actual deletion may still be deferred
under some conditions, so it may still be impossible to create another
instance of the table without shutting down and restarting.
Not much help to you, I suppose....
heLen
>Hi thereIf the table keeps on growing, it means an application (or a transaction)
>
>in our application we create and drop a table which we need for
>temporary use. Apparently, the drop doesn't work, since the table
>keeps on growing, unless we disconnect from the database.
is still using it. Firebird won't let you drop an object that is in
use. (Note that it will continue to be in use as long as there are any
uncommitted transactions containing statements that relate to it, either
directly or through dependencies).
[snipped code]
>Compiler is Borland 5.0.2 using RogueWave db.hxx libraries. We areSingle user or multiple, an unfinished transaction won't go away until the
>running FireBird 1.0 as local server under Win2000, WinNT, usually
>single user.
>
>Thanks for any suggestion.
server is shut down.
Creating and destroying tables for temporary use is not a recommended
approach for IB/Fb. (You *can* do it but it's a bad idea; in some DBMSs
you *have* to have temp table creation and destruction readily available
because they are incapable of producing record sets from stored procedures
in any other fashion...)
If an application needs temporary storage on the server, one commonly
defines a persistent table of the required structure, including a key to
identify a set of rows written by a particular user for a particular
task. Cleanup is by deleting (or, preferably, disabling) that set of
rows; and regular housekeeping prior to backups can clear out obsolete rows.
If you *must* do this, about all I can recommend is that you ensure that
your cleanup code commits or rolls back *all* transactions before
attempting to delete the table. The actual deletion may still be deferred
under some conditions, so it may still be impossible to create another
instance of the table without shutting down and restarting.
Not much help to you, I suppose....
heLen