Hi All,

I have a strange situation with a dts package that I have. I have developed it without any problems and through the use of performing a "Save As" and choosing a "Structured Storage File" have distributed it to our customers without any problems. Now we have a change made to the package, that I changed locally on my computer and which I have deployed once again in a similar manner, but for some reason, when the customer tries to "Open Package..." and load from the newly saved .dts file, they get the following errors:

"Error Source: Microsoft Data Transformation Serves (DTS) Package
Error Description: Unspecified error"

Followed by another dialog, stating:

"The selected package cannot be opened. The DTS Designer has been closed."

I've been able to reproduce the problem on our local domain with another employee but I have no explanation for it. In all cases, regardless of what actual server this new package now resides on, I can, regardless of how I connect to that server, open the package without any problems, but this other person can not. When she attempts to connect to a remote server through EM (using Windows Authentication) she cannot open the file even though EM says that her domain login is the owner. When she remote desktops to that server, and logs in using her domain name, opens EM, she can then successfully open that same package without any problems, where previously she couldn't.

Can anyone explain why this might be happening?

I have tried re-saving it many times, using different domain/local user accounts. I even tried changing the owner of it before I attempted to save it to a file. Nothing I have attempted to change about the package itself has affected whether or not this other user was able to open it.

Can anyone please tell me why?

Coemergence_John

Hello,

To narrow down the issue, you may want to create a new DTS package to test
the situation. Also, does the issue only occurs on some specific servers?

If the issue occurs with all packages on a single server, it seems the
server with this issue may have problem with DTS compoents.

You may want to unregister run the following in command prompt one by one:

Regsvr32 /u dtspkg.dll
Regsvr32 /u Comcat.dll
Regsvr32 /u dtsffile.dll
Regsvr32 /u dtspump.dll
Regsvr32 /u dtsui.dll

and then try to Register the back:

Regsvr32 dtspkg.dll
Regsvr32 Comcat.dll
Regsvr32 dtsffile.dll
Regsvr32 dtspump.dll
Regsvr32 dtsui.dll

If the issue persists, please try to reinstall SQL 2000 client tools to see
if helps.

Best Regards,

Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

================================================== ===


This posting is provided "AS IS" with no warranties, and confers no rights.


--------------------
As" and choosing a "Structured Storage File" have distributed it to our
customers without any problems. Now we have a change made to the package,
that I changed locally on my computer and which I have deployed once again
in a similar manner, but for some reason, when the customer tries to "Open
Package..." and load from the newly saved .dts file, they get the following
errors:
what actual server this new package now resides on, I can, regardless of
how I connect to that server, open the package without any problems, but
this other person can not. When she attempts to connect to a remote
server through EM (using Windows Authentication) she cannot open the file
even though EM says that her domain login is the owner. When she remote
desktops to that server, and logs in using her domain name, opens EM, she
can then successfully open that same package without any problems, where
previously she couldn't.
it to a file. Nothing I have attempted to change about the package itself
has affected whether or not this other user was able to open it.

Hi Peter,

Thanks for your reply. We have previously tried re-registering "some" dll's
(I don't recall if it were ALL of the ones you mentioned or not) to no
avail. It had no effect. What we didn't try was unregistering them first,
so we will definitely attempt that. We also haven't tried reinstalling the
client tools. We'll attemp that and I'll get back to the newsgroup with the
results.

Coemergence_John

"Peter Yang [MSFT]" <petery (AT) online (DOT) microsoft.com> wrote

I am receiving the same error, but only with a very few select packages. I
have tried resaving the package under a different name, but that doesn't
clear it up.

All of these packages have not experienced a problem until a change was made
forcing a new save.


"Coemergence_John" <Coemergence_John (AT) newsgroups (DOT) nospam> wrote

Hi Peter, et all,

I have tried all of your suggestions, all to no avail, although we have
narrowed "the issue" down to it being something specific about my domain
account, on my machine AND the issue seems related to the FTP item that we
have in our DTS script.

If a DTS script has the FTP item in it, others can't open the DTS script.
If it is removed (from the DTS script that was previously un-open-able) it
works fine and can be opened with no problems by anyone, otherwise I am the
only one able to open it, but only from my machine.

I can log into another computer and don't get the problem. I can Remote
Desktop into another computer and don't see the problem. So the resolution
we have worked out for our customer is that I have created the necessary DTS
script while Remote Desktopped into another computer, I have imported a DTS
script without the FTP item, recreated the FTP item and saved it to the SQL
Server. We will then save this new script out to a .dts file and send to
our customer, all via a different machine and a different domain user than
myself. Part of the issue is that our customer does not have Remote Desktop
access to their SQL Server, but he does have access to it via Enterprise
Manager (ya ya I know, its just about the same thing, but..."the customer is
always right"...right?) which is how he is going to be installing this new
DTS script.

Is there anything, anyone can think of that may be causing my domain
account, on my machine to be doing something different than everyone else's
domain account connecting to the same server? Could it be something to do
with me running XP Professional with a local copy of SQL Server Developer
edition whereas all of the other SQL Servers (that we are noticing the
problems on) are Enterprise versions?

Any insight would be greatly appreciated.

Coemergence_John

Same problem, did you ever come up with a solution?

"Coemergence_John" wrote: