Error with automated execution

  • Thread starter Thread starter John
  • Start date Start date
J

John

Hi

I am opening a connection on a shared db as below which works fine when used
in a vb.net win app.

Conn = New OleDb.OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=F:\Events Data\Events Data.mdb;User Id=admin;Password=;")

The problem is that as soon as I turn the app into a service or run it using
windows scheduler I get error on conn.open statement. The error is
'F:\Events Data\Events Data.mdb' is an invalid path, please check that the
path is correct...or something on those lines. If I run it as service on a
standalone PC then that works. So apparently db connection have different
rules for a standard win app and services with a db shared over a lan.

How can I make the code work as a service?

Thanks

Regards
 
Check the permissions of your path, and the user the System/Scheduled task
is set to execute as.

Is f:\ a mapped drive?

--ROBERT
 
Ok. A couple of things:

Are you using impersonation? Chances are it's a permissions error on the
mapped drive. If you're using impersonation, then the drive will be accessed
by the User Account specified by the Anonymous account settings in IIS.
Otherwise it's the account ASP.NET is set to run under (ASPNET is default).

If that checks out, try switching the path to a UNC (\\Server\Share) instead
of a mapped drive, and enable auditing on the share to see if access was
denied, and to whom.

--ROBERT
 
I am not using impersonation. I used the unc path with win service and got
the error; 'The Microsoft Jet database engine cannot open the file
'\\Server\f\Events Data\Events Data.mdb'. It is already opened exclusively
by another user, or you need permission to view its data.'. I then switched
to the windows app version running via windows scheduler and using unc path
and it works fine. I can't understand why the windows app will work with the
same connection opening code while the win service wont.

Regards
 
Did you change the Log On user for the service? There are limitations to the
"Local Account" setting. If you enable auditing, you should be able to see
what user is being rejected access, and it might give you a better idea
where to start looking.

I'm hovering around "Permissions" because the same codebase on the same
machine "should" work fine. The only X factor is user permissions.

--ROBERT
 
Back
Top