dbTalk Databases Forums  

DTS: "Execution was canceled by the user"

microsoft.public.sqlserver.dts microsoft.public.sqlserver.dts


Discuss DTS: "Execution was canceled by the user" in the microsoft.public.sqlserver.dts forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Marie Toftgaard
 
Posts: n/a

Default DTS: "Execution was canceled by the user" - 10-14-2003 , 09:16 AM






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?

Thanks.
MT.

Reply With Quote
  #2  
Old   
Sandra
 
Posts: n/a

Default DTS: "Execution was canceled by the user" - 10-14-2003 , 01:08 PM






I have the same problem and I've posted a note but didn't
get any reply. If you figure this one out can you please
share? Thanks in advance. Sandra

Quote:
-----Original Message-----
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.
Quote:
How can I avoid this error?

Thanks.
MT.
.


Reply With Quote
  #3  
Old   
JP
 
Posts: n/a

Default Re: DTS: "Execution was canceled by the user" - 10-14-2003 , 01:39 PM



Marie Toftgaard <anonymous (AT) discussions (DOT) microsoft.com> wrote

Quote:
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?
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


Reply With Quote
  #4  
Old   
Darren Green
 
Posts: n/a

Default Re: DTS: "Execution was canceled by the user" - 10-16-2003 , 10:55 AM



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.

--
Darren Green
http://www.sqldts.com

"JP" <SocSecTrainWreck (AT) earthlink (DOT) net> wrote

Quote:
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
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.
Quote:
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



Reply With Quote
  #5  
Old   
JP
 
Posts: n/a

Default Re: DTS: "Execution was canceled by the user" - 10-17-2003 , 09:42 AM



"Darren Green" <darren.green (AT) reply-to-newsgroup-only (DOT) uk.com> wrote

Quote:
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.
This is proof in and of itself of the inadequacy of MS DTS. A product
team that can ignore such strong evidence of the problem is not
exactly an endorsement for their product. As you know, I put a lot of
work into trying to reproduce this problem for you in a simple,
generic package but you were not able to get it to show up in your
environment. I am not prepared to undertake that kind of work again
when I know that the issue will be dropped if the same thing happens
the next time. In fact, if I actually thought that I would get an
adequate response from MS on it, I would get my company to authorize
the resources to log it myself. But it would be a waste of money. The
response would be: "we can't reproduce it and until you do it *for us*
we are unable to address it."

JP


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.