DTS fails on execute package task

Question

DTS fails on execute package task

juliekenny

SSCommitted

Points: 1558
More actions
November 7, 2005 at 3:50 pm

#67594

Can anyone shed any light on this one please?
We have a DTS package (held as a structured storage file) that in turn runs a second dts package. The outer package is run using dtsrun.
We pass through a global variable - set to nothing, which we then use to clear the version id.
This has worked well in three places, now it won't. We either get the error 'invalid GUID' or 'cancelled by user'. We have tried re-saving to a new file and resetting the default connections (although they are dynamically set).
Any ideas gratefully recieved.

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply

philcart SSC-Forever Points: 47796 More actions · Answer 1

I've come across this before. My feeling is that there is a bug in the save routine that doesn't save the Execute Package task correctly.

You can try,

a) deleting task, saving the package and then re-adding the task

b) re-creating the package from scratch

or

c) after many frustrating hours I replaced the Execute Package task with an Execute Process task that calls DTSRUN

--------------------
Colt 45 - the original point and click interface

juliekenny SSCommitted Points: 1558 More actions · Answer 2

The problem appears to be in the area where we clear the package id. Usually this has the effect of simply calling by name but I don't think it's happening here. I've checked the version of the target server and it's running without SQL 2000 service packs (we expect sp3a at least) so I'm wondering if this is an area that has had a fix.

philcart SSC-Forever Points: 47796 More actions · Answer 3

We run SP4 and I've had the same problem occur in a new package that one of the developers created.

--------------------
Colt 45 - the original point and click interface

juliekenny SSCommitted Points: 1558 More actions · Answer 4

Unfortunately this doesn't help as I wanted it to solve my problems. I will get the upgrade done however as we do consider this a basic there are security improvements .

juliekenny SSCommitted Points: 1558 More actions · Answer 5

Just to let you know that the upgrade solved the problem. Perhaps because it was developed on sp3a.

Thanks for help

fperkins Ten Centuries Points: 1029 More actions · Answer 6

We find this on occassion and normally correct it by resetting the Global Variable. If the package saves with the variable reading <not displayable> or something to that effect, the variable is not blank.

Open the calling package, backspace out the text, and save it again.

Aggravating but as we install on other servers / sites we have to do this 30 - 40% of the time.

juliekenny SSCommitted Points: 1558 More actions · Answer 7

We originally had this problem but as we run the top level packages from dtsrun we pass the global variable as a parameter through as blank and then pass this down as an outer package variable . This normally seems to resolve that particular issue for us.

I did wonder if this might cause the issue and considered trying to set the global variable using VBscript. Luckily I haven't got that far.

fperkins Ten Centuries Points: 1029 More actions · Answer 8

I don't recall the site where we found the details on using the blank to override the version, but it specifically mentioned passing the blank to the variable would not work consistently so we went with the stored variable and adjusted it when necessary.

Limit may have been version related though as we originally did it this way a couple of years ago. Now our packages consist of one ActiveX task and all functionality was moved from bunches of tasks to one script.

Maintenance is a breeze.