If you are getting into the code where the table is opened exclusively you already have an exclusive lock it can't be a sharing problem.

So that rules out issues related to locking/contention.

If this is intermittent then this is some sort of OS file system or permissions issue.

I would suspect Anti-Virus as others have. This is the most common problem for intermittent file operation failures on writes especially.

Another thing to think about: Where do the files live? Are they in AppData or a User folder? If not and Windows UAC is on Windows will move those file under you to a private user store. So if the files live in the programs folder and permissions have not been set explicitly for that user the files are virtualized and can be moved under you - possible that only manifests intermittently as a file is moved while writing to it. Easiest way to check for this is to run the app as Run As Administrator or explicitly give full permissions to the user running the app...

+++ Rick ---

>I have a client where at least one person (one of the testers, so intense user of the app) is intermittently getting error 111 "Cannot update the cursor "cursor", since it is read-only." He says he sees it at least once every other day.
>
>The error log tells me that it's always the same table and always on the ZAP in this sequence:
>
>

>USE Network EXCL
>ZAP
>USE Network
>

>
>This is in a routine that does the same thing to about 10 different tables and this is not the first one listed. (And no, I didn't write this code originally and wouldn't have done it this way, but changing the architecture at this point would be significant.)
>
>This is a DBF permanently stored on disk, not a cursor, and not a table created temporarily.
>
>One question is whether this could be related to OpLocks, but if so, would I see it always on the same table?
>
>I have ideas for work-arounds, but I'd prefer to figure out what's actually going on.
>
>Any suggestions?
>
>Tamar