rmaranhao
asked on
Temporary table visible only to the connection that created it
I HEARD the noise but don't know where it came from.....
Is it possible to create a table in MSSQL that will be visible only to the connection that created it? What I want is a place to store information and manipulate it with the SQL language but I need to protect it so that I can have several copies running at the same time and each copy visible only to its client.
I can achieve it using permanent tables but this possibility is exactly what I need....
So if you can assure me that I can't do it, it will still be a valid answer....
Is it possible to create a table in MSSQL that will be visible only to the connection that created it? What I want is a place to store information and manipulate it with the SQL language but I need to protect it so that I can have several copies running at the same time and each copy visible only to its client.
I can achieve it using permanent tables but this possibility is exactly what I need....
So if you can assure me that I can't do it, it will still be a valid answer....
use a table variable
syntax:
DECLARE @MyTable Table(AnID INT, AValue VARCHAR(255))
INSERT INTO @MyTable SELECT ........
SELECT AnID, AVALUE FROM @MyTable
syntax:
DECLARE @MyTable Table(AnID INT, AValue VARCHAR(255))
INSERT INTO @MyTable SELECT ........
SELECT AnID, AVALUE FROM @MyTable
a note,
using CREATE #MyTable(....) will create a table that is accessible by the database. if someone connects to the while someone is still in the stored procedure, you will get an error that states a table of name #MyTable already exists. using a table variable allows you to not worry about that table already existing, for it's lifespan is unique to the execution of the stored procedure and many people can fire the same sp with a table variable at the same time or within the same execution time. you can't do so with CREATE TABLE #MyTable(...). a table variable works just like a regular table too.
using CREATE #MyTable(....) will create a table that is accessible by the database. if someone connects to the while someone is still in the stored procedure, you will get an error that states a table of name #MyTable already exists. using a table variable allows you to not worry about that table already existing, for it's lifespan is unique to the execution of the stored procedure and many people can fire the same sp with a table variable at the same time or within the same execution time. you can't do so with CREATE TABLE #MyTable(...). a table variable works just like a regular table too.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
szacks, you are perfecly correct.
Just one more doubt: I the connection is lost, how do I drop this table?
Just one more doubt: I the connection is lost, how do I drop this table?
i stand corrected on that, i genearlly always run the same instance of qa, so never really noticed that before.
notes about usage of table variables (As taken from books online)
Use table variables instead of temporary tables, whenever possible. table variables provide the following benefits:
A table variable behaves like a local variable. It has a well-defined scope, which is the function, stored procedure, or batch in which it is declared.
Within its scope, a table variable may be used like a regular table. It may be applied anywhere a table or table expression is used in SELECT, INSERT, UPDATE, and DELETE statements. However, table may not be used in the following statements:
INSERT INTO table_variable EXEC stored_procedure
SELECT select_list INTO table_variable statements.
table variables are cleaned up automatically at the end of the function, stored procedure, or batch in which they are defined.
table variables used in stored procedures result in fewer recompilations of the stored procedures than when temporary tables are used.
Transactions involving table variables last only for the duration of an update on the table variable. Thus, table variables require less locking and logging resources.
Assignment operation between table variables is not supported. In addition, because table variables have limited scope and are not part of the persistent database, they are not impacted by transaction rollbacks.
notes about usage of table variables (As taken from books online)
Use table variables instead of temporary tables, whenever possible. table variables provide the following benefits:
A table variable behaves like a local variable. It has a well-defined scope, which is the function, stored procedure, or batch in which it is declared.
Within its scope, a table variable may be used like a regular table. It may be applied anywhere a table or table expression is used in SELECT, INSERT, UPDATE, and DELETE statements. However, table may not be used in the following statements:
INSERT INTO table_variable EXEC stored_procedure
SELECT select_list INTO table_variable statements.
table variables are cleaned up automatically at the end of the function, stored procedure, or batch in which they are defined.
table variables used in stored procedures result in fewer recompilations of the stored procedures than when temporary tables are used.
Transactions involving table variables last only for the duration of an update on the table variable. Thus, table variables require less locking and logging resources.
Assignment operation between table variables is not supported. In addition, because table variables have limited scope and are not part of the persistent database, they are not impacted by transaction rollbacks.
Thank you for posting that comment on the usage of table variables. I have never used them before, but it seems like they are worth looking into.
One of the beauties of temporary tables is that the database deals with the clean up for you. You do not have to drop a temporary table, though it is considered good form to do so.
The tempdb is specifically made to handle things like this.
One of the beauties of temporary tables is that the database deals with the clean up for you. You do not have to drop a temporary table, though it is considered good form to do so.
The tempdb is specifically made to handle things like this.
example: create table #table1(F1 int, F2 int)
then you would use normal syntax with it. select * from #table1 you can even add indexes and stuff.