>>>>Thank you for this confirmation. It looks like for some people it's much easier to blame VFP than realizing that they need to focus on finding the reason for their problems.
>>>
>>>Microsoft is not supporting VFP anymore. I feel stuck with it. At least i can change the database.
>>
>>It's your app and your decision. I hope you make the right decision, and wish you good luck. It would be very nice to read a report about your experience with changing the database engine, and whether that solved your problems or not.
>>
>>However, you miss my main point completely, namely that you have a problem somewhere in your design, and you should fix it. As many others here have written, corruption is usually caused by badly written software. You live in the hope that adding another database can remove your problem, and you may be right. But your problem will not be fixed because you add the other application, but because you must change your code to work with this other database. These changes would be more or less the same changes as you would make to work with dbfs anyway. My take is that after switching to SQL syntax, your problems would go away also with dbfs.
>>
>>Good luck, and I mean it. :-)
>
>I'm curious as to why you believe that using SQL syntax against a VFP database will reduce the risk of data corruption. In VFP all proccessing is carried out on the local machine so whether using SQL syntax or not all relevant data has to be pulled/pushed over the network. That's vastly different to (and inherently more risky than) the behaviour of a true server based data engine such as MSQL

I base my comment on discussions I have had with some of the people who has created VFP, like Calvin Hsia. I am not saying that they told me directly that SQL syntax was "safer", but it was these discussions that convinced me to skip xbase commands completely, except when I worked with cursors.