>>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
>
>
>When it crashes, can you look and see if any other users have that file in use?
>Some app might be using it and not letting go.

The table is local. This is an unusual application and users don't share any tables.

But that makes me think I should:

a) ask him whether he sees it again if he tries right away;
b) if so, ask whether reboot cleans it up.

Tamar