I have scenario where I have several variables eg. sourceFilePath, sourceFileName and etc. I am storing the variables as a configurations in SQL Server Table. To store this configuration, we have to provide a connection (I have opted for OLEDB Connection).
When I am executing this from BIDS, it is working very fine and there are no issues at all.
I can change the sourceFilePath and sourceFileName from the Configuration table and the package is taking the changed path as well.
But the problem arrived when I have deployed the Package on SQL Server. I am not able to get the configuration values from table and it keeps on saying "Login failed from user.... Unable to load the configuration ...... ".
What can I do to avoide this situation?
Yes, I tried giving the password explicitly when scheduling the job but I can do the same for production server as it stores the password as a plain text.
Any help is highly appreciated.
Many thanks.
Thanks to all. I just need to set ProtectionLevel property for my packages and the rest is done. Such a small thing and it was making me nuts...
Related
Please look into the below error which I am facing. I am trying to create a new job. While configuring the step 1 for this job I am trying to set an SSIS dtsx package under SSIS db. But it doesn't allow me to select my SQL Server Database Engine under the Server drop down. It shows an empty drop down. Please let me know what could be wrong.
When you click the Server drop down, it kicks off a network scan asking any server running the SQL Browser service if they have any SQL Server instances it can talk to. The browser service can be off and SQL Server works just fine, it just means it isn't broadcasting that it is available. Some folks have a misguided belief that, much like hiding under the covers so monsters cannot find you, not advertising that you have a SQL Server instance running you're more "secure."
But the Browser service is running. Ok, then what about firewall, networking rules and potentially user account controls - it's likely that one of those is blocking packets somewhere.
In the job step configuration, you can enter a name for the step. Choose the SQL Server Integration Services Package type, enter the name of the server and select the package.
This article will help you to tackle with SSIS/SQL:
mssqltips
I had to manually enter the SQL Server name inside the Server dropdown shown in the above screenshot to fix the problem.
I have an SSIS package that has run for months daily with no problem. Suddenly it is failing every day with the error above. No changes to the package or the stored procs it runs have been pushed, to my knowledge, no changes to the database environment have been made including permissions for the service account that owns the job.
This is a SQL Server 2008 package that connects to a SQL server 2008 R2 database. The configuration is through the ssisconfig table and it defines which server to use through an environment variable.
The component in question is using a stored proc. In the proc, all fields are explicitly cast to the same data type of the table the data is being staged too. The proc runs fine by itself. It is a relatively complex proc that has two table variables and a CTE.
I can't run it from my local on prod and dev is not failing. If I open the prod SSIS package while I am set to the environment variable that the job owner uses, I do not get a validation error on this component. ValidateExternalMetadata is set to true for this component. For the entire package though, Delay Validation is set to True. I do get a validation error that would be expected on a task using a variable that is set dynamically in an earlier task. This error, however, is many, many steps later than the step it is currently failing on.
Usually in the past when we have had this sort of unspecific error, I have been easily able to see the problem with the data that caused the sudden failure. But none of the data in the proc result set is even close to being incorrect for the datatypes defined for staging table for that field. None of the required fields are missing data either.
I am out of ideas for what else to look at. If the environment didn't change, the actual code didn't change and the data looks correct, what is left to try?
As I have commented for details error, you can try below link from Microsoft:
Debug SSIS Package while calling from Agent
Some info from link:
Reasons that the package may have failed are as follows:
The user account that is used to run the package under SQL Server Agent differs from the original package author.
The user account does not have the required permissions to make connections or to access resources outside the SSIS package.
The package may not run in the following scenarios:
The current user cannot decrypt secrets from the package. This scenario can occur if the current account or the execution account
differs from the original package author, and the package's
ProtectionLevel property setting does not let the current user
decrypt secrets in the package.
A SQL Server connection that uses integrated security fails because the current user does not have the required permissions.
File access fails because the current user does not have the required permissions to write to the file share that the connection
manager accesses. For example, this scenario can occur with text
log providers that do not use a login and a password. This scenario
can also occur with any task that depends on the file connection
manager, such as a SSIS file system task.
A registry-based SSIS package configuration uses the HKEY_CURRENT_USER registry keys. The HKEY_CURRENT_USER registry keys
are user-specific.
A task or a connection manager requires that the current user account has correct permissions.
Method 1: Use a SQL Server Agent proxy account Create a SQL Server Agent proxy account. This proxy account must use a credential that
lets SQL Server Agent run the job as the account that created the
package or as an account that has the required permissions.
This method works to decrypt secrets and satisfies the key
requirements by user. However, this method may have limited success
because the SSIS package user keys involve the current user and the
current computer. Therefore, if you move the package to another
computer, this method may still fail, even if the job step uses the
correct proxy account.
Method 2: Set the SSIS Package ProtectionLevel property to ServerStorage Change the SSIS Package ProtectionLevel property to
ServerStorage. This setting stores the package in a SQL Server
database and allows for access control through SQL Server database
roles.
Method 3: Set the SSIS Package ProtectionLevel property to EncryptSensitiveWithPassword Change the SSIS Package ProtectionLevel
property to EncryptSensitiveWithPassword. This setting uses a password
for encryption. You can then modify the SQL Server Agent job step
command line to include this password.
Method 4: Use SSIS Package configuration files Use SSIS Package configuration files to store sensitive information, and then store
these configuration files in a secured folder. You can then change the
ProtectionLevel property to DontSaveSensitive so that the package is
not encrypted and does not try to save secrets to the package. When
you run the SSIS package, the required information is loaded from the
configuration file. Make sure that the configuration files are
adequately protected if they contain sensitive information.
Method 5: Create a package template For a long-term resolution, create a package template that uses a protection level that differs
from the default setting. This problem will not occur in future
packages.
Above link will help you through logging and other possible scenarios of failure of your package from SQL Agent. I suspect that your user of Agent has been corrupted. But that is an assumption. You first enable the logging of SSIS by following link :
Enable SSIS Package Logging
Some info from link
To set the logging level for a package by using the Execute Package
dialog box
In SQL Server Management Studio, navigate to the package in Object Explorer.
Right-click the package and select Execute.
Select the Advanced tab in the Execute Package dialog box.
Under Logging level, select the logging level. See the table below for a description of available values.
Complete any other package configurations, then click OK to run the package.
Hope this will help you in the first place. If not please let me know.
I have many packages that are using the package configuration with the following way:
-ALL Packages have the XML configuration file that has only one proporty defined. The ConnectionString of the SQL Server connection that holds the configuration table for the rest of the properties
-A SEPARATE SQL Server package configuration for each connection manager in the package.
-Finally i have an SQL Server configuration for all the properties that are specific to this package.
I attach a pic of what i mean:
Yellow is the XML config with the connectionstring, Blue the connectionamangers and purple the package specific.
So with this setup i can:
Change the xml file location and just point all the setup in another sql server or another database.
Or create different configuration filters in the same config table and try to go into the package and change the filter.
With all the above the problem is that if i do anything from within VS, i am loosing the password in the connectionstring because i am not using the encrypt property. And i dont want to use it...
What are my options? Just go in .dtsx with notepad and chage what i want BEFORE i open the package or before i deploy?
-I dont want to use EncryptSensitiveWithPassword, so:
When i go to package configuration and try to change the ConfoigurationFilter to point to another setting then i am getting to the screen to select the property (connectionstring) and when i finish the DATABASE record for the setting is cleared from the Password= that i have put previously.
So i short what i want:
-No EncryptSensitiveWithPassword in my packages.
-Being able to change configuration from within VS WITHOUT resetting the connectionstring string.
The recommended way for setting this up would be to store the file location of the dtsconfig file in an environment variable. Then change the dtsconfig to use the environment variable rather than a hardcoded location.
So the nuances of that scenario are this:
The password gets blanked out when you resave the xml file (as you pointed out in your question). This is what it is, and it is one of the reasons I never use them.
A process (devenv.exe) will cache the values of the environment variables on start up. This means you need to restart visual studio if you make a change to the value of the environment variable.
The same issue above applies to the integration services service. This will need to be restarted after you add environment variables. Or when you run your packages, the values will not be found.
The idea is that your dev machine points to a dev instance. Then as you migrate the packages to new environments - QA, Prod, each server has it's own environment variable pointing to its respective dtsconfig file.
As a side note, a similar pattern which avoids the password obliteration would be to add a sql connection manager which points to the server which will load the rest of the configurations. Then set the connection string of this connection manager with an environment variable. The advantage is that you don't have to go copying config files around. This works best with integrated security so you are not storing credentials in an environment config. If you want to be more cryptic about it, you could use a registry entry.
Error :
Argument "ETL" for option "connection" is not valid.
The command line parameters are invalid. The step failed.
While executing the Job in SQL Server Agent.
This is often a problem with parameter configuration, see e.g. here.
When you run from inside BIDS, you are in an environment where your parameters are available. When you schedule an SSIS package as a SQL Server job, those parameters have to come from somewhere. You can reference them in a configuration file, and you can override them in the configuration tab for the job.
Today I faced exactly same issue and I fixed it. What I did is, renamed connection name (without space, dots,hyphen) in my SSIS package. Previously I had default connection name so it showed error as
Argument "****" for option "connection" is not valid. The command line
parameters are invalid. The step failed.
later I changed both source and destination connection names(without space) and used those packages while scheduling Job in SQL Server Agent and tried Start Jot at Step and succeeded.
I had a similar issue where the paramater value ended in a backslash. I just removed it and appended it back in an expression within the SSIS package.
I also had a similar problem, I made a change deployed and it stop working, I tried to remove spaces and hyphens as suggested above (I have 2 connections at fault) and still nothing, well it did make an effect as in the error message switched from one connection to the other - arrrgh, after pulling all my hair out all day. I just had a thought to delete the job and recreate and it worked! Also BIDs I definitely think there is some kind of configuration bug in that after you deploy and try to manually change the connection manager it fails, so my workaround is to configure first, then deploy, (delete existing job if present) then create the job, so repeat for each environment u need to deploy to.
I have a package that imports from a AS400 file to SQL. The package executes properly within Visual Studio, but fails when set up as a scheduled job. the error message is that my password is incorrect. I know that it is correct. I also setup a package configuration and this did not work. I have searched and tried many things. Could someone give me some assistance?
Your password is incorrect.
Seriously, you "know" that your password is correct? You know better than the code attempting to use your password? Does this seem likely to you?
Consider the possibility that you and SSIS may be referring to different passwords. Maybe the one you "know" is correct actually is, but the other one is not.
Possibly a stupid answer, but how are you connecting to the AS400? If it's using ODBC drivers, you'll need the AS400 drivers installed on both local (dev) and your SQL server box. They're notoriously picky about versions.
If memory serves me correctly, when you set up the ODBC connection using the AS400 driver software, I think you need to specify connection details as well and they get explicitly saved in the ODBC connection.
The support link above is correct. To boil it down to a simple answer. Password protect your SSIS package to save the credentials needed to connect to the AS400.
With the ODBC configuration: use a system DSN instead of user DSN, it will work!
Try to use odbc connection or try to redeploy the package on your SSIS Server.