Skip to content

[release/10.0] Fix OPENJSON column name when going over 2100 params#37572

Merged
roji merged 1 commit intodotnet:release/10.0from
roji:37569
Feb 5, 2026
Merged

[release/10.0] Fix OPENJSON column name when going over 2100 params#37572
roji merged 1 commit intodotnet:release/10.0from
roji:37569

Conversation

@roji
Copy link
Copy Markdown
Member

@roji roji commented Jan 27, 2026

Fixes #37569

Description
Fixed a case-sensitivity bug in SQL Server's OPENJSON generation when parameter collections exceed the 2098 parameter limit. When VALUES expressions are replaced with OPENJSON to work around SQL Server's parameter limit, the OPENJSON WITH clause defined a column with lowercase [value] while ColumnExpressions referenced it with uppercase [Value], causing a name mismatch in case-sensitive collations.

Customer impact
Applications using SQL Server with case-sensitive collations that query large parameter collections (>2098 elements) or queries with many parameters that trigger OPENJSON usage will fail with column name mismatch errors. The bug specifically affects collection methods like All(), Contains(), etc. on inline collections.

Example failing code:

var ids = Enumerable.Repeat(1, 2099);
await context.Users.Where(user => ids.All(id => user.Id == id)).ToListAsync();

Workaround: Use databases with case-insensitive collations (the default), or restructure queries to avoid exceeding parameter limits.

How found
Customer reported via GitHub issue #37569. The issue affects customers using case-sensitive collations with large parameter collections - a relatively small subset of SQL Server users, but a critical correctness bug for those affected.

Regression
Yes, regression in EF Core 10.0.

Testing
The fix was tested by building the solution successfully. Existing test coverage includes Parameter_collection_of_ints_Contains_int_parameters_limit which exercises parameter collections of 2098, 2099, and 2100 elements, though it validates no exceptions are thrown rather than asserting specific SQL output. The fix ensures OPENJSON uses uppercase [Value] to match the VALUES column naming convention.

Risk
Very low. The change is a simple two-line fix that ensures consistency in column naming between VALUES and OPENJSON expressions. It only affects the code path where parameter count exceeds 2098 and VALUES is replaced with OPENJSON.

Quirk added.

@roji roji requested a review from a team as a code owner January 27, 2026 13:25
Copilot AI review requested due to automatic review settings January 27, 2026 13:25
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Fixes a SQL Server case-sensitivity issue in the over-2100-parameters fallback path where EF Core switches from VALUES to OPENJSON and produced mismatched column casing ([value] vs [Value]) under case-sensitive collations.

Changes:

  • Update SQL Server nullability processing to align OPENJSON WITH column name casing with ValuesValueColumnName ("Value"), with an AppContext switch to opt into old behavior.
  • Strengthen/update SQL assertions in the SQL Server JSON type primitive collections functional tests to validate the corrected casing.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File Description
test/EFCore.SqlServer.FunctionalTests/Query/PrimitiveCollectionsQuerySqlServerJsonTypeTest.cs Updates assertions to expect OPENJSON WITH ([Value] ...) and validates generated SQL for huge parameter collections.
src/EFCore.SqlServer/Query/Internal/SqlServerSqlNullabilityProcessor.cs Uses a consistent column name (Value) for the over-limit OPENJSON path, with an AppContext quirk switch for legacy behavior.

Copy link
Copy Markdown
Member

@artl93 artl93 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Customer reported regression. Quirked. Odd case. I'm guessing hard for customer to diagnose on their own?

Approved for me.

@roji
Copy link
Copy Markdown
Member Author

roji commented Jan 28, 2026

I'm guessing hard for customer to diagnose on their own?

Yeah, also not much they can do about it when they do, unfortunately... Changing the database collation to be case-insensitive would work, but is a very big hammer that affects many other aspects of the program.

@ErikEJ
Copy link
Copy Markdown
Contributor

ErikEJ commented Jan 28, 2026

@roji Do you plan to run SQL Server tests on a case-sensitive collation? (or maybe you alreeady do?)

@roji
Copy link
Copy Markdown
Member Author

roji commented Jan 28, 2026

@ErikEJ not at the moment, no. This is the first time in a very long time that we've encountered a collation-related issue - we could of course change that in the future.

@rbhanda rbhanda added this to the 10.0.4 milestone Feb 5, 2026
@roji roji merged commit 46436ac into dotnet:release/10.0 Feb 5, 2026
6 of 7 checks passed
@roji roji deleted the 37569 branch February 5, 2026 17:55
@JaderCM
Copy link
Copy Markdown

JaderCM commented Feb 5, 2026

Thanks @roji!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants