July 5, 2013 at 6:34 am
Ive noticed dudes in this forum uses # for the first letter of their table names.
Does it have any special meaning?
Does SQL Server have different behavior with them?
Or its just a letter like a,b,c... etc?
___________________________________
Computer Enterprise Masoud Keshavarz
I don't care about hell.
If I go there I've played enough Diablo to know how to fight my way out.
July 5, 2013 at 6:50 am
These are temporary tables.
Basically it means they are stored in tempdb (one of the system databases) and are dropped when the connection is terminated or when SQL Server is restarted.
They behave like any other table, so you can create them with CREATE TABLE #myTempTable or with SELECT ... INTO #myTempTable.
You can use ALTER TABLE and add indexes if you want.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
July 5, 2013 at 6:53 am
masoudk1990 (7/5/2013)
Ive noticed dudes in this forum uses # for the first letter of their table names.Does it have any special meaning?
Does SQL Server have different behavior with them?
Or its just a letter like a,b,c... etc?
#table is a temporary table...it's one that you can create on the fly, and it gets destroyed automatically when your connection is closed.
SELECT name
INTO #temp
from sys.tables
they are real tables, and are unique to the processes/scope that created them...so a procedure which creates a temp table can be called thousands of times per second, and each instance of the procedure creates it's own temp table, called #temp or whatever, but that do not collide with any other process creating temp tables by the same name.
technically, a table gets created with a unique name in tempdb, and it might actually be called the same name, but with a unique number appended to the end of it;
see for yourself:
select POWER(convert(bigint,2),31) as val into #temp
select name from tempdb.sys.tables where name LIKE '#temp%'
--#temp__{snip}__000000000006
Lowell
July 5, 2013 at 6:55 am
When you put a # sign in front of the table name, the table will be created in [tempdb] database. This table will be only available within your current session and is called a local temporary table. When your session is ended, the temporary table will be automaticly removed.
If you put a double # sign in front of the table name, the table will also be created in [tempdb] database and is called a global temporary table. This table will be available from within other sessions.
From MSDN:
Temporary Tables
--------------------------------------------------------------------------------
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.
July 5, 2013 at 6:55 am
select POWER(convert(bigint,2),31) as val into #temp
I see what you did there 😉
Recycling is good for the environment 😀
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
July 5, 2013 at 7:06 am
Koen Verbeeck (7/5/2013)
select POWER(convert(bigint,2),31) as val into #temp
I see what you did there 😉
Recycling is good for the environment 😀
haha! cannot put anything past you! at least i didn't plagiarize!
Lowell
July 5, 2013 at 8:02 am
Thank you every one.
If you put a double # sign in front of the table name, the table will also be created in [tempdb] database and is called a global temporary table. This table will be available from within other sessions
Thank you for extra information.
@Koen Verbeeck
I see what you did there [Wink]
Recycling is good for the environment [BigGrin]
What did Lowell do?
You made me afraid to test his query.
___________________________________
Computer Enterprise Masoud Keshavarz
I don't care about hell.
If I go there I've played enough Diablo to know how to fight my way out.
July 5, 2013 at 8:18 am
select POWER(convert(bigint,2),31) as val into #temp
he was referencing another thread, where someone asked for the max size of a varchar(max);
that thread is here:
http://qa.sqlservercentral.com/Forums/Topic1470699-391-1.aspx
i reused my same code example from that thread, but inserted it into a #temp table to show you how to use a temp table;
he was referring to the fact that he noticed the same code in the other thread.
it was just a for-fun notification that he sees everything.
Lowell
July 5, 2013 at 10:27 am
Lowell (7/5/2013)
it was just a for-fun notification that he sees everything.
That's true. So you better watch out!
(maybe I'll add an off-topic warning next time, to not confuse anyone else)
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
July 9, 2013 at 8:16 am
HanShi mentioned local and global temp tables. You don't see this as often but a global temp table has two numbers signs in front of it like so: ##temptable.
To get some understanding about the difference between the two, open a new query window in SSMS and run these SELECT statements:
CREATE TABLE #LocalTempTable (xId int); --(1) Local Temp Table
CREATE TABLE ##GlobalTempTable (xId int); --(2) Global Temp Table
INSERT INTO #LocalTempTable VALUES(1);
INSERT INTO ##GlobalTempTable VALUES(1);
Then, in the same query window, you could successfully run these queries:
SELECT * FROM ##GlobalTempTable
SELECT * FROM #LocalTempTable
If you open a new query window, however, and run the two SELECT statements above, the first will be successful but the second one will fail.
-- Itzik Ben-Gan 2001
July 9, 2013 at 8:29 am
A good programming practice is to always drop your temporary stuff in the procedure when you're done. I know they're supposed to be destroyed when the session terminates, but I sometimes see shrapnel left over when people don't drop them.
Dropping them also makes developing your procedures easier because you can't create them if they already exist. Knowing that they're local to my session, I still like to use the following approach before creating a temp table.
IF OBJECT_ID('tempdb.dbo.#temp_table', 'U') IS NOT NULL DROP TABLE #temp_table;
July 9, 2013 at 9:16 am
Ed Wagner (7/9/2013)
A good programming practice is to always drop your temporary stuff in the procedure when you're done. I know they're supposed to be destroyed when the session terminates, but I sometimes see shrapnel left over when people don't drop them.Dropping them also makes developing your procedures easier because you can't create them if they already exist. Knowing that they're local to my session, I still like to use the following approach before creating a temp table.
IF OBJECT_ID('tempdb.dbo.#temp_table', 'U') IS NOT NULL DROP TABLE #temp_table;
interestingly, there's quite a few threads here, where it's shows that if you explicitly drop tables at the end of your procedure, you incur a slight performance cost over letting SQL destroy the tables automatically.
now if you are creating a script, i 100% agree,bullet proof your code and drop them before you (re-)create them, just in case.
Lowell
July 9, 2013 at 9:32 am
Alan.B (7/9/2013)
HanShi mentioned local and global temp tables. You don't see this as often but a global temp table has two numbers signs in front of it like so: ##temptable.To get some understanding about the difference between the two, open a new query window in SSMS and run these SELECT statements:
CREATE TABLE #LocalTempTable (xId int); --(1) Local Temp Table
CREATE TABLE ##GlobalTempTable (xId int); --(2) Global Temp Table
INSERT INTO #LocalTempTable VALUES(1);
INSERT INTO ##GlobalTempTable VALUES(1);
Then, in the same query window, you could successfully run these queries:
SELECT * FROM ##GlobalTempTable
SELECT * FROM #LocalTempTable
If you open a new query window, however, and run the two SELECT statements above, the first will be successful but the second one will fail.
Much appreciated, very good example
___________________________________
Computer Enterprise Masoud Keshavarz
I don't care about hell.
If I go there I've played enough Diablo to know how to fight my way out.
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply