>I am sure you are right. And I plan to improve my design by making UI working with disconnected data from DB. Currently, the database/tables are open when UI forms are open. Then of course, if network goes down or user shuts off the computer, probability for corruption is much higher. There is another reason I want to move to SQL Server, more "political" than technical. Selling application with VFP database is much harder than with SQL Server. Some organizations when hearing VFP, don't even want to consider it.

I've not had VFP table corruption problems for years. My policy for sometime has been to provide the first fix at regular rates. There after, it's three times.

>
>>You'll also have transaction difficulties if you need to update the one table in SQL Server and others in VFP.
>>
>

The problem is that VFP transactions aren't supported by SQL Server and vice-versa. You could may kludge something together with COM+, but you'll have to build your own Compensating Resource Manager for the VFP data. I call it a kludge because VFP transactions don't work in a CRM, so you have to provide a different mechanism to simulate them. I'll be talking about this in my DevTeach session later this month.