How do I do a SELECT * INTO [temp table] FROM [stored procedure]
? Not FROM [Table]
and without defining [temp table]
?
Select
all data from BusinessLine
into tmpBusLine
works fine.
select *
into tmpBusLine
from BusinessLine
I am trying the same, but using a stored procedure
that returns data, is not quite the same.
select *
into tmpBusLine
from
exec getBusinessLineHistory '16 Mar 2009'
Output message:
Msg 156, Level 15, State 1, Line 2 Incorrect syntax near the keyword 'exec'.
I have read several examples of creating a temporary table with the same structure as the output stored procedure, which works fine, but it would be nice to not supply any columns.
This can be done in SQL Server 2014+ provided SP only returns one table. If anyone finds a way of doing this for multiple tables I'd love to know about it.
This pulls the definition of the returned table from system tables, and uses that to build the temp table for you. You can then populate it from the SP as stated before.
There are also variants of this that work with Dynamic SQL too.
If you know the parameters that are being passed and if you don't have access to make sp_configure, then edit the stored procedure with these parameters and the same can be stored in a ##global table.
Well, you do have to create a temp table, but it doesn't have to have the right schema....I've created a stored procedure that modifies an existing temp table so that it has the required columns with the right data type and order (dropping all existing columns, adding new columns):
Note this won't work if sys.dm_exec_describe_first_result_set_for_object can't determine the results of the stored procedure (for instance if it uses a temp table).
If the OPENROWSET is causing you issues, there is another way from 2012 onwards; make use of sys.dm_exec_describe_first_result_set_for_object, as mentioned here: Retrieve column names and types of a stored procedure?
First, create this stored procedure to generate the SQL for the temporary
To use the procedure, call it in the following way:
Note that I'm using a global temporary table. That's because using EXEC to run the dynamic SQL creates its own session, so an ordinary temporary table would be out of scope to any subsequent code. If a global temporary table is a problem, you can use an ordinary temporary table, but any subsequent SQL would need to be dynamic, that is, also executed by the EXEC statement.
If you're lucky enough to have SQL 2012 or higher, you can use
dm_exec_describe_first_result_set_for_object
I have just edited the sql provided by gotqn. Thanks gotqn.
This creates a global temp table with name same as procedure name. The temp table can later be used as required. Just don't forget to drop it before re-executing.
In order to insert the first record set of a stored procedure into a temporary table you need to know the following:
sp_executesql
)The above may look as limitation, but IMHO it perfectly makes sense - if you are using
sp_executesql
you can once return two columns and once ten, and if you have multiple result sets, you cannot insert them into several tables as well - you can insert maximum in two table in one T-SQL statement (usingOUTPUT
clause and no triggers).So, the issue is mainly how to define the temporary table structure before performing the
EXEC ... INTO ...
statement.The first works with
OBJECT_ID
while the second and the third works with Ad-hoc queries as well. I prefer to use the DMV instead of the sp as you can useCROSS APPLY
and build the temporary table definitions for multiple procedures at the same time.Also, pay attention to the
system_type_name
field as it can be very useful. It stores the column complete definition. For, example:and you can use it directly in most of the cases to create the table definition.
So, I think in most of the cases (if the stored procedure match certain criteria) you can easily build dynamic statements for solving such issues (create the temporary table, insert the stored procedure result in it, do what you need with the data).
Note, that the objects above fail to define the first result set data in some cases like when dynamic T-SQL statements are executed or temporary tables are used in the stored procedure.