Schema mismatch after a refactor: the service account holds a GRANT SELECT on dbo but a DBA moved tables to a new schema (e.g. raw, staging, reporting) using ALTER SCHEMA. Schema-level grants do not follow the object — the grant on the old schema becomes irrelevant for the moved object.. ADF dataset uses a hardcoded schema prefix that no longer matches reality: the dataset was set up as dbo.FactSales but the table was renamed or moved to sales.FactSales, so the generated query hits an object the account has no access to.. Service principal vs. SQL login confusion: a Managed Identity or Azure AD service principal was granted access, but the ADF linked service is still configured with a SQL login that never received the equivalent grant on the target schema.. Row-level security or column-level DENY masks the error as 1934 in some configurations: an explicit DENY on a column or a blocking security predicate causes the engine to surface a permission error rather than returning a filtered result set.. Object was created in a non-default schema by a developer who used their personal schema instead of dbo or a shared schema. Grants were never issued because the object was considered temporary but later referenced in production pipelines.. The grant was issued to a Windows group that no longer includes the service account because of an AD group membership change or a group policy update, silently removing effective permission.. A database restore or environment clone was performed without re-running the permission scripts. The restored database has no grants for pipeline service accounts, causing all copy activities to fail with 1934 on first run.

Step 1 — Confirm the object exists and identify its schema: SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_TYPE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'YourTable'; If no row is returned, the object may have been renamed or dropped. If a row is returned, note the TABLE_SCHEMA value.. Step 2 — Check current permissions for the service account: SELECT dp.permission_name, dp.state_desc, OBJECT_NAME(dp.major_id) AS object_name, s.name AS schema_name FROM sys.database_permissions dp LEFT JOIN sys.schemas s ON dp.class = 3 AND dp.major_id = s.schema_id WHERE dp.grantee_principal_id = USER_ID('your_service_account'); This shows schema-level and object-level grants side by side.. Step 3 — Grant SELECT on the correct schema (preferred for pipeline accounts that need broad read access within a schema): GRANT SELECT ON SCHEMA::[target_schema] TO [your_service_account];. Step 4 — Or grant SELECT on the specific object only (least-privilege alternative): GRANT SELECT ON [target_schema].[YourTable] TO [your_service_account]; Repeat for views or functions referenced in the same pipeline.. Step 5 — Alternatively, add the account to db_datareader to cover all user-accessible objects across all schemas: ALTER ROLE db_datareader ADD MEMBER [your_service_account]; Use this only if broad read access is acceptable; avoid on databases that contain sensitive columns.. Step 6 — In ADF, update the dataset schema prefix to match the actual schema: open the dataset, set Schema to the correct value (e.g. staging), and run a preview to confirm data returns before re-triggering the pipeline.. Step 7 — Re-run the failed pipeline trigger and verify in ADF Monitor that the copy activity status changes to Succeeded. Then re-check downstream Synapse or Power BI refresh jobs that were blocked by the missing source data.

Medium severitypermission

SQL Server Error:
1934, Object Not Found or No Access

Impact

When 1934 blocks an ADF copy activity, all downstream tables in Synapse or Fabric that depend on that source remain stale — incremental loads stop silently and dashboards serve yesterday's data without any visible alert unless pipeline monitoring is in place. If the failing activity is part of a dependency chain, child activities are skipped and the entire pipeline marks as Failed.

A 1934 error causes an immediate activity failure with zero rows written to the sink. ADF does not retry permission errors by default — the activity moves straight to Failed status. Any downstream activities marked as dependent on Success are skipped, which means incremental load watermarks are not updated, Synapse external tables remain at the previous snapshot, and scheduled Power BI dataset refreshes that run against those tables will either fail or return stale data. SLA breaches accumulate for every hour the grant is missing.

What does this error mean?

SQL Server error 1934 is raised when a login or database user attempts a SELECT on a table, view, or function for which the executing principal has no explicit or inherited permission, or when the object does not exist in the referenced schema. In a data-pipeline context this error surfaces at query execution time — not at connection time — which means the ADF linked service connects successfully but the copy activity or lookup activity fails when it tries to read the actual object. The engineer sees a failed pipeline run with an 'SqlException' containing message 1934; upstream extractions halt immediately and no rows are written to the sink.

Common causes

