@christopherlecky mind confirming what would be the purpose of doing so? Can’t you just restore with overwrite enabled (and drop connections) to allow it to go thru? 

Is there some failure you’re intermittently getting or just curious?

@Chris Hollis Unable to gain exclusive access.
this is with unconditional overwrite and drop connections enabled.

Not completely clear why but dropping the DB in the past has saved time as typically restores are done under duress.

in this case its a scheduled restore that is failing.

Apologies @christopherlecky, I didn’t see this reply.

Confirming your query was answered under a support incident. 

Issue Findings:

Support determined that there is something creating a constant logon request for that DB, meaning it is always in use regardless of the paramaters leveraged in our restore process. 

Unfortunately, there is no option built into SQL agent to drop the DB prior to restore. If this is going to be a scheduled operation then to resolve this particular issue, you can look at scripting the restore with a pre-process script. You can wrap a SQLCMD call in a .bat file.

I would be interested in finding out if you managed to try this and if this worked as you hoped?

Thanks,

Chris ​​​​​​​

Hi Chris,

That is exactly the approach I took, but I have seen this issue often enough that I was just wondering if the functionality had been baked into the product. 

Thanks for the follow up.