Can you set the connection of an Exec SQL task through a dtsConfig file - configuration

Can you set the connection of an SSIS Exec SQL task through a dtsConfig file?
I have a SSIS package with an Exec SQL task, with it's Connection property set to a OLE Db Connection Manager ... it runs fine in Visual Studio.
Created a package configuration with the connection string of the connection manager, but when I try and run it from DTEXEC, I get the errors ... The specified module could not be found against the connection manager, and then ... Failed to acquire connection "ZZZ". Connection may not be configured correctly or you may not have the right permissions on this connection

No but yes ;)
You cannot directly change the connection manager through a configuration. That property isn't exposed.
What you can do is use your configuration to change the ConnectionString property on an existing Connection Manager that the Execute SQL Task uses thereby changing the connection for an Execute SQL Task at run-time via configuration.
If you need a more detailed walkthrough, I can probably generate some basic biml

Related

SSIS Logging to SQL Server does not see Project Connection

In VS 2019 I am running a simple SSIS package using a OLEDB Connection Manager which I have Parameterized the full db connection string as a Project Paramater.
This connection ('Booking') works fine throughout the package, however I have added SQL Server logging using the same connection and it is available in the configuration dropdown but when I run the package in VS I get the following error right at the start...
"Error: 0xC001000E at Package: The connection "Booking" is not found. This error is thrown by Connections collection when the specific connection element is not found."
The only thing I can think of is that I did rename the connection to 'Booking' and added parameters for teh connection string. Initially it was called something else and had no parameters. Could this renaming be the issue?

SSIS OLEDB connection not saving password when setting connection string from package configurations

I am setting up an SSIS project for testing. This project has a package where I manage some connections to SQL Server data bases, for doing this I use Package Configurations. Here I have a configuration that takes four connection strings from a table. Each is being mapped to connection string property of SSIS OLEDB connection (As shown in next image).
When I turn off "Work offline" and test the connection it works, the problem is that when execute the solution it logs some errors that are releated with the incorrect login to the data base.
I tried to do some workaround for this by setting everything manually (without Package Configurations) and changing protection level to "EncryptSensitiveWithPassword" and it worked.
It seems that the password of the connection string is not being saved when being taken from package configurations.

SSIS dynamic connectiong string via environment variable failed to execute

I want to test dynamic connection string in SSIS. Here were the steps that I already performed.
1) Created connection string.
2) Parameterizing connection string
3) Deploy SSIS Package to SSIS Catalog via Project deployment model
4) Setup environment variable in SSIS Catalog
5) Configure SSIS project to reference environment variable
Everything look goods but failed to execute the task.
SSIS Catalog
Project configuration
Error message
I think you should fix the issue with the steps below:
Create a Proxy account with permissions in SSISDB and the permissions needed for the db used in the package.
Create a credential in the SSIS server. The user and password are the same that the proxy account.
Use the proxy account to execute the project.
As per the screenshot, it looks like the package is failing due to login issue. Please check the login with which the package is running and it has correct access to DB Server.

Why does SSIS connection works with Windows but not with SQL Server authentication?

I have an SSIS package that contains a Lookup Transformation. This requires a connection to the database. At the connection manager, when I use the Windows authentication the connection works fine but when I use SQL Server Authentication then I get this error:
[A140_DAMAGETYPETEXT [3799]] Error: SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "servername.Datenbankname.sqlUser" failed with error code 0xC0202009. There may be error messages posted before this with more information on why the AcquireConnection method call failed.
Connection string:
Data Source=TheServerName;User ID=TheSQLUser;Initial Catalog=TheDababase;Provider=SQLNCLI10.1;Persist Security Info=True;Application Name=NameOfThePackage{80F4BFAB-642D-457E-9F47-1E811AFA48D0}ServerName.TheDababas‌​e.TheSQLUser;
Cause of the issue:
Your connection string is missing the Password attribute. That is the reason why the connection manager is failing to connect to the database instance.
Possible option to fix:
When you create the connection manager on SSIS, make sure to check the Save my password box so that the Password is retained in the connection string. If you do not check this box, the value will not be retained and you have to key in the value.
Package configuration:
If you are using package configurations, adding / updating the connection manager will cause the Password attribute to drop from the connection string property. I usually use database based package configuration. So, I use a query to update the connection string in the package configuration table every time I update the package configurations.
Recommendation:
I prefer to use Windows authentication so that the password to connect to the database is not exposed. I feel that Windows Authentication is little more secure than dealing with SQL Server Authentication.
here was the solution for me: click
the thread from Raj_007 was the rescue. I use a sequece container and the TransactionOption was setting to required.
I changed the TransactionOption to supported and it worked for me.

