Login failed while deploying data


Author
Message
Greg McGuffey
Greg McGuffey
Strategic Support Team Member (4.8K reputation)
Group: Forum Members
Posts: 2K, Visits: 6.6K
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!
Reply
Trent Taylor
Trent Taylor
StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 7K
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.

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...





Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search