>>Hi all,
>>Is there a function that forces VFP to update its cdx files since flush only updates table header and not cdx header?
>>Thanks in advance
>>Yau
>
>I haven't seen specific documentation on this issue, but it seems to me, from experience, that FLUSH does indeed flush both the table and the index (and probably the memo file, too). After using FLUSH conveniently, I had almost no corruption problems, including index corruption.

I think you are right, Hilmar, in all cases but one I found, after several years of trying various methods to avoid data/CDX problems. I had problems like Yh occasionally, so I installed some FLUSHes at various points. At first it didn't seem to work, in testing, where I deliberately fouled up a CDX or table. So I replaced the FLUSHes with file-closes and re-opens to force the updates. The closes had performance hits, though, had me concerned about potential file-open/close colliosions, and seemed a rather draconian solution. I never liked having the closes and reopens in my apps. So I did some more testing, and finally figured out what was going on.

It turned out the FLUSH testing was a "false test," because I was the only user of the DBCs, tables, indexes in the test environment. Under certain NTFS cache settings that we use here (this is true for at least NTFS, not sure about other file environments), even in shared mode FLUSH can *seem* not to perform properly sometimes.

Then I found that FLUSH *was* working after all. What was going on is that with only 1 user having Shared files open, the darned client machine was pulling entire copies of tables (and cdx, memo) over the network, IF it would fit in RAM, for efficiency. So a FLUSH was doing a full job after all, but it was only flushing everything to the locally-cached copy, and a full server update would only be certain with a full close. For this odd situation with only 1 user in shared mode, a complete close was the only thing that seemed to work. Once a 2nd user opened a given shared table, there would be generated an automatic FLUSH, whether by vfp or NTFS, not quite sure, but it does occur. And then FLUSH works fine again for table, dcx, memo, etc., so far as I can tell. As you say, it's not documented in VFP, perhaps because of situations like mine, where NTFS settings seem to dictate what way things will happen, and perhaps not VFP at all.

Anyway that's not a common "real-life" situation, normally there are multiple users sharing tables almost all the time, and FLUSH works fine for everything. Hence, I removed the file-closes/re-opens I had installed as a result of my initial "faulty" testing sceanario, replaced them with FLUSHes, and all has been fine ever since. That was some 3-4 years ago.

Possibly there have been changes (in vfp, NTFS versions, etc.) so that the 1-user cache problem no longer occurs since then. But I've been doing fine with the FLUSHes, so not going to worry about it.

Final thoughts/advice while I'm yakking: 1) Best, always set every possible server file to NTFS Readonly status to avoid problems, with 100% certainty. Sometimes large look-up tables and even DBCs can be dumped into Readonly server folders. 2) Open the tables NOUPDATE for certain groups of users that don't require write-access whenever possible. 3) (and this of course obvious to most Fox people by now): use views, buffering, and cursors for almost everything in your apps, this also greatly reduces "real-data" problems.