I was wondering, what is the difference between these two scripts?
SELECT * FROM ##TEMP
and this
SELECT * FROM #TEMP
##TEMP is global temporary table, #TEMP is local.
Local temporary tables are visible only to their creators during the same connection to an instance of SQL Server as when the tables were first created or referenced. Local temporary tables are deleted after the user disconnects from the instance of SQL Server.
Global temporary tables are visible to any user and any connection after they are created, and are deleted when all users that are referencing the table disconnect from the instance of SQL Server.
see documentation.
Actually here is almost the same question with answer - Local and global temporary tables in SQL Server.
The first one (##TEMP) is global - anyone can access it's content and also you can from different sessions (think of tabs in SQL Server Management Studio). The other is only visible by you.
## are global tables which are visible to everyone and are deleted when all the connections that are referencing them are closed.
# are local tables that is visible to only the connection that has created it and are deleted once that connection has been disconnected.
Related
I am using ADO.NET to connect SAP HANA database. I enable connection pooling in connection string like this: Server=hana-db:30015;Pooling=true;Max Pool Size=50;Min Pool Size=5;UserID=JSmith;Password=secret. But my problem is that, when I first connect to database and create a temporary table called #tbl, then disconnect without dropping #tbl. And when I reconnect to database, table #tbl still exists.
That doesn't happen when I set Pooling=false. So when Pooling=true, do I need manual drop temporary tables? Cause in MSSQL or Postgresql, temp tables dropped automatically when connection closed.
I believe in MSSQL it only drops the temp table on connection close when it's inside of a Stored Procedure. If your query is outside of a SP you will need to drop the temp tables yourself.
I'm currently trying to determine possible issues with creating temporary tables from a web application and how SQL Server naturally determines separate sessions.
SELECT blabla, lala FROM table INTO #TempTable
SELECT blabla FROM #TempTable
DROP TABLE #TempTable
In the above, while one user of a web application is waiting for the second line to execute, and another user fires off the same 3 lines, what would determine whether the 2nd user gets a "Object already exists" or else a new #TempTable is created for that user.
If each user was on a separate computer on the same network, would SQL server treat this as separate sessions and thus create separate temporary tables.
What about if it is run on the same computer on two different networks?
Each user connection to the database is it own session. These sessions are unique even if you're using connection pooling within SQL Server. Behind the scenes, SQL Server appends each #tempTable with a single session reference number, so they technically aren't even named the same thing during execution.
If the root of your problem is an error message about the object already existing when you are debugging. Try adding the code snippet below before you create the temp table:
IF OBJECT_ID('[tempdb]..[#tempTable]') IS NOT NULL
BEGIN
DROP TABLE #tempTable
END
SQL Server does not determine separate sessions.
It is a client application who create sessions. You can write an application where all traffic to the database use single connection (not so easy) or a separate connection is created for each page (common mistake). Both of the solutions are pretty bad.
In proper design you should use connection pooling and your code should reserve connections from the connection pool as needed.
Even if you are using connection pooling, it is possible that each command is executed on a different connection from the pool.
I have a stored procedure in SQL Server in which I am creating couple of temp tables within and manipulating them as per my business logic and at the end I’m deleting those temp tables by using drop table query in the procedure itself.
I have a question, if multiple users are operating at the same time the what will be the case of temp tables? Will it provide multiple instances as sessions in asp.net or only one instance will be available for all users?
Please suggest a good approach for this.
Local temporary tables:
are visible only to the current connection for the user, and they are
deleted when the user disconnects from the instance of SQL Server
If your ASP.NET application creates a separate connection for each user request, then each connection will have its own temporary tables - they won't be shared with other users.
After a user is logged into his system and opens my progamm he can see data from a database depending on his WindowsUsername(I wrote a little stored procedure for that).
This Data comes from a query with a temporary Table (#temp). My question is now, if many users use this programm, after opening it they would all try to build the #temp Table within the stored procedure. Is that even possible?? Because if i try to build a tempTable with the same name the server gives me an error. Do i have to give dynamic TempTable names maybe according to the user who is logged in??? Or is there another better option?
MS-SQL Server
A local temp table (one #TableName) is per session/connection
Many users can not share a session/connection
So, a local temp table in a stored procedure is safe for may concurrent users
On the other hand you use a global temp table (##TableName) then it is visible to world+dog
From MSDN (my bold)
There are two types of temporary tables: local and global. Local temporary tables are visible only to their creators during the same connection to an instance of SQL Server as when the tables were first created or referenced. Local temporary tables are deleted after the user disconnects from the instance of SQL Server. Global temporary tables are visible to any user and any connection after they are created, and are deleted when all users that are referencing the table disconnect from the instance of SQL Server.
If it is a true temp table within a stored procedure (SP) then the temp table is created/only exists during the execution of the SP. If the sp is run multiple times by multiple users at the same time the temp table is created multiple times and stored in its own memory space for each user.
The results returned to each user will be unique and each copy of the temp table will not see the temp table from other sp calls.
If you are testing in a query window by creating the temp table twice then you will get an error.
To prove that the above works schedule the SP to run twice at the same time passing a different user id. You will get two different result sets.
I have a vb.net app , and I am creating and dropping temp tables. I just want to know whether the temp tables created programatically from some client app will get dropped automatically with dispose of application or we should have to drop it explicitly by code.
I need to be sure that all tables will get dropped when I close my app or that block has been executed successfully.
Right now I am dropping using drop table .... I need code to check existing temp table in sql server and drop them all at a time on form close.
I hope my lines are clear.
Environment is VB.Net + Sql Server 2008
Local Temp tables are disposed of when the session closes.
Global temp tables (with ## prefix) are dropped off when the last connection using it closes.