Yeah, and that's why DBF files can be easily corrupted: You have many clients trying to update the same files remotely over a network. Any network microcut, any client virus or any client that collapse or reset is a potential contributor to write bad info, resulting in the well known file corruption, being some of the worst those that passes unseen (corrupted data that does not corrupt the file structure) but that soon or later you will find.
This problem is more noticed starting from Windows greater than 2003/XP, for wich the SMB protocol have changed, privileging fast througputs and optimizations for HTTP protocols at the expense of the now deprecated ISAM files access.
2018-01-25 20:04 GMT+01:00 Stephen Russell srussell705@gmail.com:
I see a potential problem when multiple users are doing updates on the same table. What constitutes the server file to be updated? How do the localized cdx files know to update when the server version is updated?
On Thu, Jan 25, 2018 at 12:51 PM, Gene Wirchenko genew@telus.net wrote:
At 08:15 2018-01-25, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
On 2018-01-24 18:39, Fernando D. Bozzo wrote:
When the index is evaluated initially, VFP knows exactly what fields affect what index, so really just affected indexes are updated. It's easy to test it. just make an old index (IDX) on two different fields: CREATE TABLE test (field1 C(10), field2 I) INDEX on field1 TO test_f1 additive INDEX on field2 TO test_f2 additive Add some data, wait a minute, replace one of the fields and do a FLUSH FORCE, and you will see that only the affected index changes his timestamp.
I don't think that's a fair test to use IDX files since this example uses
a CDX file, and it's all in the same file.
I think it *is* a fair test for exactly that reason. If you seeonly
one of the IDX index files change, that suggests that VFP only updates an index where it would make a difference.
I grant that it could be that that optimisation does not exist inthe
CDX handling, but how likely do you think that is?
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]