January 25, 2011 at 3:13 pm
Hello all,
I'm having a bit of a problem here. I need a proc that can make a variable number of temporary tables on the fly. It would have to take an input that tells it how many to make and then create them using a naming convention such as #temp1, #temp2, #temp3, etc.
Obviously my problem is that I would have to use dynamic SQL in which case the temp tables would go out of scope after the execute statement.
I would use global tables but I need to be able to access this proc concurrently from other sessions.
Any ideas on my options here?
January 25, 2011 at 3:21 pm
How about using a new database and creating uniquely named tables - perhaps include the SPID in the name
MM
select geometry::STGeomFromWKB(0x0106000000020000000103000000010000000B0000001000000000000840000000000000003DD8CCCCCCCCCC0840000000000000003DD8CCCCCCCCCC08408014AE47E17AFC3F040000000000104000CDCCCCCCCCEC3F9C999999999913408014AE47E17AFC3F9C99999999991340000000000000003D0000000000001440000000000000003D000000000000144000000000000000400400000000001040000000000000F03F100000000000084000000000000000401000000000000840000000000000003D0103000000010000000B000000000000000000143D000000000000003D009E99999999B93F000000000000003D009E99999999B93F8014AE47E17AFC3F400000000000F03F00CDCCCCCCCCEC3FA06666666666FE3F8014AE47E17AFC3FA06666666666FE3F000000000000003D1800000000000040000000000000003D18000000000000400000000000000040400000000000F03F000000000000F03F000000000000143D0000000000000040000000000000143D000000000000003D, 0);
January 25, 2011 at 5:19 pm
Have you considered doing something like this:
SELECT EntryId, Entry, Description
INTO #T
FROM logentries
The INTO statement will create the temporary table.
January 25, 2011 at 10:02 pm
Ron, I don't think this would work for my situation b/c the table would still be created in the scope of the exec statement if I were to use dynamic sql to generate names.
I need something that would let me either create the tables in the same scope as my stored procedure or some other way to create table names on the fly.
January 26, 2011 at 12:32 am
mister.magoo (1/25/2011)
How about using a new database and creating uniquely named tables - perhaps include the SPID in the name
This sounds like an excellent idea. I'm not sure that a new database would be necessary.
Edit: A permanent table would allow the procedure to create the table dynamically, then use it.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
January 26, 2011 at 7:48 am
Okay, it seems a permanent table could be used with session IDs appended.
What are the I/O implications with this though? This will be put on a server with some heavy traffic from multiple clients. I'm afraid that the performance may take a big hit using permanent tables.
January 26, 2011 at 8:16 am
ntran777 (1/25/2011)
I need a proc that can make a variable number of temporary tables on the fly.
I would be interested in knowing why you need to do this. It may be that there are better ways around the problem.
eg If the tables have the same structure you could create one temporary table with the addition of a SetNumber column.
January 26, 2011 at 8:40 am
I'm creating a table for reporting that has too many columns in it to return as one. The rows go over SQL's 8060b limit. To solve this, I'm gathering the data into smaller tables and joining them together for the application to use. I don't know how many tables will need to be created. It depends on how many columns the particular customer has defined.
January 27, 2011 at 10:28 am
ntran777 (1/26/2011)
I'm creating a table for reporting that has too many columns in it to return as one. The rows go over SQL's 8060b limit. To solve this, I'm gathering the data into smaller tables and joining them together for the application to use. I don't know how many tables will need to be created. It depends on how many columns the particular customer has defined.
How about using dynamic SQL to create the stored procedure which creates and uses the temp tables?
- Les
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply