Skip to main content

*Msg 5064, Level 16, State 1, Line 1 Changes to the state or options of database '' 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 1 ALTER DATABASE statement failed.

Hi everyone!

This post will cover the single-user mode error for a database. There will be mention of replication, but that is not the focus of the post.

If you would like more information on replication, check out my other post here .

Here's what happened. I was tasked with setting up replication between two databases on a server. It turns out replication was no longer needed and I didn't need the database at all. So I dropped the replication publication and subscription without removing them from the database first.

This is a no-no. You should always remove replication from your database first before deleting any publication(s) and/or subscription(s).

Since I did not do it properly, the database is still associated with the replication process and knows the process is broken.

What did it do? It forced the database into single user mode.

database is in single user mode














Now I have to get this database out of single user mode so I can remove replication and delete the database altogether.

I.
Open the replication monitor:

In SSMS, right click Replication > Launch Replication Monitor

You will be able to see that the process is broken.

sql server replication monitor



















You will now have to remove the current server from under the 'My Publishers' area of replication. You will be prompted to confirm that you want to remove the publisher:


remove replication publisher










II.
You still need to get the database out of single user mode.


We need to figure out who is using the database.

'EXEC sp_who2' will show you what user is logged in to the database.

Once you find the user, you will have to kill that process with the command 'KILL spid#'.

The process that was using the database was process 60. The command I will use to stop the process is 'KILL 60'.


I received the confirmation that the process is deleted:

Command(s) completed successfully.


III.
Next, we need to see if we will be able to run any alter statements against the database so we can put the database back to multi-user mode.

Note:
As soon as you finish running the KILL command from step 2 above, you will immediately need to run these commands:


USE master;
GO
ALTER DATABASE databaseName
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO
ALTER DATABASE databaseName
SET MULTI_USER;
GO
Your database is now back in multi-user mode.

IV.
Finally, let's get the database deleted.

First, remove replication from the database.

In my environment I am using a stored procedure that will remove replication objects from the database. 'EXEC dbo.usp_Replication_Drop'

You could also use this command:

Use databaseName;

go
sp_removedbreplication 'databaseName'
go


If successful,
 you will receive confirmations similar to these:

Dropping Replication from databaseName.
Dropping All Subscriptions
Dropping All Publications

The replication option 'publish' of database 'databaseName' has been set to false.

You will be able to delete your database now:
USE master ;  
GO  
DROP DATABASE databaseName;  
GO  

That's it!

If you have any further questions, please post below.


Thank you and Happy reading,

-marshé hutchinson
#learnSQLwithme

Comments

Popular posts from this blog

event id 101 task start failed - task scheduler event id 101 launch failure

Hello again. This post is related to automating SQL server tasks with Task Scheduler. In this example I was tasked with exporting SQL server agent jobs twice a month. To achieve this, I setup a task scheduler task that ran a PowerShell script that: establishes a local connection to the SQL server. cleans the file before writing to the .sql file to avoid adding on (appending) results on subsequent runs of the task scheduler task. when a connection is established, export the SQL agent jobs on the server to a .sql file on a remote server. sends a confirmation email via the SQL server database mail profile that the SQL agent jobs were exported to the specified remote server path. That was a mouthful. Now that you know my task scheduler task is calling a PowerShell script, let's get back to why it is failing.  The good news is this error is not related to the script. The error launch failure means the task could not even run. This is most likely due to a permissi...

Msg 14234, Level 16, State 1, Procedure sp_verify_job, Line 199 The specified '@owner_login_name' is invalid (valid values are returned by sp_helplogins [excluding Windows NT groups]).

Hi guys! Here's another quick and easy post. Scenario I was trying to copy a SQL agent job from one server to another by just copying the script of that SQL job. You can copy any script by right clicking a job > Script job as > create to > new query window. I pasted the job on a different server and tried to execute it and received this error: Msg 14234, Level 16, State 1, Procedure sp_verify_job, Line 199 The specified '@owner_login_name' is invalid (valid values are returned by sp_helplogins [excluding Windows NT groups]). This error message is simply saying for the variable '@owner_login_name', the user account associated with the variable is incorrect because it does not exist. Fix Simply update the variable for '@owner_login_name' to a valid user account for the current SQL instance. Now when you execute the script again to create the SQL agent job your results will be: Command(s) completed successfully. If you have any furt...

Database "" database is not in full recovery mode on each of the server instances. The full recovery model is required for a database to participate in database mirroring or in an availability group. [SQLSTATE 42000] (Error 1465).

Hi there. This post will be a quick and easy fix. If you are not already aware, availability groups are the replacement for mirroring in SSMS (SQL Server Management Studio). We like to utilize availability groups so that there is minimal data loss. Also, in the event of some natural disaster or disk failure on a server that is participating in an availability group, the data will fail-over to a backup server (replica). I was adding a database to an availability group when I received the error: Database "database_name" database is not in full recovery mode on each of the server instances. The full recovery model is required for a database to participate in database mirroring or in an availability group. [SQLSTATE 42000] (Error 1465). The error is exactly as it sounds; The database is not in the full recovery model. To fix this: I. In SSMS, right click the database to see the properties. On the Options page, change the database recovery model to Full. II....