Page 1 of 2 12 LastLast
Results 1 to 15 of 16
  1. #1
    Join Date
    May 2005
    Location
    Nevada, USA
    Posts
    2,888
    Provided Answers: 6

    Unanswered: DTS import works directly, fails when scheduled

    I'm new to DTS packages, but managed to create one that successfully empties a table in SQL Server then imports data from a Foxpro file on another server into it. It runs fine if I execute it from DTS, but fails if I schedule it to run in SQL Server Agent (using the "Schedule Package" option in DTS). I think the relevant portion of the error returned when the job fails is:

    Error string: [Microsoft][ODBC Visual FoxPro Driver]File 'hrpersnl.dbf' does not exist.

    The file does exist. I also tried to execute it from a stored procedure, but got a similar error. Any thoughts on why it runs one way but not the other?

    TIA
    Paul

  2. #2
    Join Date
    Nov 2005
    Location
    San Francisco, CA
    Posts
    506
    Quote Originally Posted by pbaldy
    I'm new to DTS packages, but managed to create one that successfully empties a table in SQL Server then imports data from a Foxpro file on another server into it.

    TIA
    Where do u kept the dbf file? Are u sure the connections are ok? I feel when the scheduling task is taking place your other server is some what down.That may be a cause.Plz check that ...
    Success is the ability to go from one failure to another with no loss of enthusiasm.
    - Sir Winston Churchill
    Joydeep

  3. #3
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    When you run a DTS package directly (from the console), the job runs under whatever login/authorization that you use to connect to the SQL Server. This is typically your Windows login.

    When you schedule a DTS package to run as a SQL Agent Job, you can choose what credentials the job will use by default (i.e. the job owner), and also for each job step (on the step's "Advanced" tab, near the Ok button). The default is almost never your own Windows Login.

    The difference in the credentials used often leads to problems with permissions.

    -PatP

  4. #4
    Join Date
    May 2005
    Location
    Nevada, USA
    Posts
    2,888
    Provided Answers: 6
    rudra: I had already checked that. The server/file are there.

    Pat: I was not thinking a permissions problem, because the job does start. It completes the first step of emptying the table, then errors trying to find the dbf file. Since that's found through ODBC, my assumption is that it wouldn't matter how the DTS package is run.

    In Enterprise Manager, I can execute the package in the DTS section and it will run fine. If I execute the job from SQL Server Agent, it fails with that error about the dbf file.
    Paul

  5. #5
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Just to humor me, could you change the job owner to be whatever your credentials are when you run the job manually, just to see what happens?

    -PatP

  6. #6
    Join Date
    May 2005
    Location
    Nevada, USA
    Posts
    2,888
    Provided Answers: 6
    I apologize Pat, I wasn't trying to imply you were wrong. You know a lot more about this than I do. I'm probably not understanding exactly where you're talking about. Maybe it's a Friday afternoon brain cramp. Here's a picture of where I'm looking:
    Attached Thumbnails Attached Thumbnails DTS.JPG  
    Paul

  7. #7
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Sorry, you're looking in the DTS designer. I meant to find the job, which is what actually is scheduled and change the job's owner to be you (in other words, the job and the DTS package that it uses will then run as though you had started it manually).

    -PatP

  8. #8
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    Changing the job owner will not change the outcome.

    Are you using UNC to point to the file location or through a mapped drive?
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  9. #9
    Join Date
    May 2005
    Location
    Nevada, USA
    Posts
    2,888
    Provided Answers: 6
    I've gotta say, I'm feeling pretty dense right now. On the General tab of the Job's properties in SQL Server Agent (still in Enterprise Manager), the owner was listed as:

    DomainName\Administrator

    which is how I'm logged into the server. I tried sa, and it still doesn't work. I appreciate your persistence, and by now you must be thinking "how stupid is this guy?".

    rdjabarov: I'm using a mapped drive, which is the only way I've ever been able to get the FoxPro ODBC to work.
    Paul

  10. #10
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Very good call rdjabarov! I hadn't considered the use of a mapped drive, since I can't remember the last time I used one for a scheduled task.

    The problem comes from the fact that the SQL Server Agent actually starts as a service before the Windows Explorer does. The mapped drive exists as a side effect of the Windows Explorer, so the mapped drive letter is usable by any process running as a result of user action (such as launching a DTS package), but the mapped drive is not available to a process started by SQL Agent.

    In order to access the DBF file, it must exist in a place that the SQL Agent process can find it. The obvious choice would be to find a way for the DTS process to connect the ODBC driver via a UNC to the DBF file. The next would be to copy the DBF file to the machine running the DTS package so it can use a local drive (say via a command process).

    It is usually easy to make the ODBC connection to the DBF file, but there can be complications. You'll need to make sure that the job step that accesses the DBF file on the remote machine runs as a Windows Login that has access to the UNC.

    -PatP

  11. #11
    Join Date
    May 2005
    Location
    Nevada, USA
    Posts
    2,888
    Provided Answers: 6
    I think you've nailed it. I created a quick test, and it worked. I'll try it on the real package on Monday.

    Thank you both very much!

    Paul

  12. #12
    Join Date
    May 2005
    Location
    Nevada, USA
    Posts
    2,888
    Provided Answers: 6
    I did a little testing yesterday and then let the scheduled job run overnight last night. It ran fine, and I can run the package from a stored procedure now, which I couldn't do before.

    Thank you both very much for your time and expertise.
    Paul

  13. #13
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Quote Originally Posted by pbaldy
    I think you've nailed it. I created a quick test, and it worked. I'll try it on the real package on Monday.
    Ok, just being dreadfully curious at this point since you're already happy, but what exactly did you try, and how did that work in production?

    -PatP

  14. #14
    Join Date
    May 2005
    Location
    Nevada, USA
    Posts
    2,888
    Provided Answers: 6
    Not sure what you're after in addition to post 12. I was able to create an ODBC connection with a UNC path. I did some testing with a test package on a test database Friday, and it worked. I modified the connection in the production package to use the new DSN. I let the scheduled job run last night, and it was successful. I was also able to execute the package from a stored procedure, which had failed before (same error).
    Paul

  15. #15
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    That's exactly what I was looking for...

    I had presumed that you were using a UNC from the beginning, so I never thought to question that. I thought the problem you were having was due to the job starting as either a SQL login or a Windows login that didn't have permission to read from that UNC.

    What I wanted (and you gave in post 14) was an explanation of what actually worked for you.

    Thanks!

    -PatP

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •