Issue Details (XML | Word | Printable)

Key: CORE-720
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Pavel Cisar
Votes: 31
Watchers: 16

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

Local temporary tables

Created: 17/Sep/03 12:00 AM   Updated: 12/Sep/16 11:57 PM
Component/s: Engine
Affects Version/s: None
Fix Version/s: None

SF_ID: 807942

 Description  « Hide
SFID: 807942#
Submitted By: pcisar

Allow for the definition of temporary tables which are only visible within the current connection context and which are deleted upon connection disconnect/lost.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alice F. Bird added a comment - 14/Jun/06 09:42 AM - edited
Date: 2004-05-24 12:53
Sender: agjedrus
Logged In: YES

great feature really usefull but with implementation like is done in MSSQL

Dejan Schild added a comment - 06/Nov/06 03:25 AM
It's really time to implement this feature, it's very needed for reporting,...

Maxim added a comment - 28/Jan/07 08:10 AM
Pleas see key core -961. May be is better to choose not context connections, and a context of transaction?

Vlad Khorsun added a comment - 28/Jan/07 08:26 AM
Maxim, how 'Free external tables' is related to the 'Temporary tables' ?
It seems you mixed two different things

Mirco Malaguti added a comment - 06/May/07 09:39 AM
Would be useful to declare the lifetime of the table, either the connection or the transaction in which the temporary table is created, e.g.:


Umberto Masotti added a comment - 13/Apr/09 09:33 AM
Maybe I've missed something, but if Fb 2.1 GTT solve completely this feature request, maybe it's time to close it.

Dmitry Yemanov added a comment - 13/Apr/09 09:40 AM
Global and local temporary tables are two different things. This ticket refers to the latter one.

Cosmin Apreutesei added a comment - 15/Apr/09 06:48 AM - edited
I second Mirco's idea -- otherwise procedures won't be re-entrant in the same connection and there's no easy way to make them so (you'd have to implement DROP IF EXISTS).

Cosmin Apreutesei added a comment - 15/Apr/09 06:58 AM - edited
On a second thought, this won't be enough for all cases (you can still call the same procedure in the same transaction twice and the CREATE will fail), so the best way is for them to apply the same lifetime rules as for local variables.

Or better yet, let us declare variables in the procedure body and apply full lexical scoping. It's just a feature request so any amount of fantasizing is allowed right?

Dmitry Yemanov added a comment - 15/Apr/09 07:10 AM
I don't think you need to apply your fantasy. The SQL committee had already decided everything we would implement.

Cosmin Apreutesei added a comment - 24/Jan/10 11:05 PM
> The SQL committee had already decided everything we would implement.

No good deed ever goes unpunished.

robert gilland added a comment - 15/Feb/15 10:59 PM - edited
I have just moved company after working with firebird since 2003, and being a major contributor to it.
My new company uses "SQL anywhere".
I cannot even begin to recommend Firebird to my new company unless this is implemented
An example of this is below:

ie. inside a stored procedure

  declare local temporary table Foo(
    FooCode char(10) null,
    ) on commit preserve rows;


Robert Gilland added a comment - 12/Sep/16 11:57 PM
You wouldn't believe I moved company again and have exactly the same issue.
The critical need for local temporary tables and hash tables