Scheduled DTS Package not running

I have a DTS package setup that runs just fine when I fire
it off as a DTS package, but when I schedule it to run it
fails.
I'm running SQL2K, sp3. SQLAgent is running.
Has anyone seen this before ?
TIA...
Michael.What is the package trying to do when it fails? This can happen because of
privileges (or lack thereof) of the SQL Agent service account that differ
from the privileges used when running the package from Enterprise Manager.
Bob
Microsoft Consulting Services
--
This posting is provided AS IS with no warranties, and confers no rights.|||as indicated before it depends on a number of things . .
1) if DTS references a file that SQLAgent Account cannot Access/does not hav
e access to
2) if non-sysadmin created SQLAgentJob and SQLProxy a/c exist then job will
be executed in SQLProxy a/c context
3) if DTS is executed using exec xp_cmdshell 'DTSRun' or xp_cmdshell exists
inside DTS and SQLAgent job creator account does not have rights to execute
xp_cmdshell and no sqlproxy account then could get the problem.
hope this helps|||The first part is an ActiveX script that gets file names
off a dir. and inserts them into a table.
The acct mesSQL01 is the account that SQL logs in under as
well as SQLAgent. It is also the owner of the DTS Package,
and has full control on the dir that it is looking on.
heres the fail message that is returned by sendmail:
STATUS: Failed
MESSAGES: The job failed. Unable to determine if
the owner (WILL\mesql01) of job GetFileName has server
access (reason: Could not obtain information about Windows
NT group/user 'WILL\mesql01'. [SQLSTATE 42000] (Error
8198))
I'm gonna start tearing it apart to see if there are other
parts of it that it CAN run. I am quite at a loss here.
Thanks for your help !!
m.

>--Original Message--
>What is the package trying to do when it fails? This can
happen because of
>privileges (or lack thereof) of the SQL Agent service
account that differ
>from the privileges used when running the package from
Enterprise Manager.
>--
>Bob
>Microsoft Consulting Services
>--
>This posting is provided AS IS with no warranties, and
confers no rights.
>
>.
>|||Ok, I think I've nailed down what is causing it to fail,
but I can't seem to find a solution.
Here's the ActiveX script...
Function Main()
Dim FSys
Dim Folder
Dim Files
Dim Comm
Dim Conn
Set FSys = CreateObject
("Scripting.FileSystemObject")
Set Folder = FSys.GetFolder
("\\fsq\Files\DM\Lab\TechReports")
Set Files = Folder.files
Set Conn = CreateObject("ADODB.Connection")
Set Comm = CreateObject("ADODB.Command")
With Conn
.Provider = "sqloledb"'
.open "Data Source = fsq\Mes_SQL01;
Initial Catalog =Lab Tech Library; User id=MesSQL01;
password=xxxxx"
end with
Set Comm.ActiveConnection = Conn
It all works with the WITH statement stuff rem'ed out, so
it's the stuff in the WITH statement that is causing the
fail, even though the MesSQL01 acct is a Domain account,
and has Admin priv on the SQL server. It even fails when I
log on as MesSQL01 and run the package local.
Why would this fail, even though it has the permissions ?
This is the domain acct that the server and SQLAgent logs
in under ?
help ?
TIA

>--Original Message--
>What is the package trying to do when it fails? This can
happen because of
>privileges (or lack thereof) of the SQL Agent service
account that differ
>from the privileges used when running the package from
Enterprise Manager.
>--
>Bob
>Microsoft Consulting Services
>--
>This posting is provided AS IS with no warranties, and
confers no rights.
>
>.
>|||Need to connect with trusted connection(not )
your account is a trusted connection therefore no requirement to have userid
and password
Dim IsTrusted ' IsTrusted is 0 by default
Dim oServer
Dim strServer
' Create DMO server object
Set oServer = CreateObject("SQLDMO.SQLServer")
' Use secure login and then login (trusted connection)
IsTrusted = 0
oServer.LoginSecure = True
' connect to the server requested
oServer.Connect (strServer)