Our columns Id, CreateDate, and RandomData in the first result set get a prefix of Header and a prefix of Header2 in the second result set.

Uptight:

SURPRISE!

Now imagine my surprise when, going through these examples again, I run the code and receive an error message!

Msg 11537, Level 16, State 1, Procedure GetHeaders, Line 3
EXECUTE statement failed because its WITH RESULT SETS clause specified 3 column(s) for result set number 2, but the statement sent 1 column(s) at run time.

I’m a poor man’s son

I know that it’s a different Id but I should still get a result set. It should just be empty.

So I run through my checklist

Have I missed a previous step? No.

Have I messed up a previous step? No.

Have I run things out of order. No.

Have I accidently only run part of the script. No.

What’s the error message saying?

Difference in columns? Only 1 column returned? That’s not making any sense.

I quickly write out the two SELECT statements and run them separately. They execute without problems.

Plain out of sight!

I start switching through the different panels and suddenly something pops out at me from the Messages pane.

Master Blaster:

Apart from OutOfMemory exception when you leave Actual Execution Plans on and then run a loop, this is the first time I’ve seen them interfere with a T-SQL statement!

In case you are worried about this happening to you, don’t be!
I was double checking this by runnning it on Microsoft SQL Server 2016 (SP1) and I tried to verify the behaviour.
Nope! No problem! That’s the second thing that I’ve found naturally that’s been fixed in newer versions of SQL Server!