>>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.
I don't know what CRM is so I guess, as they say, what you don't know can't hurt you <g>.
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham
