The TRY...CATCH block is causing the execution of the stored procedure to terminate before it has a chance to return the values in #TEMP.
Try this stored proc:
IF OBJECT_ID('dbo.SomeProc') IS NOT NULL
DROP PROCEDURE dbo.SomeProc;
GO
CREATE PROCEDURE [dbo].[SomeProc]
AS
BEGIN
CREATE TABLE #TEMP
(
ID INT NOT NULL
);
INSERT INTO #TEMP
VALUES (1);
INSERT INTO #TEMP
VALUES (1/0);
PRINT (N'Run the SELECT');
SELECT ID
FROM #TEMP;
END
GO
Running it, like this, without a TRY...CATCH, allows all the statements in the proc to run:
EXEC dbo.SomeProc;
The output:
Msg 8134, Level 16, State 1, Procedure SomeProc, Line 12
Divide by zero error encountered.
The statement has been terminated.
Run the SELECT
However, if you run it inside a TRY...CATCH:
BEGIN TRY
EXEC dbo.SomeProc;
END TRY
BEGIN CATCH
PRINT (ERROR_MESSAGE());
END CATCH
You see only the error message:
Divide by zero error encountered.
The PRINT (N'Run the SELECT'); never runs, and indeed the SELECT ID FROM #TEMP; never runs either. Hence no rows are returned, and nothing can be inserted into your #TEMPTABLE
From the MSDN documentation on TRY...CATCH:
If there is an error in the code that is enclosed in a TRY block, control passes to the first statement in the associated CATCH block.
As always, the devil is in the details. TRY...CATCH always aborts the code inside the BEGIN TRY...END TRY code block if any error over severity 10 occurs that does not close the database connection. Execution is immediately passed into the BEGIN CATCH...END CATCH block, even if this means aborting code in a stored proc.
Be aware that if an error occurs on any row the entire insert will not happen. The only reason you're seeing this error, and a row being inserted, is because you have two insert statements, one that runs to completion, and one that throws an error. Take for instance:
IF OBJECT_ID('dbo.SomeProc') IS NOT NULL
DROP PROCEDURE dbo.SomeProc;
GO
CREATE PROCEDURE [dbo].[SomeProc]
AS
BEGIN
CREATE TABLE #TEMP
(
ID INT NOT NULL
);
INSERT INTO #TEMP
VALUES (1);
INSERT INTO #TEMP
VALUES (1)
, (2)
, (3)
, (4)
, (1/0);
PRINT (N'Run the SELECT');
SELECT ID
FROM #TEMP;
END
GO
Using this stored proc, either inside a TRY...CATCH or with no TRY...CATCH block, will only result in a single row being inserted into the #TEMPTABLE - none of the rows in the 2nd insert will be present in the output.
Best Answer
I generally abhor SELECT * in production code, and I've been in a situation where its use led to massive amounts of rework later. Your case does look like a fair use of it though.
The place where I find SELECT * to be a must - and its evil cousin "INSERT INTO tbl" without a column list - is in an archiving situation, where rows are being moved to another table that must have the same structure.
If a new column is added to SalesOrder in the future, but not to SalesOrderArchive, the INSERT will fail. Which sounds bad, but it's actually a really good thing! Because the alternative is much worse. If all the columns were listed on the INSERT and the SELECT, then the INSERT would succeed, and so would the following DELETE (which is effectively "DELETE *"). Production code that succeeds doesn't get any attention, and it may be a long time before someone notices that the new column is not being archived, but being silently deleted altogether.