Test coverage: non-SQL-Server TDS endpoints (Synapse dedicated + on-demand, Fabric DW, Dataverse)
- Dominant language
- C#
- Stars
- 989
- Forks
- 340
- Avg merge
- 4d 19h
- Merged PRs (30d)
- 72
Description
## 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:
1. They expose a TDS endpoint but behave just differently enough that hardcoded statements issued by SqlClient aren't guaranteed to be compatible.
2. 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
- #4330 — added `ADP.IsAzureSynapseDedicatedPoolEndpoint` guard; review discussion that prompted this issue
Contributor guide
Research direction
Start by reviewing the existing public CI coverage and the #4330 change, including the ADP.IsAzureSynapseDedicatedPoolEndpoint guard, then trace how endpoint legs and existing tests are configured. Add separate coverage for the four requested TDS endpoints and triage the resulting failures; done means the legs run in CI and incompatibilities are either fixed or conditionally gated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, csharp, sql
- Domain
- backend, databases, testing
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100