Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Code Migration Options

Status
Not open for further replies.

tatonka

IS-IT--Management
Aug 20, 2002
27
GB
Hello All,

Can anyone definitely advise whether there is a "code" migration path from FPW 2.6 to non-VFP language e.g. VB, C# etc.

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

Good Luck,
JRB-Bldr
 
Thanks jrbbldr for the prompt response.

I take it from your reply that there are no "tools" available that could convert/re-generate the FPW 2.6 code in to another language, other than VFP.

Sorry to labour the point.
 
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.

Good Luck,
JRB-Bldr
 
Thanks jrbbldr - just what I need, much appreciated.
 
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.

Example

FPW
grabline = "Select fname,lname "
grabline = grabline + "from customers"

VB
grabline = "Select fname,lname "
grabline = grabline & "from customers"

By the way I use mostly SQL tables in VFP.

Do case
case 1
case 2
case "Y"
otherwise
endcase

select case num
case 1
case 2
case 3
case else
end select
 
If you want to make the VB case statement handle more like VFP, then just test for True:

Code:
select case True
case num = 1
case num = 2
case num = 3
case chr = "ABC"
case else
end select
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top