The INSERT\EXEC
pattern has issues (not listed here - google it), so if you choose that path make sure your happy with those caveats.
My goto pattern for this kind of thing (and is usually part of some large data processing) is to create a known temp table structure. In SQL Server you can access a temporary table in a child procedure that is defined in a parent.
So this is a typical example :
CREATE PROCEDURE [dbo].[ChildProc]
AS BEGIN
IF OBJECT_ID('tempdb..#JsonDataBatch') is null BEGIN
PRINT 'ChildProc Stored Procedure is designed to called from another stored proc defining #JsonDataBatch temp table';
THROW 61000, 'Stored Procedure is designed to called from another stored proc (Missing #JsonDataBatch temp table)',1
CREATE TABLE #JsonDataBatch (
RecordId bigint NOT NULL,
JSONData varchar(max) NOT NULL,
PRIMARY KEY CLUSTERED (RecordId)
)
END
INSERT INTO #JsonDataBatch (RecordId, JSONData)
VALUES (1, '{}'),
(2, '{}'),
(3, '{}'),
(4, '{}');
END
GO
CREATE PROCEDURE [dbo].[ParentProc]
AS BEGIN
CREATE TABLE #JsonDataBatch (
RecordId bigint NOT NULL,
JSONData varchar(max) NOT NULL,
PRIMARY KEY CLUSTERED (RecordId)
)
EXEC [dbo].[ChildProc]
-- #JsonDataBatch table now has data
SELECT * FROM #JsonDataBatch
END
GO
EXEC [dbo].[ParentProc]
The IF Block at the top of the child procedure isn't strictly necessary for this pattern to work, however it serves two purposes :
- To document the behavior and ensure the child procedure is being called correctly
- So that intellisence in SQL Server Management Studio works.