My question today is when I schedule a dts package, that does nothing
more than copy 3 files from one server to the another, it only takes 1
second to run in a scheduled job and shows it was successful even though
it didnt truly run the package? I have created variables with both ip
addresses of the servers and what drive to reference C$ and D$
accordingly. This package runs fine when it's run manually. I know that
sometimes it could be a permission issue. But I have another scheduled
job that uses excel and creates files on my client pc fine. So that
took out the permissions issue so now I am confused.

Any Ideas?



*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

A Quick test for the permissions issue would be to log on as the SQL Server
Agent service account and try to manually run the package.


--
--

Allan Mitchell (Microsoft SQL Server MVP)
MCSE,MCDBA
www.SQLDTS.com
I support PASS - the definitive, global community
for SQL Server professionals - http://www.sqlpass.org

<Matt Cannen> wrote

ok when I switch to use the system startup account back to system
account the first scheduled package with run correctly. But my second
scheduled package will not. Even if I tell it to use sa I get Error
Description: ActiveX component can't create object: 'Excel.Application'
Error on Line 5. Where as when I told it to use another account it
would run fine. What am I missing in the permissions?



*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Is Excel installed on the box where you run the packages (remember DTS is
client side)?
If not then this would stop it working. I have also seen this when Excel
was installed by a user and then used by others. Almost as though it
installed something to the user's profile.

--
--

Allan Mitchell (Microsoft SQL Server MVP)
MCSE,MCDBA
www.SQLDTS.com
I support PASS - the definitive, global community
for SQL Server professionals - http://www.sqlpass.org

<Matt Cannen> wrote

Yes but thats not my problem as when I change the login from Sa to my
user it runs fine. It seems more like some kind of permission issue
that I dont have set correctly but I am lost on what else needs to be
updated and the microsoft article was only slightly useful.


*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

If you are logged in as "sa" then the package should execute under the SQL
Server Service account.

--
--

Allan Mitchell (Microsoft SQL Server MVP)
MCSE,MCDBA
www.SQLDTS.com
I support PASS - the definitive, global community
for SQL Server professionals - http://www.sqlpass.org

<Matt Cannen> wrote

Does sa also need to be an actual windows user as well? When I try to
set SQLSERVICEAgent to use sa with the password it says it cannot be
verified.


*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

The service account needs to be a domain user with the nexessary permissions
to access/use any resources in the DTS package.

--
--

Allan Mitchell (Microsoft SQL Server MVP)
MCSE,MCDBA
www.SQLDTS.com
I support PASS - the definitive, global community
for SQL Server professionals - http://www.sqlpass.org

<Matt Cannen> wrote

ok just to clarify and I apologize ahead of time.

Do you mean the NT Authority\Service Account or the
SQL SA = Sys Admin account



*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

A service account has no knowledge of and couldn't really care about SQL
Server authentication. It is only interested in domain accounts.

--
--

Allan Mitchell (Microsoft SQL Server MVP)
MCSE,MCDBA
www.SQLDTS.com
I support PASS - the definitive, global community
for SQL Server professionals - http://www.sqlpass.org

<Matt Cannen> wrote