Dragan, In VFP file length is updated correctly after FLUSH command. Think about multi-user environment - how do you think other users will see new record added to the end of the file when it is not updated? At least this works on Windows NT.

What you're saying is a behaviour of low-level file functions - when you write something into the file using FWRITE(), file length is not updated immediately, only after file close.

There could be another source of the problem - network. 2 years ago, when working with VFP files through network, I often got SCX/PJX files corrupted when network fail or computer fail. There are options in the network and NT that allow to make buffering in the network minimum, so data lose is minimum. Well, this decrease speed of the network, but increase the reliability.

>>I verified that when Windows falls down (crash system, electric energy turn off, etc.), Visual FoxPro (version 6, Service pack 5) loses indexes and sometimes memo fields files (*.FPT) remain damaged.
>>
>>I would like to known if there’s a way (i.e. using some procedure written in C++ for FLL user-library) to force VFP to flush (FLUSH command save only data to disk not indexes, that remain in cache) indexes and memo files to disk when I want.
>>
>While Flush will write the buffers to disk (all of the dbf, fpt, cdx), it will not force the actual length of files to be written into their directory entries and wherever the OS keeps track of the lengths. It also means that the new blocks allocated to these files may be lost if the files are not regularly closed.
>
>The simple way would be to close and open tables periodically. I've seen this in FPD2.6 - a stuck workstation, which would have to be shut down, would lose data. Opening and closing the same tables from another workstation made sure nothing was lost.
>
>Now with datasessions freely available, you can pretty much grab a list of open tables in any form, create a new datasession, open and close each one in turn, and that's it. If you're willing to test this, you're welcome :).