views:

161

answers:

3

Ok we have a WCF service running on one machine on IIS6 + server2003 r2 this service needs to write and read to/from a fox pro database that is located on another machine on the network - windows 2003 (probably r2).

After playing with permissions (both on the fox pro file and impersonation in WCF) we have finally managed to read from it but when tring to write an exception occurs. (We know that all the DAL code works perfectly fine).

Cannot update the cursor DEVENT, since it is read-only. (We are not using a cursor, that is some kind of internal implementation of the driver) Microsoft OLE DB Provider for Visual FoxPro

DEVENT is a table name.

When the database is on the same box as the WCF service everything runs fine - however we are probably using an administrator account as this is our debug setup.

Please help me figure this out ... its been plaguing me for weeks.

Obviously the problem is using fox pro ... but we don't have that choice. :D

Thanks.

Edit:

Ok we have checked that all files in the directory are not read only We have also set the permissions on the folder and files for different users, computers and built in accounts. None of which have made a difference. could the problem be an IIS issue? We could not read when using IIS5 because the ASPNET user could not access remote files. We have since moved to II6 (which uses NETWORK SERVICE), got read access but not write. so we then tried setting admin permissions on any user account vaguely related to the process (even though thats a security nono) and had no luck. So we are fairly sure that it is not a user account problem on the machine with fox pro on it. Any other ideas?

+3  A: 

Not exactly sure why you are blaming FoxPro since you note:

"When the database is on the same box as the WCF service everything runs fine - however we are probably using an administrator account as this is our debug setup."

Definitely sounds like a permissions problem for your access to the other machine. I access Visual FoxPro data on other machines all the time.

Besides the permissions, another thing to check is that the files on the other machine really are not flagged read-only. Check settings on all DBC/DCX/DCT, and DBF/CDX/FPT files.

Rick Schummer VFP MVP

Rick Schummer
have edited question in response
John Nicholas
this was the right ballpark. It turned out to be a share permission at machine level. We put auditing onto the files and they wern't being touched prior to the cannot write exception.
John Nicholas
Permissions issues are some of the trickiest to solve. I am glad you were able to persevere and solve.
Rick Schummer
+1  A: 

I would have to agree with Rick if you can read from the db but not write then it is a permission issue. Does the account that you are using to access the db from the other server have write access? Also is the account that you are connecting to the other server have the same permissions in both cases?

Alos
A: 

I have had some issues with the VFP OLEDB Provider when using UNC paths. If this is what you are using as well, perhaps you could try with mapped network drives instead.

Eyvind