[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1828
  • Last Modified:

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....
0
rmaranhao
Asked:
rmaranhao
  • 3
  • 3
1 Solution
 
szacksCommented:
use a # sign in front of the table and it will only be available to the connection that created it.

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.
0
 
poliguinCommented:
use a table variable

syntax:

DECLARE @MyTable Table(AnID INT, AValue VARCHAR(255))

INSERT INTO @MyTable SELECT ........


SELECT AnID, AVALUE FROM @MyTable
0
 
poliguinCommented:
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.
0
The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

 
szacksCommented:
poliguin,

You are incorrect. If you open Query Analyzer for example and type create table #table1  and then open a second query window in QA and type create table #table1 it will create 2 tables that have no relationship to one another.
This is true in stored procedures as well, it's just very easy to test it in QA.
The way that # tables are handled by the database is they are created in the tempdb with somesort of unique identifier attached to the table name which is automatically handled by the engine wqhen you use the table name.
0
 
rmaranhaoAuthor Commented:
szacks, you are perfecly correct.

Just one more doubt: I the connection is lost, how do I drop this table?
0
 
poliguinCommented:
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.
0
 
szacksCommented:
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.
0

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now