>>
>I'm just curious on why you would think that there wouldn’t be cost savings. We have a huge manufacturing app written in FoxPro. We are currently working to integrate it with SQL. I find it hard to believe that switching to a different language all together and integrating with SQL would cost the same or less.
>>
>
>Most of the time, Fox Code is predicated on having local access to data. For example, anything that does a locate for, seek ,etc, that necessarily implies that 100% of the data that could contain what you are looking for - has to be on the client. As a result, Fox code *normally* has to be retro-fitted to properly handle data in a remote environment.
>
>Of course, there are those black-box funtions that accept parameters and spit out a result set. Again, if any of these require a local access to data in order to operate, then again, they have to be retro-titted.
>
>It is important to note that from an engineering standpoint and a business standpoint, it would not have made sense for applications - that were orginally pegged to go against local data - to have been developed with the mindset of going after remote data. More likely than not, it would not have been cost-justifiable.
>
>Indeed, there are RV's - but experience has taught us that it was an illusion to think that they could be used in place of Fox data. For example, lets say you have a customer table with 150K rows. A simple use customer looks like a pretty innocent statement. Now, make that a RV - and issue the same code. You will be waiting a long time. Now, think about how an existing scnenario works when searching for a customer. Do you think some re-work would be required? Probably a lot.
>
>My experience is that very little - if anything - from an existing application - when saved - has a material impact on the cost of a project. When we did the First Premier Job, I had the envious task of having Fox 2.x code in one window, and the SQL Server enterprise manager in another window. I was tasked with the job of converting Fox 2.x procedural non-sql code - and converting it to T-sql in stored procs. In the end, it was not a lot of work once some decernable patterns started to emerge. But again, given the local-ness of the data model the application was predicated upon, it was a big job - and nothign from the original app could be saved.
>
>The bottom line...companies that want to migrate to SQL Server in the correct - most efficient way - need to resign themselves that a re-write is the only way to do it. Trying to retro-fit amounts to a make-work project - ripe with lots of hassles, lots of work-arounds - that in the end - cost a lot of $ that you would not otherwise have to spend.


I think you are missing the cost of going to a different language. You first have to train all your developers or hire new ones. The new ones might know the language but wouldn't know the application. Plus if they didn't know VFP they would have a hard time knowing exactly what the application did. Plus if you start from scratch with .NET your application is going to have new bugs that the old system didn't have.

The other issue is that not all our clients would benefit from SQL and wouldn't want it. I know there is MSDE but we have many 20+ user systems that works just fine with VFP and they wouldn't want to upgrade to SQL with the cost of SQL. Plus I would guess it wouldn't work well with MSDE like it does with VFP, since MSDE is optimized for 5 queries at one time. So we were looking at doing SPT and maybe some Cursor Adaptor stuff with ADO that would work with both SQL and VFP data.