March 20, 2020 at 6:08 pm
First an explanation just to see if I am going about this the right way
I have a package that i've created using VS 2017
If run it from VS2107 i.e. locally, it works fine
I've created a SQL Agent job
Now, if I deploy it via SSMS i.e. through deploy project in Integration Services Catalog and run using the job, it works fine
If I deploy it from VS2017 and run through the job, if fails (I know it depoys as I can delete the catalog first and it reappears)
The failure is not an initial failure asit reads in and acts upon environments
It just gets to a specific task and returns Cannot create a task from XML for task. "The parameter is incorrect"
So, my thinking here is, can I see what the package looks like after deployment, just to check whether anything gets deployed differently
Has anybody seen this and does that make sense as an approach?
Thanks
- Damian
March 20, 2020 at 7:52 pm
Sounds to me like a version issue. Is your VS2017 project set to use the same SQL Server version as your SSIS server?
Failing that, you can export the ispac file, unzip it (using your favorite zip tool) and you have access to the XML in the dtsx from there.
If memory serves, VS2017 will also create an ispac file that gets pushed to the SSIS catalog on your local machine.
You can get failures too if you use a different version of SSMS when importing the dtsx file. It will import successfully but fail to run.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
March 21, 2020 at 7:24 pm
Have you checked the All Executions report to look for clues as to the error?
Are you sure that this is an execution error and not an initial validation error?
Does the package always fail at the exact same place.
If you disable the task which fails, does the package complete successfully? (Assuming that this does not completely ruin the logic in the remainder of the package, of course.)
Is the value of the parameter which causes the error set from an SSIS environment, or is it just using its default value (as set at design time).
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
March 23, 2020 at 8:15 am
Thanks Brian and Phil
I'm just going to try a couple of your suggestions and gather some information
- Damian
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply