Thanks Helen
in the meantime we managed to solve our problem by deleting the rows (just
as you recommended it).
I agree with you for the persistent table, and we will certainly implement
this in a long run. But at the moment we have to keep the stuff running, so
we just add the <delete> and it works on both DBMSs.
Thanks again
Klaus




Helen Borrie
<helebor@... An: ib-support@yahoogroups.com
.au> Kopie:
Thema: Re: [ib-support] Dropping table from application
24.10.2002 12:01
Bitte antworten
an ib-support
Telefon:







At 09:13 AM 24-10-02 +0000, you wrote:

>Hi there
>
>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.

If the table keeps on growing, it means an application (or a transaction)
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 are
>running FireBird 1.0 as local server under Win2000, WinNT, usually
>single user.
>
>Thanks for any suggestion.

Single user or multiple, an unfinished transaction won't go away until the
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



To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/