views:

67

answers:

2

In Oracle, you can create a temp table using something like:

CREATE GLOBAL TEMPORARY TABLE temp_table (
    field1 NUMBER,
    field2 NUMBER
)
ON COMMIT DELETE ROWS;

... which could be pretty nifty, as this creates a table visible to everyone, but the data one INSERTs into the table is visible only to him or her. Additionally, that data is automatically deleted on at the end of the transaction or the session (depending on its declaration), leaving everyone else's temporary data unharmed.

In SQL Server, however, you can create a temp table with:

CREATE TABLE #temp_table (field1 INT, field2 INT);

... which, as I understand it, is substantially and functionally different than Oracle's implementation. This temp table is visible only to you, and is dropped (the table) immediately after use.

Is there any capacity in SQL Server to mimic the Oracle behavior as described above? Or is the only way to work with temporary data involve having to repeatedly CREATE the temp table with each iteration of work?

+6  A: 

As you have discovered SQL Server & Oracle temporary tables are fundamentally different.

In Oracle global temporary tables are permanent objects that store temporary session specific (or transaction specific) data.

In SQL Server temporary tables are temporary objects storing temporary data, with #temp_tables storing data that is local to a session and ##temp_tables storing data that is global. (I have never had a need for SQL Server global temp tables and don't know what problem they solve.) If the #temp_table was created in a stored procedure it will be dropped when the stored procedure exits. Otherwise it will be dropped when the session closes.

And no, there really isn't a way to make SQL Server mimic Oracle. You could use a normal table with an extra column storing a session ID. But you wouldn't get the advantages of temp tables with respect to less logging. You'd have to manually delete the temp data. And deal with cleaning up from sessions that quit prematurely.

EDIT: Another difference between Oracle and SQL Server is that SQL Server allows DDL to be wrapped in a transaction with other statements. So if you need to use a temp table as part of a larger transaction, the create table #table_name... statement will not implicitly commit the current transaction like a create table statement would in Oracle.

Shannon Severance
@Shannon ~ likewise, I couldn't get my head around SQL Server ##temp_tables as well. :) Admittedly, I'd rather have an implementation as per Oracle's, but if that's simply not possible in SQL Server, then your suggestion/s seem to make the most sense. Thanks! +1
Richard Neil Ilagan
I have a coworker who has found a use for ##temp_tables - he uses SSIS for some processes and if you use ## in one proc, and that proc calls another proc, proc#2 can use the ##temp_table.
sql_mommy
@sql_mommy: I had a coworker who did a similar thing, in that they were using ##tables to use accross procs. However, they had no way of stopping the end users from kicking off the same process while someone else was already running, so ran the risk that the work from the two users would get mixed together in the global temp table. We moved the temp table definitions to the top proc, so all called procs could see them and made them local temp tables. For SSIS, if it is a batch process that is kicked off by a job, probably OK.
Shannon Severance
A: 

This is off topic but did you know that in SQL Server you can create a temp table like this:

select *
into #temp_table
from mytable
codingguy3000
Yup, I did. Thanks for pointing it out nonetheless.
Richard Neil Ilagan