Forum Discussion
Unable to change Single User Mode to Multi User Mode in SSMS v18.12.1
Hi, Desmond.
You can right-click on any database (that you can access, of course) and run it, or simply just right-click the root node at the top of the Object Explorer:
It doesn't matter, just so long as you're on the correct server.
The very first command of "USE [master]" will switch focus from whatever database you were on to the [master] database anyway, which is why it doesn't matter.
Cheers,
Lain
You have to replace YOURDATABASE by the database name that you have the issue with. And the script is fine to go to master since you cannot run the script if you are in the content of the DB you need to change so it is OK to run
Regards
Javier
Use master
Go
ALTER DATABASE YOURDATABASE SET MULTI_USER WITH ROLLBACK IMMEDIATE
GO
- LainRobertsonJan 18, 2024Silver Contributor
Tagging desmondfmw99 as this isn't for my benefit.
Strictly-speaking, you can execute SET MULTI_USER, SINGLE_USER, etc. from any database you have access to - it's more about obtaining the exclusive lock on the target database.
It's not a requirement to use master. It's simply established wisdom.
Here, I'm happily switching to single user mode and back out again from within the target database.
Anyhow, stick to using [master] as per Javier's original post above. This is just additional information, since the question of the significance of [master] was asked.
Cheers,
Lain
- desmondfmw99Jan 19, 2024Copper Contributor
Hi Lain and Javier,
Just to update on my current situation. I have tried the SQL script but I still got the same error as before.
I have detailed the SQL script used and also its output just in case the image that I uploaded is not clearly visible.
SQL Script Used:
USE master
GO
ALTER DATABASE [MY_DATABASE_NAME] SET MULTI_USER WITH ROLLBACK IMMEDIATE
GOSQL Script Output: -
Msg 5064, Level 16, State 1, Line 3
Changes to the state or options of database '[MY_DATABASE_NAME]' cannot be made at this time. The database is in single-user mode, and a user is currently connected to it.
Msg 5069, Level 16, State 1, Line 3
ALTER DATABASE statement failed.Completion time: 2024-01-19T09:18:35.9657458+08:00
Image of the error:
- LainRobertsonJan 19, 2024Silver Contributor
Try running the following to see which login - and from where - has the lock.
If you don't have permissions, you'll need to obtain them or have someone else that does run this content for you.
SELECT [s].[session_id] , [d].[name] AS [database] , [s].[login_name] , [s].[host_process_id] , [s].[program_name] , [s].[host_name] AS [remote client] , [c].[net_transport] , [c].[client_net_address] AS [remote client address] FROM [master].[sys].[dm_exec_sessions] AS [s] INNER JOIN [master].[sys].[databases] AS [d] ON [s].[database_id] = [d].[database_id] INNER JOIN [master].[sys].[dm_exec_connections] AS [c] ON [s].[session_id] = [c].[session_id] WHERE [d].[name] = 'yourDatabaseNameGoesHere' ORDER BY [d].[name] , [s].[login_name] , [remote client];If the results return a single row - which should be the case, you can then try the following (i.e. don't bother if there's more than one row).
Example output
Depending on the nature of what you see, possible next actions include:
- Stop the remote application/process so it releases the lock on the database;
- Use the KILL statement to terminate that session (rarely works as a standalone solution);
- Add KILL to the ALTER DATABASE statement to improve your chances of bringing the database back into MULTI_USER mode before the remote process can re-obtain another lock.
Note: KILL has some forceful options which I wouldn't suggest using until you've tried it without those options.
I'm a fan of the first option as a priority but it's not always possible.
I'd try the third option next only if the first option is a non-starter, which would look like this (you have to note down the session_id from the result of the previous query):
KILL 76 -- This should be your session_id from the earlier query. 76 is only an example value from my earlier output above. GO -- Now try setting the database back to MULTI_USER mode. ALTER DATABASE [yourDatabaseNameGoesHere] SET MULTI_USER;Cheers,
Lain