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.
Related
We are running an SSIS Package from a SQL Server 2014 instance which connects to a remote SQL 2016 Server through an SMO connection in a Transfer Objects Task. This task retrieves schemas, tables and SP's. The SSIS package has three of these tasks running in parallel which connect to three different Db's on the same SQL server.
Things had been running fine until a day last week the owners of the remote SQL Server decided to create a new user/password combo to give to us. No permissions changed or anything else, only the u/p.
After they did that the package has been failing with various connection type errors. The errors happen randomly on the three parallel tracks. Here are the errors:
Failed to retrieve data for this request.
Invalid Operation: The connection is closed.
There is already an open DataReader associated with this Command which must be closed first.
Property TextHeader is not available for StoredProcedure '[Sp Name]'. This property may not exist for this object, or may not be retrievable due to insufficient access rights. The text is encrypted.
But on the DB side the error the profiler was showing was the password was invalid. This is not true.
After some extensive troubleshooting we tried giving he user SA rights, which did not help. On further work we tried changing the password to 123 (while keeping SA rights,) the prior password had been a 10+ char non-alpha-numeric (had the ! char) password, for example aBc12dEF3!!!. We tried removing the ! chars and various other iterations, but that didn't work then we finally got it down to the password being 123.
This final password change worked. But obviously this is not normal, we cannot have user with SA rights and 123 as password.
Does anyone have any ideas, advice, direction on what could be going on here?
Thanks!
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
This is my first time trying to extract data from an Oracle database and push it into a Microsoft SQL database, and I'm running into an issue I cannot find a way around. I've installed ODAC, Oracle Client, on the SSIS machine and am able to see and use the Oracle Provider for OLE DB Connection manager just fine. I put in the Oracle server name, login, PW, test the connection, works fine. I can even run the SOURCE query and load it into our SQL database just fine. But if I try and deploy the package, or open up the connection manager again, everything fails because the password isn't saved, despite the obvious "save password" checkbox being checked.
After some searching, it appears that checkbox just doesn't do anything, and I've tried the following workarounds with no success:
Configuration Files. Set up the package to use a configuration file, tried to hard-code the password into that, both on its own and/or included in the connection string line. The package just ignores the password in either case.
Expressions. I've tried using the expression in this format: "Data source=SERVER;"+ "user id = USERID; " + "password = PASSWORD; " + "Provider = OraOLEDBOracle.1; " + "persisit security info = true;", which fails (connection manager always switches to "offline" mode and doesn't seem to process the expression), and also tried to just use the expression for "password" which... sort of worked one time, inside SSIS (it seems to run and looks OK inside the data flow but on the control flow the Connection Manager shows as offline again) but fails when deployed.
In all cases, I've tried using various ProtectionLevel settings: DontSaveSensitive, EncryptSensitiveWithUserKey, EncryptSensitiveWithPassword (and then adding the password to the execution of the package in the SSMS job manager). None have worked any different than the others.
I've tried this both on our actual server where our SQL DBs and SSIS server live, and on my local machine to test out the same settings to ensure it's not machine-specific. I've uninstalled and reinstalled Oracle and the ODAC on both at least once now.
At this point I can't find any other suggestions, it seems like one of those setups has worked for everyone eventually after installing everything properly. And again, the package WORKS as long as I set the password IN the connection manager and run the package manually inside SSIS, but not under any circumstances outside SSIS.
I've spent more than 2 straight days trying to troubleshoot this and am beginning to lose my mind. Aside from the obvious complaint of "What the hell is that save password checkbox even for then" I dunno what to try at this point. I really really want to use the Oracle Provider because some of this data is using complicated queries and even the smallest one is 200K+ rows, and hitting the corporate "warehouse" so it's essential to be as efficient as possible. If there's no other alternative I could try the older OLE DB Connections but that's an absolute last resort at this point.
Other info I can think of: Using Visual Studio 2010 (tried both free and professional versions), tried running both 32bit and 64bit runtime on packages (runs fine either way in SSIS but neither way in SSMS because... no password), and I have no control over the Oracle server/DBs and there's 0 chance of getting a no-password account for access (nor should I need to frankly)
Thank you for any assistance or tips!
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.
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