Is there any difference between stored procedure which uses global temporary table and one which does not in MS SQL database?
Global temporary table's scope is not limited to stored procedure, it can conflict with other procedures using same global temporary table(##TableName)
You can create Global temporary table in procedure, insert data and then see your data after store procedure execution.
Related
Like the question title, how can I do that? I'm using Oracle SQL.
begin
-- create temp table here
-- sql query
-- select temp table here
end;
You can create the Global temporary table outside the procedure and use it in your procedure.
The data in a global temporary table is private, such that data inserted by a session can only be accessed by that session. The session-specific rows in a global temporary table can be preserved for the whole session, or just for the current transaction.
You can learn more about GTT from here.
But, looking at your problem It seems that you can use the private temporary table, that can be created in your session by you and deleted(automatically) once the session/transaction is completed.
But it is available from Oracle 18c onwards.
You can learn more about Private temporary table from here.
I know #temp is temp. Table valid for particular session only. but if i define #temp in two different session, and run them simultaneously will that conflict. if no then how actually these tables are stored in memory. And how is that different from ##Temp?????
Temporary tables with a single # are "local", while those with a double ## are "global".
Local ones will drop out of scope once the stored procedure that defines them is done.
Global ones can be used by other users, or by the same user from different stored procedures, or by multiple calls of the same procedure. They will get dropped only after the last user that was referencing them is no longer referencing them, i.e. after the last stored proc is complete.
All are stored in the tempdb database; none in the "memory".
From CREATE TABLE
The full name of a temporary table as stored in the sysobjects table
in tempdb is made up of the table name specified in the CREATE TABLE
statement and the system-generated numeric suffix.
So it is stored in the tempdb.
Also from Temporary Tables in SQL Server
Temporary tables and table variables are created in the TempDB
database
I have a stored procedure inside which I am creating a temporary table.
My vb code will execute this stored procedure.
Is it possible to access the data in the temp table in vb6 after sp execution?
Use a global scope temporary table (they start with ## rather than #). These are shared between sessions. They go out of scope when the session that created them ends AND no other session is referring to them.
Temporary Tables in SQL Server
Creating and Modifying Table Basics
SQL Server 2005 and temporary table scope
Another option is a persistent temporary table (prefixed by TempDB..)
From Books Online:
A local temporary table created in a stored procedure is dropped
automatically when the stored procedure is finished. The table can be
referenced by any nested stored procedures executed by the stored
procedure that created the table. The table cannot be referenced by
the process that called the stored procedure that created the table.
A temporary table created within a Stored Procedure is dropped when the Stored Procedure ends, so the answer is no.
If you really want to share a temporary table with the caller, you could do something like the following:
Conditionally create the temporary table in your Stored Procedure if it doesn't already exist
CREATE PROCEDURE MyProcedure AS
...
if object_id('tempdb..#temp') is null
BEGIN
CREATE TABLE #temp
(...)
END
...
Whenever you want to access the temp table from your caller, you should create the temporary table before calling the stored procedure.
By creating the temporary table conditionally in the Stored Procedure, it will work whether or not the caller creates the temporary table. The caller must of course create the temporary table with the correct structure, and DROP it when finished (or close the DB connection).
An option I've used in the past is to create the temp table prior to calling the stored proc that uses it. As long as you use the same open adodb connection it should work:
myAdoDBConn.Execute "CREATE TABLE #foo (ID integer)", , adCmdText
myADODBConn.Execute "StoredProcThatPopulatesFoo", , adCmdStoredProc
myAdoRecordset.Open "Select ID FROM #foo", myAdoDbConn, adOpenForwardOnly, adLockReadOnly
Do While Not myAdoRecordset.EOF
// do something with the record //
myAdoRecordset.EOF
Loop
In this example, the temp table stays available until you close the connection (myAdoDbConn).
I have a long-lived connection, on which the application creates a temp table and uses it to fetch some dynamic runtime data. To my understanding it should be possible to reference this temp table as long as it is done on the same connection. It is possible indeed when I do a bunch of raw queries, but it is not possible with sprocs. I use ADO.NET.
Am I missing something obvious here?
Works
CREATE TABLE #CustomerNames (CustomerName nvarchar(200) PRIMARY KEY)
DECLARE #CustomerName nvarchar(200)
SET #CustomerName ='Joe Baker'
INSERT INTO #CustomerNames (CustomerName) VALUES (#CustomerNames)
Doesn't work
EXEC customerNames_createTempTable
EXEC customerNames_addCustomerName 'Joe Baker'
where sprocs encapsulate the queries
EDIT: the solution is to create a temp table outside of a sproc using a query and then do all the manipulations with the table on the same connection using sprocs. This way the temp table doesn't go out of scope.
It's been a while since I worked with SQL Server, but as far as I know, temporary tables created within stored procedure only exist for the duration of the procedure execution. In other words, they are dropped when the procedure is finished.
The problem is the scope of validity of the temp tables. A temp table only exists inside the stored proc that creates the table and inside all the stored procs the first sproc is calling. So in your not working example the temp table is invalid after you call customerNames_createTempTable.
A solution is a global temp table. These temp tables are created with '#', e.g. ##CustomerNames. But beware: Global temporary tables are visible to all SQL Server connections. So you have to name them with a unique name.
BTW: It is good habit to explicitly drop the temp tables when you don't need them anymore.
I've read around the subject of temporary tables and scope and all the answers i've seen don't seem to talk about one of my concerns.
I understand that a local temporary table's scope is only valid withing the lifetime of a stored procedure or child stored procedures. However what is the situation with regard to concurency. i.e. if i have a stored procedure that creates a temporary table which is called from two different processes but from the same user/connection string, will that temporary table be shared between the two calls to that one stored procedure or will it be a case of each call to the stored procedure creates an unique temporary table instance.
I would assume that the temporary table belongs to the scope of the call to the stored procdure but i want to be sure before i go down a path with this.
Local temporary tables (start with #) are limited to your session; other sessions, even from the same user/connection string, can't see them. The rules for the lifetime depend on whether the local temporary table was created in a stored procedure:
A local temporary table that is created in a stored procedure is dropped when the procedure ends; other stored procedures, or the calling process, can't see them.
Other local temporary tables are dropped when the session ends.
Global temporary tables (start with ##) are shared between sessions. They are dropped when:
The session that created them ends
AND no other session is referring to them
This command can be handy to see which temporary tables exist:
select TABLE_NAME from tempdb.information_schema.tables
And this is handy to drop temporary tables if you're not sure they exist:
if object_id('tempdb..#SoTest') is not null drop table #SoTest
See this MSDN article for more information.
The temporary table will be accesible to the instance of the procedure that creates it
The following script
Exec ('Select 1 as col Into #Temp Select * From #Temp')
Exec ('Select 2 as col Into #Temp Select * From #Temp')
Returns
Col
1
Col
2
Not
Col
1
2
Or an error because the table already exists.
The temporary table will also be accesible by any 'child' procedures that the initial procedure runs as well.
You might also think about using table variables. They have a very well-defined scope, and they are sometimes faster than their temporary table counterparts. The only problem with table variables is that they cannot be indexed, so some performance could be lost despite their nature. Check here for some more information on the subject.