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