Misspelled or wrong database name in the connection string. The most common cause: a typo ('Slaes' instead of 'Sales'), a case mismatch on a case-sensitive collation instance, or a connection string pointing to a DEV database name that does not exist on the PROD server.. Database is offline. The database was taken offline manually (ALTER DATABASE SET OFFLINE), is in the middle of a restore, or SQL Server failed to bring it online at startup due to a corrupt or missing file. Check state_desc in sys.databases — valid online state is ONLINE; OFFLINE, RESTORING, RECOVERING, SUSPECT all block connections.. Database is in SINGLE_USER mode. A DBA ran a maintenance operation and left the database in single-user mode. Only one connection is allowed at a time; all pipeline connections get error 4060 if that one slot is occupied by another session.. Login has no user mapping in the target database. The SQL login exists at the server level (visible in sys.server_principals) but there is no corresponding user in the database (sys.database_principals). This is common after a database restore from another server where the SIDs do not match — the user entry exists but the login-to-user SID link is broken (orphaned user).. Login's default database is inaccessible and the connection string does not override it. When no Initial Catalog is set, SQL Server tries to open the login's default database. If that database has been dropped or taken offline since the login was created, every connection attempt fails with 4060 regardless of what the application actually wanted to query.. Azure SQL: wrong database in the connection string or connecting to the logical server without specifying a database. Azure SQL Database requires an explicit database name; connecting to 'master' and then switching is not supported for most application logins. A firewall rule exists but the database itself was deleted or renamed.. Database is in EMERGENCY mode or SUSPECT state after a crash. SQL Server placed the database in an unrecoverable state. No application connections are allowed. Requires DBA intervention (DBCC CHECKDB, restore from backup) before pipelines can reconnect.

Step 1 — Confirm the database exists and check its state: SELECT name, state_desc, user_access_desc, is_read_only FROM sys.databases WHERE name = 'targetdb'; Expected: state_desc = 'ONLINE', user_access_desc = 'MULTI_USER'. Any other value points directly to the fix needed.. Step 2 — If the database is OFFLINE, bring it online: ALTER DATABASE [targetdb] SET ONLINE; Then re-run the Step 1 query to confirm state_desc switched to ONLINE before restarting the pipeline.. Step 3 — If the database is in SINGLE_USER mode, switch it back and kill the blocking session: SELECT session_id FROM sys.dm_exec_sessions WHERE database_id = DB_ID('targetdb'); — kill that session if needed: KILL ; Then: ALTER DATABASE [targetdb] SET MULTI_USER;. Step 4 — If the login exists but has no database user, create the mapping: USE [targetdb]; CREATE USER [loginname] FOR LOGIN [loginname]; GRANT SELECT ON SCHEMA::dbo TO [loginname]; For orphaned users after a restore: USE [targetdb]; ALTER USER [username] WITH LOGIN = [loginname]; — this re-links the SIDs without recreating the user.. Step 5 — If the login's default database is wrong, fix it at server level: ALTER LOGIN [loginname] WITH DEFAULT_DATABASE = [targetdb]; This prevents 4060 on connections that omit the Initial Catalog.. Step 6 — Verify the connection string. In ADF: open the Linked Service, click Test Connection. In Power BI Desktop: File → Options → Data Source Settings, edit the server/database. In SSMS: try connecting explicitly with the database name in the connection string field before testing from the application.. Step 7 — If the database is SUSPECT or in EMERGENCY mode, do not attempt application fixes. Run DBCC CHECKDB([targetdb]) WITH NO_INFOMSGS to assess damage, then restore from the last known-good backup. Notify your DBA team — this is not a pipeline configuration issue.

High severityconnection

SQL Server Error:
4060

Impact

Every pipeline and report using this connection string is dead until the database is accessible — there are no partial failures, no rows returned, just a hard connection refusal. If this is a shared linked service in ADF, all downstream datasets and dependent pipelines will stall, causing cascading refresh failures and stale data across all reports built on that source.

ADF marks the activity as Failed immediately — there is no retry that will succeed while the root cause persists, so retry policies consume their attempts and add delay without recovery. Power BI scheduled refreshes fail at the data source step and all visuals show stale data. If the pipeline feeds staging tables used by downstream pipelines, those will either error on missing data or silently process zero rows depending on their null handling. SLA breach is immediate if the database hosts time-sensitive ingestion jobs.

What does this error mean?

SQL Server error 4060 is raised at login time when the engine cannot open the database specified in the connection string. This happens before any query executes: the connection is refused entirely. In a data-pipeline context this means every ADF linked service, SSIS package, or Power BI gateway connection using that connection string will fail at the handshake stage — not mid-run. The engineer sees the error in the application layer (ADF activity output, Power BI refresh history, SSMS login error) rather than in a query result. Root causes split into three groups: the database does not exist or is misspelled, the database exists but is not accessible (offline, restoring, in emergency mode), or the login exists at server level but has no user mapping inside that specific database.

Common causes

