query.ResultsetNumber set incorrectly for MSSQL function with exactly 10 resultsets

Posts   
 
    
MoGoMo
User
Posts: 6
Joined: 25-Jul-2022
# Posted on: 18-Aug-2022 01:27:13   

We are seeing an issue with a single MSSQL stored procedure that returns exactly ten TypedView resultsets, when the same codegen runs fine for other procs with 19 and 2 resultsets, eg:

        public static void FetchGetRateMatrixDetailsResultset10ResultTypedView(IDataAccessAdapter adapter, ITypedView2 typedViewToFetch, System.Int32 billingRatecardId)
        {
            StoredProcedureCall call = CreateGetRateMatrixDetailsCall(adapter, billingRatecardId);
            IRetrievalQuery query = call.ToRetrievalQuery();
            query.ResultsetNumber = 2;
            adapter.FetchTypedView(typedViewToFetch, query);
        }
ResultSet name query.ResultsetNumber
1 1
2 3
3 4
4 5
5 6
6 7
7 8
8 9
9 10
10 2

In the designer, I can see the resultsets being ordered as 1,10,2,3,4,5,6,7,8,9 when being imported. My suspicion is that somewhere in the code the ordering is using alphabetical sort, and the mapping is using numerical. For now, I've manually overwritten the query.ResultsetNumber's to match the ResultSet names in the .cs file, but if there is a way to remap these in the designer that I've not found that would be awesome.

  • LLBLGen Pro/packages version: 5.9.2
  • No exceptions thrown until resultsets aren't returned correctly.
  • Code Version: .NET Framework 4.8
  • Database type: MSSQL
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39612
Joined: 17-Aug-2003
# Posted on: 19-Aug-2022 09:52:30   

The resultsets are named 'Resultsetnumber', so e.g. Resultset1, Resultset2 etc. so they're sorted like that alphabetical. I don't think it's a sorting problem as it would then also plague the stored proc with 19 resultsets. I think it's something to do with resultsets having the same layout which might have switched?

Anyway, you can select the resultset a typedview is mapped on in its mappings. In the designer, open the mappings for the typed view by right clicking it in the project explorer -> Edit mappings. At the top you can select the resultset the typed view is mapped on.

I will create a stored procedure with 10 resultsets and will try to see what you mean. The resultsets have a property 'IndexInListOfResultsets' and it might very well be this is kept the same for code generation purposes across synchronizations. You can see this value when using the plugin 'Project inspector' when right-clicking the project node in Project explorer and then navigating to MetaData -> all the way to the stored procedure and then the resultsets.

This stored procedure was changed a couple of times by adding new resultsets in between other resultsets? (like it first returned resultset1, 2 and 3 and then you added a 4th, which became the second resultset so the order was 1, 4, 2, 3? )

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39612
Joined: 17-Aug-2003
# Posted on: 19-Aug-2022 10:13:22   

Alright, I think I have reproduced what you ran into, but I can only conclude it did the right thing. So I created a stored procedure with 10 resultsets: (On northwind)

CREATE PROCEDURE [dbo].[pr_TenResultsets]
AS
BEGIN
    SELECT * FROM Customers;
    SELECT CustomerID From Customers;
    SELECT DISTINCT Country FROM Customers;
    SELECT DISTINCT City FROM Customers;
    SELECT CompanyName FROM Customers;
    SELECT DISTINCT Country, City FROM Customers;
    SELECT CustomerId, Country, City FROM Customers;
    SELECT CompanyName, CustomerId, Country FROM Customers;
    SELECT CompanyName, CustomerId, Country, City FROM Customers;
    SELECT CompanyName, City FROM Customers;
END

Then I added the proc to my test project, mapped 10 typed views on these 10 resultsets. This was all as expected, Typedview10 was mapped onto resultset 10. I generated code into a new folder and everything was defined ok, resultsets were correctly assigned.

Now I altered the stored procedure to this:

ALTER PROCEDURE [dbo].[pr_TenResultsets]
AS
BEGIN
    SELECT * FROM Customers;
    SELECT CompanyName, City FROM Customers;
    SELECT CustomerID From Customers;
    SELECT DISTINCT Country FROM Customers;
    SELECT DISTINCT City FROM Customers;
    SELECT CompanyName FROM Customers;
    SELECT DISTINCT Country, City FROM Customers;
    SELECT CustomerId, Country, City FROM Customers;
    SELECT CompanyName, CustomerId, Country FROM Customers;
    SELECT CompanyName, CustomerId, Country, City FROM Customers;
END

So I moved the 10th resultset to spot 2. I then synced the project, and this made the designer to map the typed views to different resultsets as the resultsets are now different; resultset2 is now equal to resultset10 previously. So Typedview1 is still mapped to resultset 1, but typedview2 is now mapped to resultset3 (as the resultset3 was previously resultset2), TypedView3 is now mapped to resultset4 etc. and TypedView10 is now mapped to resultset2 (as the 10th resultset originally is now resultset2 of the stored proc.

Generated code again and it is doing it correctly:

/// <summary>Gets the SP Call using query for fetching the TenResultsetsResultset10TypedView TypedView.</summary>
/// <returns>ready to use IRetrievalQuery instance for fetching the typedview</returns>
/// <remarks>Output parameters are not set after query is executed</remarks>
public static IRetrievalQuery GetQueryForTenResultsetsResultset10TypedViewTypedView()
{
    IRetrievalQuery query = GetTenResultsetsCallAsQuery();
    query.ResultsetNumber = 2;
    return query;
}

What I think might be wrong on your side is that the code calls a stored procedure in a schema which has still the original ordering of the resultsets (so in my example, the order when I created the proc) but the generated code expects them to be in a different order, resulting in the wrong resultset being used.

Could that be the case here?

Frans Bouma | Lead developer LLBLGen Pro