I have some custom control flow and data flow tasks that are not showing up in the SSIS Toolbox. When I open a package in SSDT containing the custom tasks I get several errors loading the package.
Error loading MyModuleTemplate1.dtsx: Cannot create a task from XML for task "__ECT Fetch Configuration", type "MyEncryptedConfiguration, MyCustomTasks, Version=1.0.0.0, Culture=neutral, PublicKeyToken=2bdffe791d57af79" due to error 0x80070057 "The parameter is incorrect.".
I've followed Russ' and Matt's replies from the following post http://social.msdn.microsoft.com/Forums/sqlserver/en-US/5fdf9243-7e38-401e-bf4a-9251738877f9/how-to-browse-the-installed-custom-task-in-sql-server-2012-ssis-ie-custom-ssis-control-flow-task, however, the tasks still don't show.
I'm using SQL Server 2012 x64 with SSDT on Windows Server 2008 R2 x64. I have verified that the tasks are in the GAC and that the assemblies are in the appropriate SQL Server\110\DTS directories. The assemblies have been compiled as 32-bit since I kept getting a warning about targeting Any CPU while referencing 32-bit assemblies (the SQL reference assemblies).
I'm able execute the packages with the custom tasks, on the target server successfully through command line. Additionally, these tasks work fine on my development machine. I can see the tasks in the SSIS Toolbox and can open packages with the tasks without issue. My dev machine is nearly identical to the target machine except that I have full installation of Visual Studio 2010.
Am I missing something?
This problem is the result of WiX installer not properly installing the custom tasks. Below is what I did to verify this.
For test purposes I created an empty custom task and manually deployed it to the target server by copying the files and the DTS\Tasks directory. This worked so I added the .cs file of one of the tasks that was throwing errors, to the test custom task and re-deployed. I was able to see both tasks. After cleaning the solution with the original custom tasks, I manually deployed the original custom task to the target server, like the test custom tasks and was able see the tasks in the SSIS toolbox. I then uninstalled the custom tasks and deployed them to the target server using a WiX installer -- the problem resurfaced. So the problem is with the installer. My previous attempts at manually installing the custom tasks failed because I was using the assemblies installed from the WiX installer, although I don't know why.
Related
We have an SSIS project in Visual Studio (2019 Community) that we deploy to our SQL server (2016) using project deployment. We have a couple of hundred packages and we most often deploy single packages at a time.
We had been doing most of our development in a single Azure Git master branch since these changes were separate from most of our other development. A few changes were done in a different development branch and then that single package was deployed from there. It should not have caused a problem because that single package was new and not being used in the master at all. However, when that single package was deployed it removed a couple of new packages from our live server that had been deployed from the master branch but had not been in the development branch when it was initially created.
I thought that a single package deployment only deployed that single package you selected or the few packages you selected if you chose a few of them. It seems like in addition to deploying that package it deleted packages that were on the live server but not in the dev branch that we deployed from.
We deploy from Visual Studio by right-clicking our package or packages and then choosing Deploy Package from the context menu. That process creates an .ispac file when we are deploying to our development SQL Server. That .ispac file is copied to the live server and then run directly on the live SQL server.
This should not be deploying all packages, correct? Just those highlighted? Does it remove missing packages if I only deploy a single package at a time but the packages in my project in VS and the project in the SSIS catalog do not match?
It depends!
For 2012 and 2014, the only option for deployment to the SSISDB was "Project" deployment. The entirety of the .ispac file is applied to the SSISDB - whether package1 had changed or not.
With 2016+, you have the ability to do Project or Incremental Package deployment. In the "Review" tab of the deployment wizard, in the Summary section you can see the command line indicates /ModelType:Package That is the indication it is deploying package(s) versus the whole project. See figure 5 of
https://www.sqlservercentral.com/articles/incremental-package-deployment-%E2%80%93-a-ssis-2016-feature
If you're deploying from the .ispac, then there should be a selector in the Select Source tab (not shown in referenced article) that allows you to do full or incremental deployment but the ModelType in the Review tab will identify which approach was selected. I suspect someone did a full/project deploy.
But, the nice thing about the SSISDB is that you can use SSMS to roll the project back to the previous state so no harm, no foul, no lost packages.
I'm having issues running a .dtsx package made in Visual Studio 2019.
In Visual Studio when using "Start without debugging" it runs perfectly with no errors, however when I try to launch the file from command line it's giving me a non-descript error and terminates the package.
It runs for some time and does execute a few of the tasks at the start of the package, however it does not get very far.
This is the "error" showing in the command prompt:
Message: <DTS:ProcessMemoryUsage xmlns:DTS="www.microsoft.com/SqlServer/Dts">DTS:PeakWorkingSetSize177860608</DTS:PeakWorkingSetSize></DTS:ProcessMemoryUsage>
When I look at the error dump, this is what I see:
This is my execution command
"C:\Program Files\Microsoft SQL Server\130\DTS\Binn\DTExec.exe" /f "C:\**PATH**\Visual Studio 2019\Projects\DataDropPrep\DataDropPrep\MSX DataDrop.dtsx" /conf "C:\**PATH**\Visual Studio 2019\Projects\DataDropPrep\Test.dtsConfig" /DECRYPT "****" /CONSOLELOG /DumpOnError /REPORTING EW
I don't understand why it works perfectly when run within Visual Studio 2019 but not in the commandline.
The package is set with target server 2016 (To match our SQL server).
I'm running the package from a local VM on my own PC, but the SQL server is deployed in Azure (cloudapp.azure.com).
I am NOT a DB admin, so I can't add the package to be run from the SQL Server itself unfortunately, wish that I could, would make my life a lot easier.
Alas I am stuck manually running this package every day from my own PC, and I'm trying to automate it with a .bat file, so I need this command working.
This is the package layout, it first truncates a staging table, then loads all items modified or created in the past 3 days, then deletes matching rows in the production table, then imports the new rows from staging. Repeat for all the different objects:
When using "Start without debugging" from Visual Studio 2019, it executes without issues:
Turns out the issue was that I was using a project parameter, which works when running from Visual Studio, but not when executing the dtsx file directly.
After converting the parameters from project to package, it executes successfully!
Without the logging and the insights that provided I wouldn't have known where to start.
Success
In the same folder as the package, SSIS generated a file SQLDUMPER_ERRORLOG.log. This pointed to a file in C:\Program Files\Microsoft SQL Server\150\Shared\ErrorDumps. This folder contains text files such as SQLDmpr0085.mdmp. When I click on this, it launches Visual Studio and gives an error message "The thread tried to read from or write to a virtual address for which it does not have the appropriate access."
After hours of experimenting and doing web searches, I discovered that I was not passing the correct package name to dtexec.exe. Once I corrected this, I was able to execute packages with no issues.
I am upgrading SSIS packages created and running in 2008R2 to 2016 version.
Facing various issue where ever there is a script task inside a package.
Can anyone help me with any generic way to upgrade script tasks like upgrading assemblies or libraries in it ?
or
Do I have to pitch into each script and make changes individually inside ?
Tried upgrading the assemblies in one of the script task, the cross sign dissappeared however, there were still some errors in the script related to few classes.
I have a SQL Server Agent Job executing a file-system-deployed SSIS package via CmdExec & the 32 bit DTExec. However, the most recent version of the package version is not executing.
The change I've made is within a Script Task. I've made sure to Build within the VSTA editor before closing, etc.
I've verified this is the problem by putting the expected version in the command line parameters, so the task fails: /VERIFYVERSIONID "\"{1F870663-1898-4A30-B4A8-226817D1755F}\""
Is there a cache that can be cleared?
One approach would be to change the executiontype for the SQL job to be Operating System (CMDEXE) and provide the path to the dtexec file for SSIS to use as the executable.
C:\Program Files\Microsoft SQL Server\110\DTS\Binn\dtexec.exe /FILE "c:\path\to\my\ssis\package\myssispackage.dtsx" /CHECKPOINTING OFF /REPORTING E
By calling the dtsx specifically you can point to the 32 or 64 bit version. You can also revert to a previous version of SSIS (dtexec) if you have those installed on your executing server.
I recently upgraded some of my packages to SSIS 2012 and had to use the new version for the packages to be executed by dtexec. That resolved my issue. Hope that helps.
Nothing to see here, move along..
I'm doing new child package testing on a server hosting multiple environments shared by my dev team, and we're in the process of shuffling things around. The job in question is one of a few identical ones and the path to the package got changed.
This is a 'master' package that dynamically executes child packages based on values read from a queue which is why it didn't occur to me to check the path.
Noob oversight.
I've got a number of SSIS packages spread across multiple projects in SQL Server Data Tools (formerly BIDS), which I want to deploy to the SSIS Catalog DB on my server.
When I want to deploy an entire project, I can just right-click the project and hit Deploy, to start the SSIS deployment wizard. However, there doesn't seem to be an option to do this for a single package only, without redeploying the rest of the packages in the same project.
Does anyone know if it's possible to deploy just a single package using the deployment wizard, independently from the others in the project?
This does not appear to be possible via the deployment wizard or SSDT. Similar discussion in this thread...where the original poster proposes a (terribly manual) workaround.
You might also want to get BIDSHelper from Codeplex (free tool). It contains a utility to allow you to deploy SSIS packages from BIDS. I haven't tested BIDS Helper with SSDT yet. Also you might want to grab SSIS Package Manager from Codeplex as well.
You can use SQL Server Management Studio to import a single package:
In SSMS, connect to your Integration Services instance.
Right-click the appropriate node (File System or MSDB) and select Import Package.
Set Package Location to File System.
Click the three dots next to Package Path. Browse to your SSDT project and select the .dtsx file you want to import.
Click OK. If prompted to overwrite the existing package, click Yes.