Stored proc with nullable string column throws SqlNullValueException under EF Core 8 + nullable enabled

[Brqqq]

Hi, I'd like some guidance on whether the following is expected behavior and what the recommended approach is.

Environment

• Reverse POCO Generator v3.14.0
• EF Core 8+ target
• Consuming project has <Nullable>enable</Nullable>
• Default settings (AllowNullStrings = false), stored-procedure generation enabled

I have this stored procedure to reproduce the issue:

CREATE PROCEDURE dbo.sp_NullableStringRepro AS
BEGIN
    SET NOCOUNT ON;
    SELECT CAST(NULL AS varchar(50)) AS SomeText;
END

This results in the following code

        public class sp_NullableStringReproReturnModel
        {
            public string SomeText { get; set; }
        }

        public List<sp_NullableStringReproReturnModel> sp_NullableStringRepro(out int procResult)
        {
            var procResultParam = new SqlParameter { ParameterName = "@procResult", SqlDbType = SqlDbType.Int, Direction = ParameterDirection.Output };
            const string sqlCommand = "EXEC @procResult = [dbo].[sp_NullableStringRepro]";
            var procResultData = Set<sp_NullableStringReproReturnModel>()
                .FromSqlRaw(sqlCommand, procResultParam)
                .ToList();

            procResult = (int) procResultParam.Value;
            return procResultData;
        }

When I call it, I get the following exception: System.Data.SqlTypes.SqlNullValueException: 'Data is Null. This method or property cannot be called on Null values.'

If I change the #nullable restore to #nullable disable in the generated models, EF Core interprets it correctly and everything works without throwing exceptions.

My understanding is:

• By default, nullable is turned on (as per project setting) for the generated model .cs file
• The // <auto-generated> in the generated file turns it off again
• #nullable restore turns it back on (as per project setting)
• EF Core then uses the nullability to do runtime sanity checks, which is what is causing my issue.

I can change the script so it writes #nullable disable instead. But I'm wondering if I'm thinking about this the right way or if there's a better solution that I'm missing

[sjh37]

Not expected behaviour - it's a bug in the generator, and #nullable disable is the right instinct but the wrong place to fix it (your edit is overwritten when the .tt regenerates).

What's happening: for table columns the generator emits .IsRequired(false) so EF Core guards NULLs. For stored-proc return models it doesn't - they're registered with only .HasNoKey(), so EF Core 8 decides whether a column can be NULL purely from the C# nullability of the property. Your project's <Nullable>enable</Nullable> makes public string SomeText a non-nullable reference, so EF reads it without a null check and throws. #nullable disable makes the property nullable-oblivious, which EF treats as nullable - hence it works.

Note AllowNullStrings = true will not fix this on its own (the return-model generator hardcodes string columns as non-nullable), so there's no current setting that solves it cleanly. I'll fix the generator so nullable SP return columns are emitted correctly.

[tomermug]

I have the same problem and not yet fixed
I'm using poco 3.14 and my EF is 9
I'm facing this issue also in EF 10
I'm getting on null string values the same error "Data is Null. This method or property cannot be called on Null values."
I can't move forward with my code and i don't want to fix all my sql stored procedure
Please update if the problem fixed

[sjh37]

Fixed. This was two independent generator bugs stacking, both now resolved.

Root cause 1 - the #nullable restore you spotted (your default-settings case). The CS8669 fix in v3.14.0 (#883) bracketed the generated DbContext/interface/factory blocks with #nullable enable annotations ... #nullable restore. But restore returns to the project's nullable setting, so in a project with <Nullable>enable</Nullable> everything after the DbContext in the single-file output - including every stored procedure return model - silently became NRT-enabled. EF Core 8+ infers result-set column nullability from the C# annotation, so public string SomeText was treated as required and read without a NULL check. The blocks now close with #nullable disable, which is the correct baseline for an <auto-generated> file, keeping the return models nullable-oblivious exactly as you found when you edited it by hand.

Root cause 2 - why AllowNullStrings = true didn't help either. Table columns respect AllowNullStrings when deciding nullability, but stored proc return columns used a hardcoded list that always treated string/byte[] as non-nullable, emitting string ... = null!. With AllowNullStrings = true, DB-nullable string and byte[] return columns now generate as string? / byte[]?. Additionally, when the generated file is NRT-enabled but a reference-typed return column can't take the ? (e.g. NullableReverseNavigationProperties = true with AllowNullStrings = false), the fluent config now emits .IsRequired(false) - the same guard table columns have always had.

@tomermug this applies to you too - the fix is version-independent and covers EF Core 8, 9 and 10 templates.

Your repro proc is now part of the test database, with a runtime integration test that calls it through EF Core and materialises the NULL. I verified the old generator output throws exactly your SqlNullValueException: Data is Null and the new output passes.

Will be in the next release. Thanks for the excellent minimal repro - it made this straightforward to pin down.

---

Before I release, can you ( @tomermug and @Brqqq ) please test this by grabbing the latest EF.Reverse.POCO.v3.ttinclude file and trying it in your project.

[tomermug]

@sjh37 Thanks for your reply
It working!!!
Thank you very much!!

[Brqqq]

The latest .ttinclude fixes my issue! Thanks a lot for your work!

[sjh37]

Now released in 3.14.1