Ed,

You are right. Thanks for refreshing what the original problem was.

>>David,
>>
>>What platform, version of VFP and service pack are you using? As far as I remember some problems were found when working with VFP over Win2k on a PC with SCSI drives.
>>
>
>This is completely wrong; the problem was that when editing a Form under Win2K and saving it, the .SCT (the variable length data potion of the SCX/SCT pair) was not written through to disk when deferred writes were enabled unless a normal shutdown of Win2K was performed. The problem could be avoided by disabling write caching; the problem with this approach was that the Win2K IDE driver would reset the status of write caching on each reset of the system, so the problem would resurface after each reset of Windows on IDE drives; the SCSI drivers I tested respected the setting of the write cache disable, so they did not require you to go in and reset the status after each reboot.
>
>A couple of workarounds were posted - manually disabling the write through via Device Manager on each reboot, zipping and subsequently unzipping the form after changes were made forced the writethrough to occur, as did using VSS and writing changes into the project under VSS, creating a fresh SCA that could rebuild the SCT were given as methods to avoid this problem.
>
>There's a recent post on a fix to the problem being released by MS; I don't remember the exact date of the post (I'm not affected, since I use SCSI drives on my development box and rely on VSS, which saves the changes differently IAC) but it'sithin the last couple of weeks.
>
>The error caused the loss of the form in totality, not the resetting of the DE; the SCT holds the custom property settings and any method code changes. The reset of the DE is not a manifestation of the improper writethrough of the file.
>
>>>... Sometime, when I am doing something in VFP, I close my form and the next time I open it... all my data environment is erased..? Did it happen to anybody else.. and why does it do that?