Migrating From Visual FoxPro?

We have done this for our application backend. We moved to SQL Server Since Microsoft wants you to upgrade to SQL Server/. NET it may be easier to go that route.

FoxPro 8&9 have built-in "Upsizing Wizards" for migrating the data, and I believe that there is a fair amount of information out there on the FoxPro to SQL Server migration: blogs.msdn.com/sqlcat/archive/2008/01/25... msdn.microsoft.com/en-us/vfoxpro/bb19027... foxcentral.net/microsoft/NETforVFPDevelo... My experience is similar to Karl's with regrard to the data clean-up. FoxPro allows data that is bigger than the stated field size. For example: if you have a field that is an N(6,2), foxpro will allow 999999 in the field - where the largest number it should allow is 999.99.

If someone did a typo and entered data bigger than the field size, then when you try to import this into the same size field in SQL Server - it will blow up. Date fields have similar issues If your FoxPro apps are similar to ours, you will have to do a significant amount of redesign where the use of data is concerned. What worked quickly in FoxPro, may not work the same way in an RDBMS.

The use of SCANs and other FoxPro specific logic either does not work at all in other languages, or works much slower. If your indexes are using Rushmore logic they will have to be re-designed as well Honestly, I don't think it makes that much difference what programming language, or RDBMS you go to - the same work will have to be done for any combination. Microsoft has probably made the SQL Server/.

NET change easier - with more documentation available.

We have done this for our application backend. We moved to SQL Server. Since Microsoft wants you to upgrade to SQL Server/.

NET it may be easier to go that route. FoxPro 8&9 have built-in "Upsizing Wizards" for migrating the data, and I believe that there is a fair amount of information out there on the FoxPro to SQL Server migration: blogs.msdn.com/sqlcat/archive/2008/01/25... msdn.microsoft.com/en-us/vfoxpro/bb19027... foxcentral.net/microsoft/NETforVFPDevelo... My experience is similar to Karl's with regrard to the data clean-up. FoxPro allows data that is bigger than the stated field size.

For example: if you have a field that is an N(6,2), foxpro will allow 999999 in the field - where the largest number it should allow is 999.99. If someone did a typo and entered data bigger than the field size, then when you try to import this into the same size field in SQL Server - it will blow up. Date fields have similar issues.

If your FoxPro apps are similar to ours, you will have to do a significant amount of redesign where the use of data is concerned. What worked quickly in FoxPro, may not work the same way in an RDBMS. The use of SCANs and other FoxPro specific logic either does not work at all in other languages, or works much slower.

If your indexes are using Rushmore logic they will have to be re-designed as well. Honestly, I don't think it makes that much difference what programming language, or RDBMS you go to - the same work will have to be done for any combination. Microsoft has probably made the SQL Server/.

NET change easier - with more documentation available.

The FoxPro / SQL Server combo is very workable. A option that I have seen (and been involved in) successfully used this scenario is to migrate the DB to SQL Server and make use of FoxPro views while retaining the original app. Then progressively rebuild the app from data layer up with .

Net tools. If the apps are modular it is possible to take it module by module. Otherwise you have to find some other demarcation.

I understand this works with other RDBMSes but I have no experience of any other combination. I suggest you spend some time before getting into the code side to ensure the data is sound. FoxPro tends to be more forgiving of data oddities (orphan records, etc).

So cleaning this up before encountering issues with it on the target RDBMS is worthwhile. Audit the DBs for orphan records, mormailisation issues, etc and address them in the product you're presumable more familiar with (FoxPro) rather than stumbling across them during the migration proper. Regards.

This was one of the first tasks I did at my current job. They were 4 Foxpro web-applications using west-wind. The Foxpro applications were a mess but that was due more to my predecessor then the language.

I went to a Mysql database and created Java versions from the applications. JDBC connections could be made to the Foxpro database and then to Mysql to do the DB transition. Other then that I don't think there are any type of migration tools out there.

But really any RDBMS would work Mysql, Oracle, MS SQL server, etc... and for the application it self Ruby on Rails, Java, PHP, . NET etc .. take your pick.

Whatever language and database you end up with, evaluate the reporting options that your choice gives you very thoroughly, because in many ways you will find it hard to match what VFP gives you out of the box in this regard.

I worked for a company that developed an application that was completely VFP. I worked on migrating the back-end from VFP Tables to MS SQL Server. That was step one for us.

I built all the update mechanisms into a number of small, custom applications that were called by our installer. After the migration we went through and started moving pieces of the application to modular . NET URL1 make the migration more seamless to the user you can start by building each part of you application as a seperate modular .

NET EXE that you could call from your VFP application. As more and more (back-end) components are moved to . NET you can decide when to make the final switch.

I would switch over all the back-end processing pieces first to harness the power of . NET and then when all of that is done, start re-engineering the front-end. You can also convert all your modular executables into dlls when you are done.

Alternatively you could used the Sedna and start building some migration tools or interop dlls that you could use. If you have any more questions feel free to ask. :D Aniket.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.