Your easiest migration path would be from FPW2.6 to Visual Foxpro 9 where a good portion of your original code would be compatible 'as is'. You would end up with a powerful 21st century GUI-centric application which would have the ability to 'grow' in a wide variety of ways and could, if desired, support alternative data 'backends' like SQL Server, MySQL, etc.
The only limitation you might encounter would be if you wanted the application to run as an actual Web application. There are some spin-off alternatives, but VFP, in its 'native' mode, does not do that.
Having said that - To change any application from Language-A to Language-B where the two languages had almost nothing in common is a LARGE task.
You (or our contractor) need to be intimately familiar with both languages so that you can read and fully understand what is going on and how it is being done in the original application.
Then you would need to 'translate' everything of importance from a functional perspective into the new language's approach and syntax - sort of like translating a Presidential Speech in English into a totally different language like Chinese where there is no direct word-to-word translation which can retain the original meaning.
If you REALLY want to make the language change I'd recommend first creating a VERY DETAILED Functional Specification of the original application where every business rule and algorithm were clearly defined in layman's terms. It would also need to include a fully defined Data Dictionary of all of the static data elements and where they 'lived'. Think of it as creating the documentation that should have been created prior to developing the original application.
Then from that document you could get a developer to create a New Application in the same manner as they would if doing so from scratch - but with good documentation.
there are no "tools" available that could convert/re-generate the FPW 2.6 code in to another language
Correct
Regardless, unless there are some MAJOR compelling reasons (not defined above) not to do so, you should probably consider migrating to VFP9 since a large portion of the 'reasons' that individuals want to consider migration would be fully addressed in VFP9 and the conversion would be greatly easier.
Totally new applications would be good candidates for a totally different language such as the .NET languages, but the conversion of an existing application - Not often.
I'd disagree about moving code from fpw to VB to the extent that you can pick up a lot of code and just move it with minor modifications.
I do this mostly in VFP9 settings but would work in fpw to a lesser extent. Also the VB report form is very similar to the VFP 9 form.
The big difference is how data is handled. VB assumes the data will be a snap shot and the connection closed. That can take some getting used to.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.