这是对您的问题稍作修改的答案。如果可以放弃对用户定义函数使用存储过程，则可以使用内联表值用户定义函数。这本质上是一个存储过程（将采用参数），它将表作为结果集返回；因此将与INTO语句一起放置。

这里有一篇关于它和其他用户定义函数的快速文章。如果仍然需要驱动存储过程，则可以用存储过程包装内联表值用户定义函数。存储过程在从内联表值用户定义函数调用select*时只传递参数。

例如，您可以使用一个内联表值用户定义函数来获取特定地区的客户列表：

CREATE FUNCTION CustomersByRegion 
(  
    @RegionID int  
)
RETURNS TABLE 
AS
RETURN 
  SELECT *
  FROM customers
  WHERE RegionID = @RegionID
GO

然后，您可以调用此函数来获取结果，例如：

SELECT * FROM CustomersbyRegion(1)

或执行SELECT INTO：

SELECT * INTO CustList FROM CustomersbyRegion(1)

如果仍然需要存储过程，则按如下方式包装函数：

CREATE PROCEDURE uspCustomersByRegion 
(  
    @regionID int  
)
AS
BEGIN
     SELECT * FROM CustomersbyRegion(@regionID);
END
GO

我认为这是获得理想结果的最“无黑客”的方法。它使用了现有的功能，因为它们的使用不会带来额外的复杂性。通过在存储过程中嵌套内联表值用户定义函数，您可以通过两种方式访问该功能。加实际SQL代码只有一个维护点。

已经建议使用OPENROWSET，但这不是OPENROWET函数的用途（摘自联机丛书）：

包括所有连接信息访问远程数据所需的来自OLE DB数据源。这方法是访问表，并且是一个一次性临时连接方法和使用OLE访问远程数据数据库。更频繁的参考OLE DB数据源，使用链接服务器。

使用OPENROWSET可以完成任务，但在打开本地连接和编组数据时会产生一些额外的开销。它也可能不是所有情况下的选项，因为它需要临时查询权限，这会带来安全风险，因此可能不需要。此外，OPENROWSET方法将排除使用返回多个结果集的存储过程。在单个存储过程中包装多个内联表值用户定义函数可以实现这一点。

Code

CREATE TABLE #T1
(
    col1 INT NOT NULL,
    col2 NCHAR(50) NOT NULL,
    col3 TEXT NOT NULL,
    col4 DATETIME NULL,
    col5 NCHAR(50) NULL,
    col6 CHAR(2) NULL,
    col6 NCHAR(100) NULL,
    col7 INT NULL,
    col8 NCHAR(50) NULL,
    col9 DATETIME NULL,
    col10 DATETIME NULL
)

DECLARE @Para1 int
DECLARE @Para2 varchar(32)
DECLARE @Para3 varchar(100)
DECLARE @Para4 varchar(15)
DECLARE @Para5 varchar (12)
DECLARE @Para6 varchar(1)
DECLARE @Para7 varchar(1)


SET @Para1 = 1025
SET @Para2 = N'6as54fsd56f46sd4f65sd'
SET @Para3 = N'XXXX\UserName'
SET @Para4 = N'127.0.0.1'
SET @Para5 = N'XXXXXXX'
SET @Para6 = N'X'
SET @Para7 = N'X'

INSERT INTO #T1
(
    col1,
    col2,
    col3,
    col4,
    col5,
    col6,
    col6,
    col7,
    col8,
    col9,
    col10,
)
EXEC [dbo].[usp_ProcedureName] @Para1, @Para2, @Para3, @Para4, @Para5, @Para6, @Para6

我希望这有帮助。请根据需要进行资格认证。

如果要在不首先声明临时表的情况下执行此操作，可以尝试创建用户定义函数而不是存储过程，并使该用户定义函数返回表。或者，如果要使用存储过程，请尝试以下操作：

CREATE TABLE #tmpBus
(
   COL1 INT,
   COL2 INT
)

INSERT INTO #tmpBus
Exec SpGetRecords 'Params'

这可以在SQL Server 2014+中完成，前提是存储过程只返回一个表。如果有人能为多张桌子找到这样的方法，我很想知道。

DECLARE @storedProcname NVARCHAR(MAX) = ''
SET @storedProcname = 'myStoredProc'

DECLARE @strSQL AS VARCHAR(MAX) = 'CREATE TABLE myTableName '

SELECT @strSQL = @strSQL+STUFF((
SELECT ',' +name+' ' + system_type_name 
FROM sys.dm_exec_describe_first_result_set_for_object (OBJECT_ID(@storedProcname),0)
FOR XML PATH('')
),1,1,'(') + ')'

EXEC (@strSQL)

INSERT INTO myTableName

EXEC ('myStoredProc @param1=1, @param2=2')

SELECT * FROM myTableName

DROP TABLE myTableName

这将从系统表中提取返回表的定义，并使用它为您构建临时表。然后，您可以如前所述从存储过程填充它。

还有一些变体也适用于动态SQL。

为了将存储过程的第一个记录集插入到临时表中，您需要了解以下内容：

只能将存储过程的第一行集插入到临时表中存储过程不能执行动态T-SQL语句（sp_executesql）您需要首先定义临时表的结构

以上内容看起来可能是限制，但IMHO完全有意义-如果您使用sp_executesql，则可以一次返回两列，一次返回十列，如果您有多个结果集，则不能将它们插入多个表中-您可以在一个T-SQL语句中的两个表中插入最大值（使用OUTPUT子句，不使用触发器）。

因此，问题主要是如何在执行EXEC之前定义临时表结构。。。进入。。。陈述

sys.dm_exec_descript_first_result_set_for_object系统.dm_exec_descript_first_result_setsp_describe_first_result_set

第一个处理OBJECT_ID，而第二个和第三个处理Ad-hoc查询。我更喜欢使用DMV而不是sp，因为您可以使用CROSSAPPLY同时为多个过程构建临时表定义。

SELECT p.name, r.* 
FROM sys.procedures AS p
CROSS APPLY sys.dm_exec_describe_first_result_set_for_object(p.object_id, 0) AS r;

此外，请注意system_type_name字段，因为它非常有用。它存储列完整定义。例如：

smalldatetime
nvarchar(max)
uniqueidentifier
nvarchar(1000)
real
smalldatetime
decimal(18,2)

在大多数情况下，您可以直接使用它来创建表定义。

因此，我认为在大多数情况下（如果存储过程符合某些条件），您可以轻松地构建动态语句来解决这些问题（创建临时表，将存储过程结果插入其中，对数据执行所需的操作）。

注意，在某些情况下，上面的对象无法定义第一个结果集数据，例如在执行动态T-SQL语句或在存储过程中使用临时表时。

另一种方法是创建一个类型，然后使用PIPELINED传递回对象。然而，这仅限于了解列。但它的优点是能够做到：

SELECT * 
FROM TABLE(CAST(f$my_functions('8028767') AS my_tab_type))