main ideas similar to Dmitry and Naoto. Have seen Pack fail after hefty runtime, correlated with size of dbf, when earlier memory of the vfp process was taxed/fragmented.
Any weird error handling in place or many errors just logged/ignored earlier ? Vfp process memory tracked/checked ?


>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