>>>Each customer is different. :-)
>>
>>Good point. I usually just say (to myself), "please help me to help you" :)
>
>Yes indeed. We've actually gone so far as to take machines to their site, raw install the Windows Server software on the server, setup the workstations and deploy it right there in front of them, and disable caching on each machine and let their employees come and test it out and try to get data corruption with the cache disabled.
>
>Some still won't do it. We only have a few like that. The rest acknowledge it's a need.
>
>We've considered switching to SQL Server, but we have a large code base and it would be difficult.
>
>I was hired here to write a converter that translated VFP source code to T-SQL. I completed that project and got it working in 30 days, but they've never used it. We later refactored that code to take FPW 2.6 code and migrate it to VFP 9 so they can continue developing legacy systems in 2.6, and then have them reliably translated to VFP 9 without having many of the errors the internal VFP-conversion encounters.
>
>It's a large code base (35K+ lines of C/C++). It's a shame they haven't used it to migrate to SQL Server. Nearly every other system we have is on SQL Server, just not these several legacy VFP9 apps.

I agree that it is a challenge to convert the application your size to SQL Server. I don't even know how big is my application, in terms of number of lines, or whatever. But I am very grateful that VFP9 has Cursor Adapter technology, This made my conversion to SQL Server very doable.