1Schema mismatch after a refactor: the service account holds a GRANT SELECT on dbo but a DBA moved tables to a new schema (e.g. raw, staging, reporting) using ALTER SCHEMA. Schema-level grants do not follow the object — the grant on the old schema becomes irrelevant for the moved object.
2ADF dataset uses a hardcoded schema prefix that no longer matches reality: the dataset was set up as dbo.FactSales but the table was renamed or moved to sales.FactSales, so the generated query hits an object the account has no access to.
3Service principal vs. SQL login confusion: a Managed Identity or Azure AD service principal was granted access, but the ADF linked service is still configured with a SQL login that never received the equivalent grant on the target schema.
4Row-level security or column-level DENY masks the error as 1934 in some configurations: an explicit DENY on a column or a blocking security predicate causes the engine to surface a permission error rather than returning a filtered result set.
5Object was created in a non-default schema by a developer who used their personal schema instead of dbo or a shared schema. Grants were never issued because the object was considered temporary but later referenced in production pipelines.
6The grant was issued to a Windows group that no longer includes the service account because of an AD group membership change or a group policy update, silently removing effective permission.
7A database restore or environment clone was performed without re-running the permission scripts. The restored database has no grants for pipeline service accounts, causing all copy activities to fail with 1934 on first run.

How to fix it

1Step 1 — Confirm the object exists and identify its schema: SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_TYPE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'YourTable'; If no row is returned, the object may have been renamed or dropped. If a row is returned, note the TABLE_SCHEMA value.
2Step 2 — Check current permissions for the service account: SELECT dp.permission_name, dp.state_desc, OBJECT_NAME(dp.major_id) AS object_name, s.name AS schema_name FROM sys.database_permissions dp LEFT JOIN sys.schemas s ON dp.class = 3 AND dp.major_id = s.schema_id WHERE dp.grantee_principal_id = USER_ID('your_service_account'); This shows schema-level and object-level grants side by side.
3Step 3 — Grant SELECT on the correct schema (preferred for pipeline accounts that need broad read access within a schema): GRANT SELECT ON SCHEMA::[target_schema] TO [your_service_account];
4Step 4 — Or grant SELECT on the specific object only (least-privilege alternative): GRANT SELECT ON [target_schema].[YourTable] TO [your_service_account]; Repeat for views or functions referenced in the same pipeline.
5Step 5 — Alternatively, add the account to db_datareader to cover all user-accessible objects across all schemas: ALTER ROLE db_datareader ADD MEMBER [your_service_account]; Use this only if broad read access is acceptable; avoid on databases that contain sensitive columns.
6Step 6 — In ADF, update the dataset schema prefix to match the actual schema: open the dataset, set Schema to the correct value (e.g. staging), and run a preview to confirm data returns before re-triggering the pipeline.
7Step 7 — Re-run the failed pipeline trigger and verify in ADF Monitor that the copy activity status changes to Succeeded. Then re-check downstream Synapse or Power BI refresh jobs that were blocked by the missing source data.

Example log output

ErrorCode=SqlFailedToConnect, Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException, Message=Error occurred when trying to execute query. SqlException ErrorCode: -2146232060, SqlException Number: 1934, SqlException Message: SELECT permission was denied on the object 'FactSales', database 'AnalyticsDB', schema 'reporting'., Source=.Net SqlClient Data Provider

Frequently asked questions

SQL Server 1934 fix — how do I find exactly which object is causing the permission error?

The error message itself contains the object name, schema, and database — read it carefully before querying. If the message is truncated in your log aggregator, enable ADF diagnostic logs and check the activityRuns table in Log Analytics: the 'error.message' field contains the full SqlException text including schema and object name.

Will adding the account to db_datareader fix error 1934 permanently?

Yes, for read access. db_datareader grants SELECT on all current and future user tables and views in all schemas in that database. It does not cover stored procedures or functions. If the pipeline calls a function or EXEC a procedure, you also need EXECUTE permission on those objects separately.

Error 1934 appeared after ALTER SCHEMA — why did the old GRANT stop working?

A schema-level GRANT is tied to the schema, not to individual objects. When you transfer an object to a new schema with ALTER SCHEMA new_schema TRANSFER old_schema.table, the object leaves the scope of the old grant. You must issue a new GRANT SELECT ON SCHEMA::[new_schema] or on the specific object in its new location.

Can error 1934 be caused by a column-level DENY and how do I detect it?

Yes. An explicit DENY on a specific column takes precedence over a schema-level GRANT and will surface as a permission error when a SELECT * or a query referencing that column is executed. Run: SELECT dp.permission_name, dp.state_desc, COL_NAME(dp.major_id, dp.minor_id) AS column_name FROM sys.database_permissions dp WHERE dp.class = 1 AND dp.grantee_principal_id = USER_ID('your_service_account') AND dp.state = 'D'; Any DENY row here blocks SELECT on that column for the account.

Source · learn.microsoft.com/en-us/sql/relational-databases/errors-events/database-engine-events-and-errors