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
Not seen that behaviour, but I tend not to have other Windows apps running when I'm in a VFP data editing session. That probably doesn't help.
Laurie
On 8 March 2016 at 15:14, Tracy Pearson tracy@powerchurch.com wrote:
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
[excessive quoting removed by server]
As Christof said some years ago: all is not what it seems with Foxpro file handling - there is a *lot* of smoke and mirrors!
On 08/03/2016 20:44, Tracy Pearson wrote:
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
[excessive quoting removed by server]
Foxpro doesn't open files, Windows does. And there can be a big stack of filter drivers in play from AV and other things.
-
Alan Bourke -
AndyHC -
Laurie Alvey -
Tracy Pearson