6

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?

jreed121
  • 2,067
  • 4
  • 34
  • 57

3 Answers3

5

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.

M.Ali
  • 67,945
  • 13
  • 101
  • 127
  • 1
    So in my SP I have `IF OBJECT_ID('tempdb..#temp_table') IS NOT NULL DROP TABLE #temp_table` this does nothing then? Or could this potentially have an adverse impact on other executions? – jreed121 Oct 30 '13 at 00:06
  • 2
    You don't need that if you're calling it from a new session each time (e.g. from a web app), since the scope of the temp table is limited to the session. See my answer for more info. – Tom Chantler Oct 30 '13 at 00:08
  • 3
    You dont need that like Dommer said but its always a good practice to check for an OBJECT's Existence before you try to create it. keep that bit of code in your proc. – M.Ali Oct 30 '13 at 00:16
4

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.

Tom Chantler
  • 14,753
  • 4
  • 48
  • 53
3

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.

Ben
  • 34,935
  • 6
  • 74
  • 113