1Misspelled or wrong database name in the connection string. The most common cause: a typo ('Slaes' instead of 'Sales'), a case mismatch on a case-sensitive collation instance, or a connection string pointing to a DEV database name that does not exist on the PROD server.
2Database is offline. The database was taken offline manually (ALTER DATABASE SET OFFLINE), is in the middle of a restore, or SQL Server failed to bring it online at startup due to a corrupt or missing file. Check state_desc in sys.databases — valid online state is ONLINE; OFFLINE, RESTORING, RECOVERING, SUSPECT all block connections.
3Database is in SINGLE_USER mode. A DBA ran a maintenance operation and left the database in single-user mode. Only one connection is allowed at a time; all pipeline connections get error 4060 if that one slot is occupied by another session.
4Login has no user mapping in the target database. The SQL login exists at the server level (visible in sys.server_principals) but there is no corresponding user in the database (sys.database_principals). This is common after a database restore from another server where the SIDs do not match — the user entry exists but the login-to-user SID link is broken (orphaned user).
5Login's default database is inaccessible and the connection string does not override it. When no Initial Catalog is set, SQL Server tries to open the login's default database. If that database has been dropped or taken offline since the login was created, every connection attempt fails with 4060 regardless of what the application actually wanted to query.
6Azure SQL: wrong database in the connection string or connecting to the logical server without specifying a database. Azure SQL Database requires an explicit database name; connecting to 'master' and then switching is not supported for most application logins. A firewall rule exists but the database itself was deleted or renamed.
7Database is in EMERGENCY mode or SUSPECT state after a crash. SQL Server placed the database in an unrecoverable state. No application connections are allowed. Requires DBA intervention (DBCC CHECKDB, restore from backup) before pipelines can reconnect.

How to fix it

1Step 1 — Confirm the database exists and check its state: SELECT name, state_desc, user_access_desc, is_read_only FROM sys.databases WHERE name = 'targetdb'; Expected: state_desc = 'ONLINE', user_access_desc = 'MULTI_USER'. Any other value points directly to the fix needed.
2Step 2 — If the database is OFFLINE, bring it online: ALTER DATABASE [targetdb] SET ONLINE; Then re-run the Step 1 query to confirm state_desc switched to ONLINE before restarting the pipeline.
3Step 3 — If the database is in SINGLE_USER mode, switch it back and kill the blocking session: SELECT session_id FROM sys.dm_exec_sessions WHERE database_id = DB_ID('targetdb'); — kill that session if needed: KILL <session_id>; Then: ALTER DATABASE [targetdb] SET MULTI_USER;
4Step 4 — If the login exists but has no database user, create the mapping: USE [targetdb]; CREATE USER [loginname] FOR LOGIN [loginname]; GRANT SELECT ON SCHEMA::dbo TO [loginname]; For orphaned users after a restore: USE [targetdb]; ALTER USER [username] WITH LOGIN = [loginname]; — this re-links the SIDs without recreating the user.
5Step 5 — If the login's default database is wrong, fix it at server level: ALTER LOGIN [loginname] WITH DEFAULT_DATABASE = [targetdb]; This prevents 4060 on connections that omit the Initial Catalog.
6Step 6 — Verify the connection string. In ADF: open the Linked Service, click Test Connection. In Power BI Desktop: File → Options → Data Source Settings, edit the server/database. In SSMS: try connecting explicitly with the database name in the connection string field before testing from the application.
7Step 7 — If the database is SUSPECT or in EMERGENCY mode, do not attempt application fixes. Run DBCC CHECKDB([targetdb]) WITH NO_INFOMSGS to assess damage, then restore from the last known-good backup. Notify your DBA team — this is not a pipeline configuration issue.

Example log output

Msg 4060, Level 11, State 1, Line 1 Cannot open database "SalesWarehouse" requested by the login. The login failed.Login failed for user 'svc_adf_pipeline'. (Microsoft SQL Server, Error: 4060)ActivityRunError: {'errorCode': '2200', 'message': 'Failure happened on 'Source' side. ErrorCode=SqlFailedToConnect,Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Cannot connect to SQL Database: ..., Database: SalesWarehouse, SqlErrorNumber=4060'}

Frequently asked questions

SQL Server error 4060 fix — what is the fastest way to diagnose it?

Run SELECT name, state_desc, user_access_desc FROM sys.databases WHERE name = 'yourdatabasename' on the SQL Server instance. If it returns no rows the database does not exist or the name is wrong. If it returns a row with state_desc other than ONLINE, that state tells you exactly what to fix. If it returns ONLINE MULTI_USER, the problem is the login's user mapping — run SELECT * FROM sys.database_principals inside the database and check whether a user exists for your login.

Error 4060 after restoring a database to a new server — why does it still fail?

A restore carries over the database users but their SIDs no longer match any login on the new server. These are called orphaned users. Fix: USE [yourdatabase]; ALTER USER [username] WITH LOGIN = [loginname]; — this re-links the existing user to the login on the new server without dropping and recreating permissions.

4060 retry — will retrying the ADF pipeline fix it?

No. Error 4060 is a hard connection refusal. The retry will fail in the same way because the root cause (database offline, wrong name, missing user) is still present. Fix the underlying issue first, then trigger a manual re-run or wait for the next scheduled execution.

What is the difference between SQL Server error 4060 and error 4064?

Both are login-time failures. Error 4060 is raised when SQL Server cannot open the database named in the connection string. Error 4064 is raised when SQL Server cannot open the login's default database (used when no database is specified in the connection string). The fix for 4064 is to change the login's default database: ALTER LOGIN [loginname] WITH DEFAULT_DATABASE = [master]; — then connect explicitly to the intended database.

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