Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Temp Table usuage in a Multi User Environment

here's the situation:

I have an SSRS report that uses an SP as a Dataset. The SP creates a Temp Table, inserts a bunch of data into it, and select's it back out for SSRS to report. Pretty straight forward.

Question:

If multiple users run the report with different parameters selected, will the temp table created by the SP collide in the tempdb and potentially not return the data set expected?

like image 354
tmercer Avatar asked Jan 18 '11 15:01

tmercer


People also ask

What are temporary tables when are they useful?

What is a temp table? As its name indicates, temporary tables are used to store data temporarily and they can perform CRUD (Create, Read, Update, and Delete), join, and some other operations like the persistent database tables.

Can temporary tables be used in a user defined function?

Temporary Tables are not allowed in User Defined Functions, whereas Table Variables can be used in User Defined Functions.

What is the advantage of using a temporary table instead of a table?

Temporary tables behave just like normal ones; you can sort, filter and join them as if they were permanent tables. Because SQL Server has less logging and locking overheads for temporary tables (after all, you're the only person who can see or use the temporary table you've created), they execute more quickly.

Which is faster CTE or temp table?

Looking at SQL Profiler results from these queries (each were run 10 times and averages are below) we can see that the CTE just slightly outperforms both the temporary table and table variable queries when it comes to overall duration.


2 Answers

Most likely not. If the temp table is defined as #temp or @temp, then you're safe, as those kind of temp tables can only be accessed by the creating connection, and will only last for the duration of the execution of the stored procedure. If, however, you're using ##temp tables (two "pound" signs), while those tables also only last for as long as the creating stored procedure runs, they are exposed to and accessible by all connections to that SQL instance.

Odds are good that you're not using ##tables, so you are probably safe.

like image 54
Philip Kelley Avatar answered Nov 17 '22 00:11

Philip Kelley


A temp table with a single # is a local temporary table and its scope is limited to the session that created it, so collisions should not be a problem.

like image 45
Joe Stefanelli Avatar answered Nov 17 '22 00:11

Joe Stefanelli