InletDownload

SQL Server error 4060

Cannot open database requested by the login. The login failed. (Error 4060)

Your login and password were accepted, but the database named in the connection string couldn’t be opened for that login: it doesn’t exist, isn’t online, or the login has no user in it. SQL Server then fails the whole sign-in with error 18456 as well.

Cannot open database "sales" requested by the login. The login failed.

Tested on SQL Server 2022 (16.0.4295.3); also 2019 (15.0.4490.9) and 2025 (17.0.5005.3) · Updated 9 October 2026

What it means

Signing in to SQL Server has two steps: the server checks the login and password, then opens the database you asked for (Database=, Initial Catalog=, -d in sqlcmd). Error 4060 means the second step failed. The server sends it, then fails the whole sign-in, so most clients show two errors:

Msg 4060, Level 11, State 1
Cannot open database "sales" requested by the login. The login failed.
Msg 18456, Level 14, State 1
Login failed for user 'reader'.

The message is the same whether the database doesn’t exist, isn’t online, or exists but your login has no user in it: SQL Server doesn’t tell someone who can’t use a database whether it’s there. The server’s error log says a little more, as error 18456 with state 38:

Error: 18456, Severity: 14, State: 38.
Login failed for user 'reader'. Reason: Failed to open the explicitly specified database 'sales'. [CLIENT: 192.168.148.1]

Two near relatives:

  • 4064, “Cannot open user default database. Login failed.” You didn’t name a database, so the server tried the login’s default database, and that one couldn’t be opened (state 40 in the log).
  • 911 and 916 are what you get when you’re already signed in and run USE: 911 Database '<db>' does not exist, or 916 The server principal "<login>" is not able to access the database "<db>" under the current security context. They tell apart the two cases 4060 hides.

Common causes

  1. The name is wrong. A typo, the database from another environment, or a different server or instance than you meant. On a server installed with a case-sensitive collation, database names are case-sensitive too.
  2. The login has no user in that database. A login only gets into the databases where a user is mapped to it (or where the guest user is enabled).
  3. The database isn’t available: offline, restoring, recovering, being upgraded, or in single-user mode with someone else already in it.
  4. A newly created, restored or copied database that isn’t ready yet, or a restore that brought the database but not a user for your login.
  5. On Azure SQL Database, a database name that doesn’t match the one in the portal, or a brief reconfiguration: Microsoft lists 4060 among the transient errors that go away when you retry.

How to fix it

Check the name and the database’s state

Connect without naming the database (you land in master, or your default database), and list them:

SELECT name, state_desc, user_access_desc, HAS_DBACCESS(name) AS has_access
FROM sys.databases
ORDER BY name;

state_desc should be ONLINE and user_access_desc MULTI_USER; has_access is 0 where your login has no way in. Copy the name exactly into the connection string.

Give the login a user in the database

As an administrator, in that database:

USE [sales];
CREATE USER [reader] FOR LOGIN [reader];
ALTER ROLE db_datareader ADD MEMBER [reader];   -- or the permissions it needs

If the database was restored from another server, the user may already exist but point at a login that isn’t on this server. Link it to your login instead of creating a new one:

ALTER USER [reader] WITH LOGIN = [reader];

Bring the database back

ALTER DATABASE [sales] SET ONLINE;
ALTER DATABASE [sales] SET MULTI_USER;

Before setting a single-user database back, see who is in it:

SELECT session_id, login_name, host_name, program_name
FROM sys.dm_exec_sessions
WHERE database_id = DB_ID('sales');

A database that is RESTORING is waiting for the rest of a restore sequence (RESTORE DATABASE … WITH RECOVERY finishes it); RECOVERING or RECOVERY_PENDING means SQL Server is still bringing it up, or couldn’t: the error log says why.

The default database (error 4064)

Name a database in the connection string, or change the login’s default to one that exists:

ALTER LOGIN [app] WITH DEFAULT_DATABASE = [master];

Azure SQL Database

Use the database name exactly as the portal shows it, with the server’s full name (<server>.database.windows.net). If the error comes and goes, retry after a few seconds: Microsoft counts 4060 as transient there, during reconfigurations. Contained database users (created in the database WITH PASSWORD) can only open their own database, so the connection string must name it. See connecting to Azure SQL Database.

Reproduce it

On SQL Server 2022 (RTM-CU27, 16.0.4295.3) in Docker, with sqlcmd 18.6. The login reader has a user in database inlet but not in sales:

sqlcmd -C -S localhost -U reader -P <password> -d sales -Q "select 1"
sqlcmd -C -S localhost -U inlet -P <password> -d nosuchdb -Q "select 1"
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Cannot open database "sales" requested by the login. The login failed..
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Login failed for user 'reader'..
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Cannot open database "nosuchdb" requested by the login. The login failed..
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Login failed for user 'inlet'..

Reading the errors the server sent, with a short TDS client script, showed Msg 4060, Level 11, State 1 then Msg 18456, Level 14, State 1 in both cases: the existing database and the missing one look identical. The error log had state 38 and “Failed to open the explicitly specified database” for both. Once signed in to inlet, USE told them apart:

Msg 911, Level 16, State 1, Server 7732422b7f56, Line 1
Database 'nosuchdb' does not exist. Make sure that the name is entered correctly.
Msg 916, Level 14, State 2, Server 7732422b7f56, Line 1
The server principal "reader" is not able to access the database "sales" under the current security context.

SQL Server 2019 (15.0.4490.9) and 2025 (17.0.5005.3) gave the same errors.

On a temporary SQL Server 2022 container (same build), a database set OFFLINE and one in SINGLE_USER mode with another session in it both gave the same 4060 and state 38, even to sa. A login whose default database had been dropped, connecting without naming one, got Msg 4064, Level 11, State 1 “Cannot open user default database. Login failed.” and state 40 in the log.

In Inlet

Paste the connection string your app uses (an ADO.NET string with Initial Catalog=…, JDBC with databaseName=…, or a sqlserver:// URL) and Inlet fills in the connection form, so you can check the database name before you connect. When the server refuses, Inlet shows SQL Server’s own message, with SQL Server error 4060, state 1, severity 11 in the detail, and links to this page.

Related

Sources