Summary
We have no public CI coverage for TDS endpoints that are not SQL Server / Azure SQL DB. These endpoints speak TDS but do not accept every hardcoded T-SQL statement the driver issues, so behavioral differences only surface in the field.
Raised during review of #4330 by @benrr101 and @edwardneal.
Why this matters
Two properties make these endpoints distinct from an average SQL Server instance:
- They expose a TDS endpoint but behave just differently enough that hardcoded statements issued by SqlClient aren't guaranteed to be compatible.
- Documentation is sometimes incomplete or fails to distinguish between variants. For example,
HAS_PERMS_BY_NAME is not documented as supported in Synapse dedicated SQL pools but is available nonetheless.
Concrete examples already known:
- Synapse dedicated pools reject
SET TRANSACTION ISOLATION LEVEL for every level except READ UNCOMMITTED (error 104409). Serverless/on-demand pools accept it like any other Azure SQL endpoint — so the two variants need separate coverage, not one "Synapse" leg.
- Dataverse rejects isolation level changes entirely.
#4330 works around the Synapse case with an endpoint guard, but that defense is specific to one statement and does not generalize.
Requested coverage
| Endpoint |
Notes |
| Azure Synapse — dedicated SQL pool |
Distinct behavior from on-demand; needs its own leg |
| Azure Synapse — on-demand / serverless |
|
| Microsoft Fabric Data Warehouse |
Including the new TDS bulk copy support |
| Microsoft Dataverse TDS endpoint |
|
Expectation is that a handful of existing tests will fail against these back ends initially. Triaging those failures is part of the work — some will be genuine driver issues, others will need conditional gating.
Related
Summary
We have no public CI coverage for TDS endpoints that are not SQL Server / Azure SQL DB. These endpoints speak TDS but do not accept every hardcoded T-SQL statement the driver issues, so behavioral differences only surface in the field.
Raised during review of #4330 by @benrr101 and @edwardneal.
Why this matters
Two properties make these endpoints distinct from an average SQL Server instance:
HAS_PERMS_BY_NAMEis not documented as supported in Synapse dedicated SQL pools but is available nonetheless.Concrete examples already known:
SET TRANSACTION ISOLATION LEVELfor every level exceptREAD UNCOMMITTED(error 104409). Serverless/on-demand pools accept it like any other Azure SQL endpoint — so the two variants need separate coverage, not one "Synapse" leg.#4330 works around the Synapse case with an endpoint guard, but that defense is specific to one statement and does not generalize.
Requested coverage
Expectation is that a handful of existing tests will fail against these back ends initially. Triaging those failures is part of the work — some will be genuine driver issues, others will need conditional gating.
Related
ADP.IsAzureSynapseDedicatedPoolEndpointguard; review discussion that prompted this issue