Bug with new experimental feature of Multiple Result Sets from a stored procedure

I am trying the new experimental feature of Multiple Result Sets from a stored procedure. This worked great for me with a couple of small things below.

Steps to reproduce

I created a simple stored procedure that returned 3 different result sets back in one call. No input parameters.

• The generated code did not include the Dapper package for me–no big deal, just unexpected. This may be out-of-band and just need to be documented.
• I included a non-multi stored procedure with the test and it happens to include an nvarchar in it’s result set. This fails code generation if the experimental feature is on, but works if it is off. Unable to get result set shape for PROCEDURE 'dbo.Blahblahblah' Operand type clash: nvarchar is incompatible with Blahblahblah
• I was a but surprised that this returns multiple List<> variables. This will not be a problem for the code I write, but if someone has a very large result set, this may pose a memory issue. Normally a DataReader of some sort is used.

Further technical details

EF Core version in use: EF Core 6

EF Core Power Tools version: 2.5.863.0

Database engine: SQL Server 2019 Standard Edition

Visual Studio version: Visual Studio 2022

[JimF42]

1. Understood
2. Well, actually, it wasn’t what I thought it was. This database is new to me and I just “picked one”. Turns out it passes in a UserDefinedTableType that does not actually have an nvarchar in it! See sample code below.
3. Understood. Again, it’s not a concern for me personally as I typically spin off these kinds of result sets to List<>s anyway–you’ve just done it for me.

/****** Object:  UserDefinedTableType [dbo].[ChecksAdd]    Script Date: 12/16/2021 2:33:34 PM ******/
Create Type dbo.ChecksAdd As Table
(
    ProcessID int           Not Null,
    HistoryID int           Not Null,
    CheckID   int           Not Null,
    CheckDate datetime2(7)  Not Null,
    CheckRaw  numeric(9, 3) Not Null,
    Primary Key Clustered (
                              ProcessID Asc,
                              HistoryID Asc
                          )
    With (Ignore_Dup_Key = Off)
)
Go
Create Procedure dbo.ReturnDataTypes @tp ChecksAdd ReadOnly
As
Begin
    Select 1
End
Go
Declare @RDT ChecksAdd
Exec dbo.ReturnDataTypes @RDT

[JimF42]

@ErikEJ Personally, I’m fine with not being able to have the SchemaOnly table valued parameters.

I have better ways of dealing with passing in tables of data to a stored procedure (better from the standpoint of having a c# app calling the sproc at least). As long as there’s not to much volume of data I usually pass in a JSON string and have SQL decode the JSON. Even then, I only typically do that for things like when I have a variable, but small number, of items I need to write a filter for. Say the user wants to filter on certain product numbers and they get to choose which ones, etc.