GetSchema("DataTypes") does not report the json type against Azure SQL

[apoorvdeshmukh]

Summary

GetSchema("DataTypes") never reports the json type against Azure SQL, even though Azure SQL supports it.

Cause

Rows in the DataTypes collection are filtered by the version the server reports. SqlMetaDataFactory.SupportedByCurrentVersion compares the row's MinimumVersion against ConnectionCapabilities.ServerVersion as a string, and the json row is declared from 17.00.000.0 onwards:

https://github.com/dotnet/SqlClient/blob/main/src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/SqlMetaDataFactory.DataTypes.cs#L61-L62

Azure SQL reports 12.00.xxxx whatever it supports, so the comparison excludes the row.

This affects only the newest types. Every other row is declared at 10.00.000.0 or below, which 12.00 satisfies.

Repro

Against Azure SQL, on a database where json columns can be created:

using SqlConnection connection = new(azureConnectionString);
connection.Open();

foreach (DataRow row in connection.GetSchema("DataTypes").Rows)
{
    if ((string)row["TypeName"] == "json")
    {
        Console.WriteLine("found");
    }
}
// nothing is printed

Suggested fix

The driver already negotiates json support through a feature extension (FEATUREEXTACK token 0x0D), and ConnectionCapabilities carries the result. That is authoritative and correct on both Azure SQL and on-premises, unlike the reported version.

SqlMetaDataFactory is constructed with the full ConnectionCapabilities, so the value is already available where the collection is built. #4501 takes this approach for the vector type:

if (vectorVersion != TdsEnums.VECTOR_VERSION_NOT_SUPPORTED)
{
    AddVectorType();
}

Doing the same for json would make the two consistent.

Why this is filed separately

json's current behaviour has shipped, so changing it is a behavioural change that deserves its own discussion. #4501 only avoided introducing the same gap for the new vector type, which has not shipped.

[github-actions]

🔍 Triage Summary

Check	Result
Issue type	Bug
Environment	All required environment details provided for investigation
Area	Area\Json
Duplicates	Potentially related: #3833 (GetSchema DataTypes missing JSON and VECTOR)
Regression	Not indicated — behavior has shipped and was never correct for Azure SQL

Analysis

GetSchema("DataTypes") filters rows using a string-based version comparison in SqlMetaDataFactory.SupportedByCurrentVersion, which excludes the json row (declared at 17.00.000.0) because Azure SQL always reports version 12.00.xxxx. The root cause is using the server-reported version string as a proxy for feature support rather than the authoritative feature-extension negotiation result (FEATUREEXTACK token 0x0D) already available in ConnectionCapabilities. The fix is small and surgical, mirroring what #4501 already did for the vector type. Severity: P2 — incorrect metadata returned to callers that rely on GetSchema for type discovery.

Next Steps

• Review GetSchema("DataTypes") does not return entries for JSON and VECTOR types #3833 before proceeding — it covers the same GetSchema gap for both json and vector; this issue may be resolved as part of or in tandem with that work.
• Assign to Copilot coding agent to investigate SqlMetaDataFactory (SqlMetaDataFactory.DataTypes.cs) and apply the same capability-flag-based guard used for vector (Add vector(float16) support #4501) to the json type row — specifically, check ConnectionCapabilities.IsJsonSupportEnabled (or equivalent) instead of relying on MinimumVersion string comparison to determine whether to include the json row.
• Add a unit/functional test that asserts GetSchema("DataTypes") includes the json row when the connection has JSON support enabled.

Note: This triage summary is auto-generated by an AI agent. The analysis and suggestions above have not been verified by a human maintainer. Please treat as preliminary guidance only.

Generated by SqlClient Issue Auto-Triage for issue #4592 · 29 AIC · ⌖ 8.93 AIC · ⊞ 8.6K · ◷

[edwardneal]

Further context is on an earlier comment for PR 3858. This specific case is covered in the ConnectionSchemaTest manual test, and its absence was actually the reason why the concept of ConnectionCapabilities came about - as noted, we need to rely on more authoritative metadata than a SQL Server version.

#4362 rewrites the DataTypes schema generation; I was waiting for that to be reviewed/merged before making a further fix.