views:

59

answers:

1

I have built an SSIS job in visual studio 2005 that accesses a flat file and updates a table in SQL Server 2005. This works perfectly. I then store a copy on SQL Server by using the server storage option in the protection level property. When I try to run this it cannot locate the flat file. The flat file is located on a server and I use the IP address to access it. I have noticed that if I remove my maping to this server and run the job from visual studio, it cannot find it either. Hoe do I access the file from SQL Server 2005 ? I intend to schedule this job to run automatically on SQL Server. Many Thanks for any help you can give. Ronnie Carlin

+1  A: 

Just to avoid anything more complex being the issue, check what account the job is being run under (e.g. has a procy and credential) or whether it is using the base SQL Agent account, and then check whether that account has access rights to the folder \ file you are trying to import. Had that catch us out more than once.

Edited to include the additional information in the main answer.

When SQL Agent runs a job it does not use your account, even if you initiated the job execution - it uses the SQL Agent account. The account the SQl Agent is set up under (by default) or a named account you specidy with a proxy / credential. You might be able to access the folder, but you need to check what account SQL Agent is running under and whether it can access it.

To find out which account the job is running under by default you can access it via Start -> Program files ->SQL Server -> Configuration Tools -> SQL Server Configuration Manager. In the 2005 Services SQL Server Agent will be listed, right click properties, first tab shows what account the Agent is being run under.

However, if you need a job running under a specific account I would advise you create a proxy / credential and not alter the agent account - since that is the account all the other jobs are using.

Credential and proxy are different objects within SQL, Credentials are stored under the security folder / credentials - that is where you create a credential and place your AD username / pwd. The proxy then asks you to select a credential from the list of credentials already stored on the system - not your domain\user at that point.

Andrew
Thanks for your help Andrew.I am not sure what you mean by account. When I connect to SQL Server I use Windows authentication and my windows account can access this folder.ThanksRonnie
Ronnie Carlin
Andrew, How do I determine whataccount it is running under ? I have checked the properties for SQL Server Agent but can't see anything there.
Ronnie Carlin
Andrew thanks a lot for your help with thisI have been a developer for many years but I am relatively new to SQL Server so I am struggling a bit.I have decide that the way forward is to create a proxy account for this job. basically all I want is for the job to run with the same rights as my windows account so it can access the required folder. When I create the proxy account, it asks me for a credential name and I enter my domain\login but it doesn't like that telling me that it does not exist. Any suggestions.
Ronnie Carlin
Hi AndrewI created an entry under credentials with my logon and password.I then created a proxy under SSIS package execution and it allowed me to select the credentials that I had just created.I wasn't sure how to tell the job to use this proxy but I noticed that the job step (it's a 1 step job) , in the general properties had something called 'run as' which allowed the selection of SQL Agent service account or my new proxy. I selected my proxy but when I run it it fails with the helpful message "the job failed" ???
Ronnie Carlin
You've got the right place to specify your proxy, you can specify it per step. You now need to inspect the SQL log or add a log provider to your package so it tells you why it is failing. You have at least now got it executing under your AD account, which it was not doing before.
Andrew
It doesn't actually execute, the message I get is "MessageExecuted as user: ZONE1-SCBNET\1335723. The process could not be created for step 1 of job 0x3D96C1441DD1F4419CE1749907E59471 (reason: 1314). The step failed."
Ronnie Carlin
1314 equates to A required privledge is not held by the client. Number of reasons this can be occuring, permissions based, does the package have encrypted credentials, is the step running an xp_proc of some kind.The problem is too narrow / specific at that point without having the package / database / job etc to inspect to see what's going on or advise on a fix easily.
Andrew
Andrew,Thanks for your help.I have other fish to fry so I am putting this to the side for the moment. You have taught me some more about SQL Server even if I haven't managed to crack this problem today. Thanks for that.Regards,Ronnie
Ronnie Carlin
No problem, you can contact me here / on my blog.
Andrew