>
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.