Repository navigation
GetSchema("DataTypes") does not report the json type against Azure SQL #4592
Description
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:
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 printedSuggested 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.
Activity
github-actions commentedon Aug 25, 2026
🔍 Triage Summary
Area\JsonAnalysis
GetSchema("DataTypes")filters rows using a string-based version comparison inSqlMetaDataFactory.SupportedByCurrentVersion, which excludes thejsonrow (declared at17.00.000.0) because Azure SQL always reports version12.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 (FEATUREEXTACKtoken0x0D) already available inConnectionCapabilities. The fix is small and surgical, mirroring what #4501 already did for thevectortype. Severity: P2 — incorrect metadata returned to callers that rely onGetSchemafor type discovery.Next Steps
GetSchemagap for bothjsonandvector; this issue may be resolved as part of or in tandem with that work.SqlMetaDataFactory(SqlMetaDataFactory.DataTypes.cs) and apply the same capability-flag-based guard used forvector(Add vector(float16) support #4501) to thejsontype row — specifically, checkConnectionCapabilities.IsJsonSupportEnabled(or equivalent) instead of relying onMinimumVersionstring comparison to determine whether to include thejsonrow.GetSchema("DataTypes")includes thejsonrow when the connection has JSON support enabled.edwardneal commentedon Aug 25, 2026
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
ConnectionCapabilitiescame 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.
Fix | GetSchema("DataTypes") does not report json type on Azure SQL (#…