>>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?
>
>- Antivirus
>- Background process running e.g. backup, defrag etc.
>- Network connectivity issues, check event logs
>- Existence of Network.* or excessive number of temp files in temp files folder
>- Problem with CDX or FPT file(s) if present
>- Problem with DBF file "found" by SET TABLEVALIDATE
>- Problem with database files if table is part of a DB
>- "Network" appears to be a reserved word in VFP

Lots of good ideas, but several would seem to lead to this happening on random different tables, not just this one (and it always is this one). OTOH, most of the time, he doesn't have the problem, so the tables exists. Free table, so not a database issue. No CDX or FPT for this one.

Not sure how it being a reserved word would play in, but interesting thought. Hard to see why this would be intermittent, though, if that were a problem.

Tamar