I have been tracking down a very random occurrence of a table opened with
the Exclusive flag throwing an error.
#111 Cannot update the cursor "cursor", since it is read-only.
I checked the code, no NOUPDATE flag.
I brought up SysInternals Process Monitor and opened, appended a record,
and closed a table 10000 times.
I had suspected multiple anti-virus and on demand backup tools causing
behavior problems.
This Windows 7 (virtual machine) has 1 GB RAM, Kaspersky, Bitdefender, and
Carbonite installed.
No exclusions, and Carbonite is set to specifically backup the data folder
on demand.
My test actually does a Try/Catch around the USE statement, wrapped in a DO
WHILE NOT USED()
It seems the tools mentioned are not the direct culprit. Instead when things
fail, Windows Explorer was the direct cause. Windows Explorer opens the
table Read Only and with Share Read/Write and reads the first 4000 bytes.
Then closes the file. Why I don't know, I don't care. I do know it only
happens when the Explorer window is open to the folder where the table
exist.
Lucky for me, the place I open tables is via a class, so a check with
ISREADONLY() will prevent this in the future.
So what really happens? In Process Monitor I can clearly see I open a table
in one session of VFP 9, then in another session of VFP 9 I attempt to open
it again. First VFP attempts to open the table Read/Write with Share None.
It gets a Sharing Violation. Then VFP attempts to open the table Read Only
with Share None. There is that split moment on some machines that VFP is
successful.
Has anyone else seen this behavior before?
Thank you for reading,
Tracy