I'm setting up a development machine in which I need to maintain an SSIS package created by another developer. I can't get the package to run on this new machine, either in Visual Studio or as a SQL Server job. The most helpful message comes from Profiler:
Login failed for user 'MyUserName'. Reason: Password did not match that for the login provided. [CLIENT: <local machine>]
I know what the password should be, but I can't find where to set it.
To debug this, I've tried two ways of modifying the credentials to specify a different user, but the different user name is not being used in the connection attempts.
First I tried modifying the data source properties in Visual Studio.
Then I tried modifying the package config.
Data Source=.\SQL2014;User ID=DifferentUserName;Initial Catalog=dbname;...
The original user name is still being logged in Profiler, so I'm wondering where else to look for the credentials.
Related
I'm working on an SSIS package to extract data from one old database and move to a SQL database. The only way to connect to the source database is using ODBC. I set up an ADO.NET connection manager and project parameters to store the username and password. Then I went to the connection and chose "Parameterize...". I selected username and password and linked to the project parameters I set up. The connection continues to fail. The only way I've been able to get it to work is to allow the package to save sensitive data and to save the password in the connection manager (going to edit, typing in username and password, then saving). If I rely on the parameters it does not work. I also tried deploying to the SSIS catalog, then executing by going to the package and entering the credentials under the Connections Managers tab. The only way I've been able to get this to work is to allow it to save sensitive data, enter credentials directly in the package and then save.
I cannot figure out why it will not pass the username and password from parameters or with the connection manager when executing in SSMS. The error I get back is that it's missing the password.
Any help would be greatly appreciated! I'm not new to SSIS, but have tried everything and can't seem to make this one work. I'm stuck using ADO.NET and ODBC.
Few things to do:
Set the SSIS package ProtectionLevel to SaveNoSensitive.
Go to the connection and chose "Parameterize..." and select the
entire connection string.
Assign proper values to Project level parameter that is used to parameterize the enire connection string.
I have created a project level sql-server connection for my SSIS project. There are multiple packages which utilise this connection and it works perfectly fine. However, I have a new package which contains an "Execute SQL Task". This task also utilises the same connection but throws an error saying "login failed for user".
It might be one of these things:
The Protection level property that is set to DontSaveSensitive, meaning the password doesn't get saved. You can choose to change it to EncryptSensitiveWithUserKey. Although I wouldnt suggest this when you deliver the project to Deployment server
If you are using package configuration and saving the connection string to a XML File (for example) the password won't get saved, you have to add it manually. Something like: ;Password=someReallyCoolPassword;
Even if you do at the password manually, it can still have some problems. I believe it can be that the word "Password" is sensitive itself, and even if you have protection level as DontSaveSensitive, when the package read the XML File, it wont read the password value. I have no idea why, but have to put a blank space before Password, like this: ; Password=someReallyCoolPassword; and it will work, although your connection could be seen if someone hover the mouse over the connection manager.
If you could add more information about how you are handling your connection, I could give you a mroe specific answer
I have an SSIS Package that I created through the Import Export (32-bit) Tool. When I executed the package manually through the Execute Package Utility the package run successfully with no issues. However when I try to run the package through a Job Agent in SSMS I keep getting errors. The primary error I get seems to be:
Failed to decrypt protected XML node "DTS:Password" with error
0x8009000B "Key not valid for use in specified state" You may not be
authorized to access this information. This error occurs when there is
a cryptographic error. Verify that the correct key is available.
I'm using SQL Server 2008 R2.
I have researched this error to some degree and I think it has something to do with the package protection level. I feel like I've tried the configurations that make the most sense but none seem to be working for me. The Options are:
Encrypt sensitive data with user key
Do not save sensitive data
Encrypt sensitive data with password
Encrypt all data with user key
Encrypt all data with password
Rely on server storage and roles for access control
I feel like Ishould be using the last option here (Rely on server storage...) because I prefer to use SQL Server Authentication. I use SQL Server Authentication on the 'Choose Destination' window of the SQL Server Import and Export Wizard, and similarly I use this with the same username and password when I create the Job Agent in SSMS on the General Tab of the Job Step Properties. Is it possible that there is something that I need to add to the User I'm using in SSMS - even though it works outside of SSMS?
Something else I wondered that might have an impact is having the option "Drop and Re-create destination table" checked in the Column Mappings window of the Import and Export Tool. I was using a stored procedure to remove the tables before executing the Job Agent and I feel like ti was working at one point - could that have something to do with it?
Again the thing that baffles me most is that it runs no problem when I execute it manually through the 'SQL Server Execute Utility Package' tool.
I've included images of some of the windows I mentioned above if that helps.
So I'm trying to setup Railo and I want to add a datasource.
For the database I'm using Microsoft SQL server Management Studio.
But now I've run into the classical problem: "Login failed for user 'sa'. ClientConnectionId:afd80ac2-0744-4a7d-a9f7-083d93adee0d"
What I've done so far:
With the SQL Server Configuration Manager in the TCP/IP settings I enabled the IPs I had to.
I set the password for the user 'sa' in MSSQL and I added a user mapping for the table I want to use.
I made the user 'sa' the owner of the DB i want to connect to
Restarted the SQL service, my computer and Railo multiple times.
I'm pretty much out of ideas.
After Leigh mentioned in the comments to look at my logs it had the following message: "Login failed for user 'max'. Reason: Failed to open the explicitly specified database 'test'. [CLIENT: 127.0.0.1]"
I then tried to make a connection without mentioning a database and that worked.
I would also point to Leigh's answer here which explains how to turn Mixed-Mode authentication on, as this can also cause this error. Since the cause of this isn't on Railo/Lucee's end, this issue still arises in 2018.
I just don't want a useful answer to get lost to history, nor plagiarize an answer I barely found.
I'm getting this error when running an SSIS package through SQL Agent
Failed to acquire connection "ORACLE ADO.NET". Connection may not be configured correctly or you may not have the right permissions on this connection.
When I log on as the SQL Agent User and run the ssis package directly it is fine. When I then execute it through the SQL agent job, it fails.
I've read around extensively on this topic, and it seems a lot of the advise concerns how you are logged in, configuring of proxy accounts, etc, etc, etc, none of which has been helpful.
I am logging onto an Oracle database with an ADO.NET conncetion. The connection string is as follows (datasource, userid and password have been changed):
Data Source=DATASOURCE;User ID=userid;Password=password;Persist Security Info=True;Unicode=True;
I'm loading this from a registry setting using package configuration. To check that I am getting the correct string, I am writing it into a temporary log table. I am definately getting the string I need from the correct registry setting.
I've tested the oracle login credentials though PL/SQL developer, and it lets me login just fine.
As far as I can tell, as I'm using an explicit user name and password for the Oracle connection it just shouldn't matter who the SSIs pacakge is run as. The only point of failure that Ican see would be the reading of the information from the registry, but that seems fine.
I'm really quite baffled, I must confess, and would appreciate any help some of the splendid experts here can offer.
Many thanks,
James
Ok, tracked this one down after quite a lot of pain.
It was working fine on one environment, but not another, so I fired up Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) and ran a package through the SQL Agent job, comparing which system entities were hit on each enviroment.
On the failing environment, at the point of the bulk transfer operation, the package attempted to get the Oracle 11 client DLL, and then hung.
I knew that this was installed, and, moreoever, the DLL path was a system environment setting. After further investigation it was revealed that the server had not been rebooted since the Oracle Client install and the SQL Server Agent process had not bee recycled.
Yes, can you believe it, the old helpdesk fix "Can you reboot your computer?" worked.
Sigh!
We had issues at a client with running packages connecting to Oracle before stored on our sql server instance. The work around we found was to change the package property, protection level, to "Dont save Sensitive Data" and for security purposes, we encrypted the username and password in the package configuration that was decrypted by a udf in sql server. Of course, before you try the whole encryption part, I would recommend putting the username and password in the package configuration without encrypting the values to see if changing the protection level setting is the solution to your specific problem. I hope this helps.
I was getting this error when tnsnames.ora file did not have a valid entry for the environment