CODEWITHSUNDEEP
sql-servertemp-tablestable-locking
jreed121
jreed121

Reputation: 2097

In MS SQL Server 2005, what happens when a temp table is being accessed by different executions of the same SP?

I have a stored procedure that first checks for a temp table (#temp_table), deletes it if it exists, uses the table, then finally drops it when it's done. This SP is called randomly when a user does something to trigger it and it is likely that sometimes the SP will be executed at the same time - or with some overlap.

Lets say I have Exec1 and Exec2 both of the same SP creating, altering, and dropping the #temp table, and they are running within milliseconds of each other.

What happens? Will Exec1 lock the #temp_table and Exec2 waits while Exec1 finishes? That would obviously be desirable in my case. I wouldn't want both Exec1 & 2 to use the table at the sametime, nor would I want Exec2 fail because Exec1 is already using the table.

[EDIT] Should I just convert my temp table to a table variable?

Upvotes: 6

Views: 2224

Answers (3)

M.Ali
M.Ali

Reputation: 69524

In sql server if you create a local temp table it is with a single # sign sql server uses a few under-score and some ID in the back end. Say you create a Temp table with the name #Temp sql server in temp db Creates a Table with name #Temp_______10912098 , every Temp table created in separate connections will have their on ID in the end of the name.


TempTables

These are all the Temp Tables Created in different Connections all has the name #Temp but are appended with some underscores and a unique id sql server uses to differentiate between them.

Upvotes: 5

Ben
Ben

Reputation: 35613

Temp tables named with a hash # are specific to the individual connection.

So if two connections (also known as "processes" or "SPIDs") both reference a temp table by the same #tablename they will actually be referencing different tables.

You can see this if you look in tempdb. There will be multiple tables named things like #748B826C. These are in reality temporary table variables like declare @t table (ix int identity primary key) and temp tables name with a hash.

So provided these are different connections rather than recursive triggers, there should be no issue.

however if you are concerned about the possibility of recursive triggers you should use table variables instead. These are restricted to the scope of the batch or stored proc.

Upvotes: 3

Tom Chantler
Tom Chantler

Reputation: 14941

The scope of the temp table #table is limited to your session, so it should not be a problem.

If you used a ##table, then that's global and you would have issues.

See here: MSDN SQL Tables

Specifically this bit:

If a database session creates the local temporary table #employees, only the session can work with the table, and it is deleted when the session disconnects. If you create the global temporary table ##employees, any user in the database can work with this table. If no other user works with this table after you create it, the table is deleted when you disconnect. If another user works with the table after you create it, SQL Server deletes it after you disconnect and after all other sessions are no longer actively using it.

Upvotes: 4

Related Questions