I'm using SQL Server 2000 SP4 and am trying to execute a DTS package using
the DTSRUN utility using the "AT" scheduling command in Windows Server 2003.
Unfortunately, the job fails and the reason is because the package is being
executed by user SYSTEM. I can tell this by the log file. I've read
Microsoft article 269074, but this does not quite apply because I actually
*can* get the package to run both interactively and as a scheduled job
*within* SQL. The problem appears to be with scheduling this in the O.S.
This used to work under Windows Server 2000. Any ideas?

In message <09D29E60-1FDD-42FE-83CC-0C98C8E10B0A (AT) microsoft (DOT) com>, Bill
<Bill (AT) discussions (DOT) microsoft.com> writes
You may be able to run the package interactively, and under the SQL
Agent service account, but are either of these SYSTEM? If not then you
have not tested it yet, as the account is very important. Why not use
the Windows Scheduler service ( is this base don AT, I thought it was),
but the key point is the GUI allows you to specify an account to use.

To be honest why use AT when SQL Agent does a better job anyway.

--
Darren Green (SQL Server MVP)
DTS - http://www.sqldts.com

PASS - the definitive, global community for SQL Server professionals
http://www.sqlpass.org

I have an ActiveX script within a DTS package that executes every 30 minutes
checking for any text files that need to be imported. These text files,
however, are imported using any one of a number of DTS packages. So, in my
script I find the package that needs to be executed for the particular text
file and build the DTSRUN command line along with the AT command to schedule
it. WshShell is used to run that command line. This way, the DTS package
with the ActiveX script does not have to wait until the import is finished
before finishing and running again in another 30 minutes. The SYSTEM account
definitely won't work. I want the package to run under the same domain
account as the SQL agent but scheduling with the AT command appears not to
allow the package to run under the SQL agent.

"Darren Green" wrote:

For those browsing these messages, I ended up solving this one by setting the
sql agent proxy account. You can use xp_sqlagent_proxy_account or set it
within EM.

"Darren Green" wrote:

Rather that using AT to get the asynch behaviour you want, two other
choices would be-

Use the "start" command, as by default this is asynch.

Create a job, start that job. Jobs can be set to clean up after
themselves. This also means you can set a job step file to capture
output, and the job does not delete itself when it fails so the job and
log is then available for investigation when you have a fail.

Darren

In message <E7E8FCF8-EF01-4C2F-8CF9-796FC0299B3E (AT) microsoft (DOT) com>, Bill
<Bill (AT) discussions (DOT) microsoft.com> writes
--
Darren Green (SQL Server MVP)
DTS - http://www.sqldts.com

PASS - the definitive, global community for SQL Server professionals
http://www.sqlpass.org

Didn't know about the START command in the O.S. Thanks! I do think it would
be more elegant to use the sql job scheduler than the AT command. I hadn't
really considered using it for "one time" type jobs, but upon review it looks
like a number of flags can be set for auto-deletion, etc. which is what I was
hoping for. For those reviewing this post, you may want to check this
article: <http://www.sqlteam.com/itemprint.asp?ItemID=19595 >

"Darren Green" wrote: