Read the OP carefully:
1. The OP does not need to find which user account is running the Windows
service. He has said that it work when using "Local System" account, but not
when using "Local Servic" account.
2. He does not use SQL Server, hence not point to "switch to sql
authentication"
To the OP:
Since you use Jet database (Access database), the user account that runs the
application and accesses data in it must have read/write permission to the
folder where the *.mdb file is in. Local System account has mighty power to
access to almost everywhere of the computer, hence it works. Local Service
account, on the other hand, has very limited access to computer resources by
default, you need to explicitly assign permissions to this account to use
resources on the computer. That is, when you place a program to a computer
running as services, you should start with a most restricted user account
and only assign access permissions as needed. In your case, it is good
choice to use Local Service account, but you need to explicitly allow this
account to read/write to the floder where *.mdb sits. Of course you can
choose other user account to run the windows service as long as the account
has sufficient access permissions.
"sloan" <sloan@xxxxxx> wrote in message
news:OHJLn8x8IHA.3848@xxxxxx
>
> I'm guessing your db isn't configured to allow permissions from the (being
> used) user.
>
> 2 suggestions:
> Switch to sql authentication.
>
> Figure out ( and give permissions ) to the correct user for your db.
>
>
> Here is some crappy code to figure out (so you can log it) the user.
> You're thinking "I know who the user is", but sometimes its good to do it
> while in the code.
>
>
>
>
>
> Go to Control Panel / Users and you can see a list of "built in" users
> that
> a windows machine has.
>
>
>
> private string FindIIdentity()
>
> {
>
> try
>
> {
>
>
>
> string returnValue = string.Empty;
>
> WindowsIdentity ident = WindowsIdentity.GetCurrent();
>
> returnValue = ident.Name;
>
> try
>
> {
>
> returnValue += " on " + System.Environment.MachineName;
>
> }
>
> catch (Exception ex)
>
> {
>
> }
>
> return returnValue;
>
> }
>
>
>
> catch (Exception ex)
>
> {
>
> return "Error Finding Identity";
>
> }
>
> }
>
>
>
>
>
>
> "Matt Lowrance" <matthewlowrance@xxxxxx> wrote in message
> news:87310f74-67d0-42ad-8bbe-709b0edbbff6@xxxxxx
>> I'm hoping someone can give me a little guidance. I have written a
>> simple Windows Service that goes out and scrapes a few web pages and
>> updates some data in an access database. The service works correctly
>> in the IDE and trying to be a good citizen I set it to run as "Local
>> Service" when I install it.
>>
>> However once installed it fails silently. My log eventlog message
>> saying the the DB was updated successfully is written, however the
>> actual write to the database doesn't happen. There does not seem to
>> be an error or exception that I can catch, it just doesn't write.
>>
>> Once I change the service to run as "Local System" it works
>> correctly. So my question is should I really avoid using "Local
>> System". I have read the articles explaing he dangers, yet I see lots
>> of services running as it on my system. Maybe its more like a
>> guidance "Do so if you can, but if not don't worry too much about it?"
>> Is there another option? Is there a better way to know where the
>> problem with the "Local Service" account exists? Like I said when I
>> debug it in the IDE it works correctly, but at that point it is
>> running as my user account (which apparently has all the rights it
>> needs).
>>
>> Should I just create another user account and play with the permission
>> until I find the right ones. This service goes out to client
>> locations so I hate to make them do too much manual work in creating
>> an account (as some clients I doubt would even know how to do it),
>> etc?
>>
>> Thanks,
>>
>> Matt
>>
>> >
>