You are hitting a known limitation in Azure SQL Database: it does not allow you to grant or modify permissions directly on most system objects, such as system stored procedures, catalog views, or extended stored procedures, resulting in the error "Msg 40574, Level 16, State 1, Line 1 - Permissions for system stored procedures, server scoped catalog views, and extended stored procedures cannot be changed in this version of SQL Server". This is not a bug but intentional: in Azure SQL Database, many server-level and some system-level permissions are simply not supported and cannot be changed by users.
Why This Happens
-
Azure SQL Database (unlike SQL Server on-prem or Managed Instance) restricts direct changes to system object permissions for security and multi-tenancy reasons.
-
Many server/instance-level concepts are not available in Azure SQL Database, and permissions must be managed at the database level, not the server level.
Lakeflow Connect Workaround & Permissions
-
For ETL scenarios using Lakeflow Connect with change tracking (not CDC), you do not need to modify permissions on system objects directly.
-
Instead, focus on granting the following at the database and object level, as outlined in the Databricks documentation:
-
VIEW CHANGE TRACKING on tables and schemas that are being ingested.
-
VIEW DEFINITION on the database being ingested.
-
Example T-SQL for these (replace with your user/table/database names):
-- For each tracked table:
GRANT VIEW CHANGE TRACKING ON OBJECT::dbo.<your-table> TO <etl-user>;
-- At schema scope (alternative):
GRANT VIEW CHANGE TRACKING ON SCHEMA::dbo TO <etl-user>;
-- Grant view definition for the whole database:
GRANT VIEW DEFINITION ON DATABASE::<your-db> TO <etl-user>;
-
There is no supported way to bypass or "fix" the inability to change permissions on system objects—stick with object- and database-level grants as above.
If You Still Get Errors
-
Double-check that you are not attempting to run GRANT statements referencing any system object, but only your user tables, schemas, or DB.
-
If Databricks or Lakeflow Connect instructions refer to granting permissions on system objects that can't be modified in Azure SQL DB, you can safely omit those steps and just use the granular permissions above.
Summary Table
| Object Type |
Can Permission Be Changed? |
Workaround/Azure SQL Approach |
| User tables/schemas/databases |
Yes |
Use GRANT as documented |
| System stored procs/views/tables |
No |
Not supported, ignore/omit |
| Change tracking metadata |
Yes (object/schema level only) |
Use VIEW CHANGE TRACKING |
You should not attempt or expect to grant rights on system-level SQL objects in Azure SQL Database, and should instead use the per-database/object permissions specifically documented for your ETL scenario.
