I received a query from one of the community members, before discussing his query I would like to discuss his environment first. He is working in an environment where multiple users shares the same machines and the same credentials to work on SQL Server Management Studio 2005. He asked me, if I could help him to remove the recent files activity from the menu, to restrict any other user from viewing his activities.
Given below is the screen image in SQL server 2005 with the recent files history.
I started searching the solution in SSMS and found few solutions :
Solution 1
You need to go to Tools \ Options \ Environment \ General
Here you can change the display files in recently used list from 10 (By default it is 10) to 1.
There are two issues with this solution :
- You cannot make it 0.
- If you make it 10 again, it will show you the history again.
Solution 2
You can delete the recent file activity history through registry. Open the registry via “regedit.exe” and go to the given below path with respect to the SQL Server version you are using and delete the key related to your files as shown in below image.
SQL SERVER 2005
HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server\90\Tools\Shell\FileMRUList
SQL SERVER 2008
HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server\100\Tools\Shell\FileMRUList
SQL Server 2012
HKEY_CURRENT_USER\Software\Microsoft\SQL Server Management Studio\11.0\FileMRUList
After that close the SSMS and open it again, there will be no recent files activities.
Let me know if you know a better solution.
Is there some reason why this user can’t have his/her own set of credentials? Or is this the way things are done at this facility?
I seems to me that, if you want your work to remain confidential, then you have your own login (use your Windows login to access SQL Server), and that removes the problem at the root.
Your solutions are all that I would know how to do. Furthermore, manipulating the registry is not a recommended “good DBA” practice.
Once you disable the file list, it’s not available for that login/userid, so anyone else who’s also using that login/userid will notice immediately.
Best practice: one person = one set of login/userid.
Hi Michelle,
Thank you for your feedback. Totally agree with you, But He is mostly working on development / staging servers and due to some issues they cannot create separate credentials.
Imran
This is encouraging a number of security worst practices.
Provision a number of either AD users or local users and have each developer/admin log in under their own credentials.
Advising a DBA to modify the registry is asking for a crashed machine.
Hi Marc,
Appreciate your valuable feedback. It is really not recommended to edit registry in any machine. You are right, It may crash machine. Basically, this is the last option for SQL developers / testers on development / testing machines not live server where they don’t want to share their scripting details with each other. If they have same credentials. (Also same credentials are not recommended).
Thank you.
Imran
Thanks a lot Muhammed for such great article.