An Apache Spark-based analytics platform optimized for Azure.
Hello Kishor kumar Reddy Akki,
Welcome to Microsoft Q&A,
This is expected behavior, not a bug. SQLSERVER Unity Catalog connections used for Lakehouse Federation are read-only at the connection-type level, and the platform silently ignores read_only: false in create and patch requests for this type rather than erroring.
- Is
read_onlyconfigurable for SQLSERVER Unity Catalog connections? No. Microsoft's own connection-type comparison confirms query federation connections (which is what SQLSERVER, Snowflake, and similar external-database connections are) support Read: Yes, Write: No as an inherent capability, not a per-connection setting. See Unity Catalog connections. - Is it enforced by the backend? Yes. This lines up with your own testing: the create and patch calls both succeed without error, but the backend forces the field back to
truebecause write was never an available capability for this connection type to begin with, it isn't validating and rejecting your input, it's just not honoring a field that doesn't apply. - Is there any supported way to flip it via CLI or REST API? No, this isn't a documented or supported operation for SQLSERVER/Lakehouse Federation connections, on any API version. This is confirmed as intentional design (
CREATE FOREIGN CATALOGis explicitly documented as producing "a read-only mirror" of the source database), not a gap in the CLI or API.
If you need write access back to SQL Server from Databricks, the connection type itself needs to change. A JDBC connection type does support both read and write in Unity Catalog, unlike query federation. The tradeoff, confirmed by others hitting this same wall, is that JDBC writes fall outside Unity Catalog's governance and lineage tracking that the native SQLSERVER federation connection gives you for reads. There's no way to get write-back with full UC governance on this connection type today.
Please click Accept Answer and upvote if this helped.