I have an SSIS package to load data from multiple CSV files into an SQL staging table, then aggregate the rows of the staging table and insert those records into a destination table and finally delete the staging table rows.
The Package works fine when run manually.
When run using the windows task scheduler(using a .bat file), the package manages to load data from CSV into staging but doesn't do the aggregation ,insert and delete steps.
There are no errors seen in the Task scheduler post execution.
In the SSIS logs however, the following error was seen: Executing the query "" failed with the following error: "Retrieving the COM class factory for component with CLSID {32E37890-EC10-4F89-8D74-1B8CAA4C95F2} failed due to the following error: 8007007e The specified module could not be found. (Exception from HRESULT: 0x8007007E).". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly .
I am not very savvy with the tool so wasn't able to understand what the error meant or how to resolve this.
I have not found the need to use any parameters in this package as the operations are quite straight forward and did not require any.
The .bat file contains
"C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\DTExec.exe" /f "E:\Third Party Supply Performance\CNMA_DATA_EXTRACTION\CNMA_3RDPARTY_SUPPLY_DATA_EXTRACT\CNMA_3RDPARTY_SUPPLY_DATA_EXTRACT\CNMA_DATA_EXTRACTION.dtsx"
Could someone share some guidance on this issue or what I may be missing in terms of package design?
Related
I am building out a new SQL Server 2019 database and using SSIS 2019 to import data from various sources. Most of my SSIS packages are randomly failing on the server (but not when I run them from Visual Studio), but then will run successfully, and then fail again. The failure error can change from failure to failure on the same package.
To simplify things, I built a brand new Test package that executes a stored procedure to see if I could isolate the problem. The Test package has only the one SQL task and the Connection Manager.
The Test package also randomly fails but is always for the same reason: cannot find the Connection, which it lists by the GUID. It will run several times, then fail once, sometimes twice, then run 5 or 6 times in a row, then fail. Off and on.
The packages are deployed to Integration Services Catalog and I'm calling them using Autosys to run the DTEXEC command.
Any ideas on what would cause a random failure like this?
I am currently migrating a database from an old SQL Server 2012 to a new system running SQL Server 2019. In addition to the database I am also migrating several SQL Server Agent Jobs.
One of these jobs consists of multiple different steps, one that just runs a PowerShell script and two other steps that are implemented as an SSIS package. When I execute one of the steps that are implemented as SSIS package, I get the following error:
The process could not be created for step 2 of job <long hexadecimal number> (reason: The system cannot find the file specified). The step failed.
How am I supposed to diagnose this error? I have no idea which file cannot be found and why. Is there no way to get any additional information about this error? I already checked all files involved in the SSIS package such as the package file itself, the configuration file and all files that are accessed during the execution of the step but I cannot find the reason for this error.
Could there be a compatibility issue since the packages are executed in a new SQL Server 2019 instead of the older SQL Server 2012? If so, how can I check if this is actually the case?
Thanks a lot in advance!
Having the exact same issue.
Found a workaround, don't like it, but it did get the package run.
Change "Type" from SQL Server Integration Services Package" to "Transact-SQL script (T-SQL)"
Make your SQL Statement something like:
EXEC xp_cmdshell '""C:\Program Files\Microsoft SQL Server\150\DTS\Binn\DTExec.exe" /FILE "\"<Path To Package>\<PackageName>.dtsx\"" /WARNASERROR /X86 /CHECKPOINTING OFF /REPORTING E'
Note that the start of the command '"" is NOT a type-o, neither is the \"" right after the .dtsx package name.
Don't like this answer, but until the correct solution comes along... it is working.
I have an SSRS report. I am downloading that as an Excel file through SSIS package. I have created a script task for that. This is working fine.
But the problem is when I am trying to run the SSIS package through SQL Server Agent job, it fails. I am not able to find where I am going wrong in this?
Please help me solve this.
I have already tried creating Desktop folder in
C:\Windows\SysWOW64\config\systemprofile
I have also tried changing the ProtectionLevel to DontSaveSensitive at both project and package level.
Error Description: The script returned a failure result. End Error DTExec: The package execution returned DTSER_FAILURE (1).
I have built an SSIS package that imports a file, processes it, and generates another file.
I use a flat file source destination, and it correctly rejects rows that fail validation using the "redirect" settings, including when a column is missing in a row. All other rows continue to be processed, and I can log my "error" row in a log file.
This works fine in the developer tools.
When deployed to a server, the package works fine, rejecting rows that have validation errors (eg data type errors) and writing them to my error log.
But when I try to test a file where a row has a missing column, the package just hangs and never completes, and shows no errors.
I have tested this with the same file on my machine in the dev tools, and on the server. The package performs correctly picking up the file, writing the error log, and writing the output file fine on the server for all other scenarios (so I don't believe it is a permissions issue reading/writing to disk)
The flat file connection manager has Format = Delimited, and is otherwise performing correctly as far as I can tell.
We have a test package that was designed using VS2017 that has one "Data Flow Task" object with "ODBC Source" and "ODBC Destination" objects within it. The package is simply trying to move records from table 'Table_1' to table 'Table_2' in the same SQL Server 2014 database named 'Test'.
When we execute the package from VS2017, it runs successfully.
However, when we import that package into SSIS, and then run the package directly from there, we get the following error messages (see screen shots below):
The version of ODBC Destination, clsid {51B271F1-3B7E-4875-870E-62A0456FE2AD} is not compatible with this version of the DataFlow.
The version of ODBC Source, clsid {F8600F4A-E321-42F4-AA59-DA00FA374EA5} is not compatible with this version of the DataFlow.
The component is missing, not registered, not upgradeable, or missing required interfaces. The contact information for this component is "ODBC Destination;Connector for Open Database Connectivity (ODBC) by Attunity; Attunity Ltd.; All Rights Reserved; http://www.attunity.com;7".
Any ideas as to what is causing these errors?
Couple side questions / interesting notes:
Why is it referencing Attunity? We are not using the Attunity connectors. We are using ODBC. I don't even have Attunity installed on this machine (I did at one point but uninstalled it).
If you don't use the DataFlow task with the OBDC driver and just use a simple 'Execute SQL Task' object in the package that runs a simple 'INSERT INTO Table_2...' statement, the package runs in SSIS. There is something wrong with using the Data Flow Task.
Screen shots:
Here you can see the package is running successfully in VS2017:
The package was imported into SSIS:
When you run it in SSIS, it fails with the following errors:
Found the answer from other posts.
First, change the TargetServerVersion property for the project to the version of SQL Server you are using for SSIS as explained by the links below and the screen shot shows.
The version of ODBC source is not compatible with this version of the dataflow
SSIS: version of ODBC source is not compatible with this version of the dataflow
After you do that, you may run into an error that states something like the following:
[ODBC Destination [2]] Error: The AcquireConnection method call to the connection manager MyConnectionManager failed with error code 0xC0014009. There may be error messages posted before this with more information on why the AcquireConnection method call failed.
If you get that error, change the Run64BitRuntime property to 'True' for the project as explained by the link below and the screen shot shows.
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/eb9e6826-b650-433b-bab9-16da214efd99/the-acquireconnection-method-call-to-the-connection-manager-mydatabaseodbc-failed-with-error-code?forum=sqlintegrationservices