I am running into the exact same problem, I have only found a handful of
forum posts talking about this, but I've only found the same questions, no
answers.
I can edit all of our DTS packages without problems on our Server
2003(SP1)/Sql Server 2000 (SP4) machines unless I try to edit the DTS with
the FTP task. When attempting to design the DTS with the FTP task I get an
unspecified error. To add to the frustration the DTS will not run through a
job, when I run the job I get a similar error:
Error: -2147467259 (80004005); Provider Error: 0 (0) Error string:
Unspecified error Error source: Microsoft Data Transformation
Services (DTS) Package Help file: sqldts80.hlp Help context: 713.
Process Exit Code 1. The step failed.
Because of this obscure bug I have only been able to run the DTS by hand
through my workstation and have been unable to automate this. My workstation
is Server 2003, but happens to have sql server 2005 installed. Have you
found another solution to this issue besides installing sql server 2005?
That seems like such a hacky approach.. there has to be another way?
[quoted text, click to view] "Patricia" wrote:
> Problem editing SQL Server 2000 DTS Package containing a File Transfer
> Protocol task. User can edit SQL Server 2000 DTS package logged in
> locally to server but cannot edit same package from her PC via SQL
> Server 2000 Client Tools. A co-worker and myself are able to edit the
> dts package from our PC's logged on as administrator but we cannot edit
> the package logged onto the user's PC using our administrator login.
> To prove that it was the FTP task causing the problem, I removed the
> FTP task from the DTS package leaving the remaining tasks intact. User
> can edit the package that does not contain the FTP task.
>
> I started looking for differences in PC configuration and realized
> anyone with SQL Server 2005 Client Utilities installed in addition to
> SQL Server 2000 Client utililities can edit a DTS package containing a
> File Transfer Protocol task in SQL Server 2000. I have searched
> endlessly in an attempt to identify a logical explanation for the
> problem encountered. I realize the two clients probably share dll
> files but I really do not want to recommend loading software to her
> machine that she will not use just to correct the problem.
>
