>>>>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
>>>
>>>Could it be AV?
>>
>>Seems to me if it were AV, it wouldn't always be the same table. It would happen randomly to different tables in the list.
>>
>>Tamar
>
>Is the file in question one that may get particular large (and thus may take the antivirus longer to complete the scan and release it)?

In fact, this table will never have more than one record.

>Does adding extensions DBF, FPT, CDX, DBC, DCT, and DCX into the exclusion list for the antivirus (so that it doesn't scan those files) help the situation at all?

ISTR that the last time I asked about AV, the answer was none, but I can double-check.


Tamar

>Does anybody know off hand the type of file operations are being performed during ZAP? That is, does it perform the truncation "in place" or does it accomplish it by similar operation as PACK (but doesn't copy data blocks)?
>
>One of the sequence of commands that I'd run into that ran afoul of antivirus was sequence where I was creating a temporary table with a CREATE TABLE followed by a USE to re-open the table with a selected alias. It would appear that the file does get implicitly closed with the USE command (as it is using the same workarea), and that the file never got re-opened. What I figure happened was that between the implicit close and the point where the table was re-opened, the antivirus got in the way and prevented the table from being re-opened. I eventually settled on a kludge where I first explicitly closed the table, then performed a looped retry for opening the table and executing a DOEVENT for each failed attempt, was enough to work around the problem I was having. I am aware that in case where I was using SQL SELECT to generate the cursor, I could've used READWRITE clause -- however I happened to be working on an application authored in VFP6 (which doesn't have the READWRITE clause).