![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
-----Original Message----- I have a package that consists of several Execute package tasks. When I right-click on any of these packages and |
|
How can I avoid this error? Thanks. MT. . |
#3
| |||
| |||
|
|
I have a package that consists of several Execute package tasks. When I right-click on any of these packages and choose Execute step - the package fails and the error messages is "Execution was canceled by the user". If I open the same package and choose Package/Execute the execution succeeds. How can I avoid this error? |
#4
| |||
| |||
|
|
Marie Toftgaard <anonymous (AT) discussions (DOT) microsoft.com> wrote I have a package that consists of several Execute package tasks. When I right-click on any of these packages and choose Execute step - the package |
|
How can I avoid this error? It's a dts bug. You can't avoid it. In fact, the official attitude seems to be that it does not even exist, because no one who counts can replicate it. I have seen the same error with package/execute as well. Now that I'm done blowing off steam about possibly the greatest single irritant that I have with DTS, let me see if I can give some advice. There is some history in this ng archives on this issue. One thing I'm certain of is that if you execute the outer package with dtsrun you will not get the error. I have never seen the package fail like this with dtsrun, only within dts designer. I found that the error seemed to be related to having multiple data pumps in an inner package. You could try restructuring your packages so that the inner ones only have a single data pump in them. I did this and it helped for a while, and then, incredibly, the error came back. The problem seems to be in the inner package, because when the error returned in the first outer package, it returned in all subsequent runnings of any outer packages that call the same inner package. Anyway, this solution is extremely onerous. There is an even more onerous MS solution that involves saving the package as a VB file and then putting code in there to trap the error. Obviously, this is maintenance nightmare because you either have to give up using designer for maintenance, or you have to add this code back in every time you make a change with designer. Ugh. Oh, and MS believes that the problem is solved and I believe they define the problem more narrowly than its real world occurrence. There's a KB article on it but I don't remember the number. I think it's in the archive. The approach I am working on right now involves using a combination of activex and commandline tasks to dtsrun the inner packages, but this approach has its own problems, one of which is that you have to replace every exec package task with two others, not to mention making something much harder than it should be. Good luck. This is an intolerable limitation on the usefulness of dts, that you can't reliably package reusable components for use as needed, and it's the kinda thing that allows ETL competitors to dismiss dts as a mere toy. I guess I wasn't done blowing off steam after all. JP |
#5
| |||
| |||
|
|
If anyone can send me a repro of this "bug" then I can get it logged, but I have never been able to repro it, so I have nothing to log. I don't doubt there is a problem due to the volume of posts, but I haven't seen it myself. |
![]() |
| Thread Tools | |
| Display Modes | |
| |