Original: Unable to use SQL login to login to SQL Server-' Password did not match '
Originating From: http://blogs.msdn.com/b/apgcdsd/archive/2011/02/01/sql-login-sql-server-password-did-not-match.aspx
Problem Description: In Management Studio on a single machine, SQL login is not always available to log on to SQL Server. However, if you use the same SQL login on other machines, you can log in to SQL Server.
Error message: ' Password did not match '
Diagnostic steps:
1. Can I use SQLCMD to connect to SQL Server on this machine and log in with the same SQL login to succeed?
2. Create a new SQL login but use a blank password. Is it possible to log on to SQL Server with the newly created SQL login and the empty password on the offending machine?
If both 1 and 2 are successful, we can basically determine that the problem is due to the failure of the Management Studio tool to encrypt the pass-through password.
The Management Studio tool needs to be encrypted first before it passes the password we enter on the interface to SQL Server. Where does this encrypted password exist?
We can run the%appdata% environment variable to check the path in run. Usually this path is set to%userprofile%\appdata\roaming. Under this path, continue to find the Microsoft\protect directory.
All encrypted caches are stored under this directory.
Let's look at some of the causes of this problem:
1. You can try emptying all files and folders in the Protect directory and try again.
2. Run%appdata% error directly, unable to open the specified path, this is usually the path pointed to%appdata% no permissions, or%appdata% point to the path is wrong. %appdata% is stored in the following registry key value, and we can verify that the path is valid by accessing the registry: hkey_current_user\software\microsoft\windows\currentversion\ Explorer\user Shell Folders\appdata.
3. For registry key value HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell folders\appdata. No access rights. This is also easy to confirm by accessing the registry key value.
As long as our current user confirms access to the registry key value, the path stored in the registry key value is valid, and the current user has access and write access to the path stored by the registry key value, which can be resolved.
Sometimes we find that the Protect folder is not found in the Microsoft subdirectory under this directory, as long as these three prerequisites are checked, modified and ensured, the Protect directory is automatically created when management Studio uses encryption. So the Protect folder does not exist and is not the cause of the problem.
Cannot use SQL login to log in to SQL Server-' Password did not match '