SSIS Package not executed by SQL Server Agent using password or xml config or table config

I have an SSIS package that takes data from a MySQL database and puts it in to a SQL Server table. The connection to MySQL is ADO.net. The package runs fine in BIDS.
I would like to deploy the package to be run as a Job on SQL Server 2008. The MySQL connection requires sensitive data to be either stored within the package or held in some external configuration source. If it is stored within the package it will either by encrypted with a key specific to my windows user profile or must be protected via a password.
I have tried three methods of setting up a SQL Server Agent job to execute this pacakge, and all fail:
Using a Password
I set the ProtectionLevel of the package to EncryptSensitiveWithPassword and supply a password for the package. I then save a copy of the package to the msdb. I can then connect to SSIS and run the package, at which point I am prompted for a password.
When I try to schedule this as a job in SQL Server I am prompted to enter the password by clicking on the Configurations tab of the Job Step Properties and I can see that the /DECRYPT switch has been added to the Command Line tab. The Run As property is set to the SQL Server Agent Service Account, which is mapped to a database login that has sysadmin server role. When I attempt to start this job I get the following error:
Executed as user: DOMAIN\UserROLE. Microsoft (R) SQL Server Execute Package Utility Version 10.0.5500.0 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 12:31:30 Error: 2012-07-03 12:31:31.20 Code: 0xC00291EC Source: Get Data Execute SQL Task Description: Failed to acquire connection "DATA_SOURCE". Connection may not be configured correctly or you may not have the right permissions on this connection. End Error DTExec: The package execution returned DTSER_FAILURE
It seems that using this method the package password itself is not stored anywhere for the job to access it.
Using an XML configuration file
I then created a copy of the package and set the ProtectionLevel to DontSaveSensitive and I set up a package configuration to store the MySQL credentials in an XML file. I then save this to the msdb and then when I run the package from
Integration Services I can provide a path to the config file, and all is well. However, once again when I set up a job for the package I point to a configuration file on the server but the job fails with the same error. I am wondering whether this is because the SQL Server Agent does not have an associated windows account that would allow it to read from the XML file stored in the file system.
Using a SQL Server table configuration
This time I created a copy of the package and set the ProtectionLevel to ServerStorage. I then created a [SSIS Configurations] table in the target SQL Server database. I modified the entries in this table to contain the password for the MySQL data source. Again, the package runs successfully from Integration Services, but fails with the same error as previously when run from a job. I have checked that the SQL Server Agent is able to read from the [SSIS Configurations] table ok - I set up a standalone job to test this.
Does anyone have any suggestions about what else I should do here?
I am thinking of giving up on SQL Server Agent Jobs for this and going back to having the package scheduled simply by the windows scheduler but thought before throwing in the towel I would try here first.
I am using the method of encrypting the password by setting EncryptSensitiveWithPassword as you discribed above and don't see anything you do wrong. Remember to use option keep protection level of the original package when importing the package with integration services, but it looks like you're doing that, too.
Try setting the role SQLAgentOperatorRole to your SQL Server Agent Service Account, you didn't mention that and i am not sure if you did. This could possibly solve your permission problems. (liked to answer by commenting this, but i lack of permissions here, too :)