Currently, my database is in Single User mode. When I try to expand me database, I get an error:
The database \'my_db\' is not accessible.(ObjectExplo
Press CTRL + 1
find the process that locks your database. Look in column dbname for your db and note the spid. Now you have to execute that statement:
kill <your spid>
ALTER DATABASE <your db> SET MULTI_USER;
SSMS in general uses several connections to the database behind the scenes.
You will need to kill these connections before changing the access mode.
First, make sure the object explorer is pointed to a system database like master.
Second, execute a sp_who2 and find all the connections to database 'my_db'.
Kill all the connections by doing KILL { session id } where session id is the SPID listed by sp_who2.
Third, open a new query window.
Execute the following code.
-- Start in master
USE MASTER;
-- Add users
ALTER DATABASE [my_db] SET MULTI_USER
GO
See my blog article on managing database files. This was written for moving files, but user management is the same.
To switch out of Single User mode, try:
ALTER DATABASE [my_db] SET MULTI_USER
To switch back to Single User mode, you can use:
ALTER DATABASE [my_db] SET SINGLE_USER
Today I faced the same issue where my database was changed from Multi User to Single User mode and this was eventually stopping me to publish database.
In order to fix this issue, I had to close all Visual Studio instances and run the below command in Sql Server query window -
USE [Your_Database_Name]; ALTER DATABASE [Your_Database_Name] SET MULTI_USER GO
This command has changed the DB from Single user to Multi User and afterwards, I was successfully able to publish.
Not sure if this helps anyone, but I had the same issue and could not find the process that was holding me up. I closed SSMS and stopped all the services hitting the local instance. Then once I went back in and ran the exec sp_who2, it showed me the culprit. I killed the process and was able to get the Multi_User to work, then restart the services. We had IIS hitting it every few minutes/seconds looking for certain packages.
I had the same problem, and the session_id to kill was found using this query:
Select request_session_id From sys.dm_tran_locks Where resource_database_id=DB_ID('BI_DB_Rep');