I'm attempting to deploy my security tables using the DDT. When I do the deploy, I create a new package, which includes the permissions table as part of the deployment. I first got an error that a login (to a common db user for the dev db) failed because the user needed to change their password. I figure out that this is set on the permission package, so I go to SQL Server and change it and update the password for the permission data. Now I get an error that the login is just failing...sigh... So I open up SQL Management Studio and test the user/password (all sql user/passwords btw). They work...sigh... So I change the user/password to another one. I STILL get an error related to the login failing for the first user.



Now, I decided I didn't want to deploy all the security tables, so I deleted some of the packages. Could there be some residual info that could be causing this problem? I'm stuck until I can get this solved (can't deploy).



Thanks!

Whenever you went to SQL Server to update the data, did you change the us_Data field?  That's the field that contains the password, so if you change it in the database, the user won't be able to log in.  Now, for the user that you created within the Security Maintenance to work, the project encryption key (set in the security project) will need to be the same key as the one you specify within your application (through the SecurityBasics.SetSecurityKeyAndVectorForUserAuthentication() method).  This value determines the "seed" for the encryption key and vector that are used to encrypt the data for the user.  Can you give me any more details on what you changed in SQL Server to change the user's password?

I think you are misunderstanding me. The login failure is a SQL Server login, not a SF login. This is occurring when I'm attempting to deploy a project from DDT. There has never been that particular user in the SF users table (when it worked the last time I used).

This is still an outstanding issue...any ideas?

Greg,

There is not a lot of "magic" that happens here.  From what I understand you are getting the login error when the deployment data tries to create the package based on the credentials supplies in the deployment data record, correct?  If the login error is occuring when the deployment data is trying to be created then it would have to be the credentials supplied within that record.  The first thing I would try is setting up a test profile that creates the deployment data to ensure that it is not a profile issue.  Another issue that I have seen in the past is the resolution of the SQL Server.  For example, I have a machine in the office and one at home, both from which I create the packages from.  At home, it cannot resolve the DNS name properly, but at the office it can.  So I put in an IP address since the IP is the same at home as well as the office, this way there is always resolution.  I also always supply the SQL login information rather than relying on Windows Auth for the same reason.

When SQL authentication issues arise it is generally a configuration or data issue.  If the problem keeps up let me know and we can dive into the database itself and see what is in there.