Post reply

Old DTS issue

  • September 10, 2003 at 12:18 pm

    #107001

    Folks,

    This issue must have come up a hundred times and admittedly is becoming kind of annoying.

    A DTS package that runs by executing it, won't run by scheduling it.

    Both processes run under the same system_admin_account (admin rights on both local server as well as the SQL server).

    Yes, this is a stand alone server and the admin is logged only locally.

    But I don't see why, if all I am doing is using a DSN that has its full credentials on the

    remote DB2 server, should fail for permissions reason.

    Shouldn't the job run under the local account (which is an admin) and let the package use

    DSN credentials to access the remote DB2 server?

    What's up with the job failure? Any ideas?

    Thanks

    A.

  • September 10, 2003 at 5:10 pm

    #473573

    When you say it 'runs by executing it', are you actually physically on the box, or running via EM on your workstation? If the latter, then the package is executing under your credentials, NOT the SQL Server credentials.

    Other than that, I would point the finger at the SQL service running as a local account. Have had many a problem with SQL logged in using a local account that has no privelages outside the box.

    There is probably some underlying network traffic that is tripping up the package execution. What is the actual error that is returned?

    Hope this helps

    Phill Carter

    --------------------

    Colt 45 - the original point and click interface

    --------------------
    Colt 45 - the original point and click interface

  • September 11, 2003 at 10:09 am

    #473754

    Hi, just wanted to elaborate that, in this case, the same user is the owner/admin of all those processes. I was finally forced to use DTSRUN from the command-line and make a bath file and schedule that using the "at" command (and that works, still the same user!). So, I really think this is a problem with the product.

    here is the message that the package logs:

    "Step Error Source: Microsoft OLE DB Provider for ODBC Drivers

    Step Error Description:[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified

    Step Error code: 80004005

    Step Error Help File:

    Step Error Help Context ID:0"

  • September 11, 2003 at 6:09 pm

    #473832

    Is the DSN defined as a User DSN or a System DSN?

    Have you tried using a UDL file instead of a ODBC DSN?

    Hope this helps

    Phill Carter

    --------------------

    Colt 45 - the original point and click interface

    --------------------
    Colt 45 - the original point and click interface

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply