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 SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Migrating from FoxPro 2.6

Status
Not open for further replies.

MelanieP22

Programmer
Apr 5, 2006
5
0
0
CA
Hi,

Currently our whole operation system is in FoxPro 2.6. We are using the XP mode to make it work on Windows 7 computers but I'm starting to think about migrating to a newer program/version. Do you have any suggestions on which program would be the easiest/fastest to migrate to ?

Thanks for all your help.

Melanie
 
The "easiest" migration would be to VFP 9, but it depends on what your overall objective is.
VFP has also been dumped by Microsoft in 2009, though official support does continue, it's only a matter of time before that ceases too.

After that, it's all philosophical. It won't be cheap to migrate regardless of the path you pick. VFP developers are hard to find, on the plus side if you have Fox developers for your current system, they can start out by using VFP as a "Better FoxPro", while they come up to speed on it's more modern architecture (versus FPW2.6). You could consider one of the "Fox" alternatives like XBase++. It is based on the same "family" of development as VFP. (xBase, dBase, FPD, FPW, Clipper are all in this family, but of them, XBase++ is still being developed by Alaska software, and when I spoke to them a few months back, they are planning a major release next year that is meant to be as close to VFP as you can get without being VFP.

Moving to C# or Java, or VBA, etc, then literally every line will need to be re-written, and you will likely need to switch to SQL server. It's a tough road you face. The more complex your application is, the harder and more expensive it will be to make a move.
-S

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."[hammer]
 
Scott said:
Moving to C# or Java, or VBA, etc, then literally every line will need to be re-written, and you will likely need to switch to SQL server.

Well, Yes and No.

The No part - You will not HAVE to switch to SQL Server if you don't want to.
One of my clients took a Legacy FP/VFP application and migrated its functionality to VB.asp and made that available to their own client base over the web.
When they did that they used ODBC connections to their existing VFP data tables and it works quite well.

The Yes part - Yes, every line of functional code had to be totally recreated in the new language.

Melanie said:
Do you have any suggestions on which program would be the easiest/fastest to migrate to ?

No question here. Migrating to VFP9 would be the easiest and fastest.
Much (not all) of your existing code will run 'as is'. You will need to create new Forms (a.k.a. screens), Menus, and learn to use the Report Form, but the majority of the code itself will migrate.

Good Luck,
JRB-Bldr



 
JRB-Bldr,
I did say "likely" not "have to" migrate to SQL server. I was trying to keep it simple. The "Likely" in fairness meant, if you don't, then you need to use ODBC but that's a can of worms too...


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."[hammer]
 
Looks like I'll be looking into VFP9. Thanks for all your help guys !
 
I agree that VFP 9 is the easiest migration path, though it still could be a lot of work, depending what you want to do.

I just want to add that VFP is already out of support. The last service pack shipped in 2007 and support ended in 2015. Given that community support has always been strong, that shouldn't be a major issue, but thought you should know up front.

Tamar
 
Thanks for your input Tamar... We've been running on FP26 since 1996, so VFP shouldn't be a problem. Unless you have another suggestion ? I don't want to migrate all of our system and find out we can't run it in a few years.

Melanie
 
>I don't want to migrate all of our system and find out we can't run it in a few years.

That may or may not be a point. Nowadays still lot of FPD software runs, but it runs on either old computers or in specialised dos versions or add ons.
As Tamar says VFP is not supported by MS and that means its functionality isn't tested. If a company grows and works on latest Windows (at max one version back), that means your legacy software (also redone in VFP) will become that legacy case again.

It's still most easy to migrate to VFP9 even staying with legacy style of workflow and program flow (see the current thread thread184-1782547, where the discussion about using READ within VFP now starts).

If you want to modernize, VFP9 is an easy option, but also one not really forcing the necessary rethinking on you, you most lilkely end up staying in legacy coding style not compatible with anything else but foxpro.

Bye, Olaf.
 
I'm reasonably confident that VFP 9 will work as long as Windows 10 does, and Microsoft claims it's the last version of Windows, so ...

Tamar
 
Before rewriting to VFP9, try vDos. I am running FoxPro 2.6 programs on a network with Windows 7, 10 (32 & 64 bit).


I am not associated with this business in any way, just a satisfied customer.
 
I agree with jnoblin, vDos is an excellent program. It's a DOS emulator, so it's slower than NTVDM, but this is not noticeable in normal use (taking phone orders, invoicing orders, etc.). I would suggest keeping a 32 bit machine available for re-indexing files, very large reports, and other maintenance jobs.
 
VFP is an order of magnitude better than FP, being Windows 32-bit compatible means it will probably work reasonably well for years to come as Tamar wrote. It doesn't do 64-bit or have the latest bells & whistles for the .NET etc advances though it does have flexibility to gain access to some of it. But the large companies don't want to deal with unsupported 'legacy' applications, they won't invest in any but current and supported languages.

Scott wrote "VFP developers are hard to find." Well, that's a two edged sword. If you look at the job boards, there are few calls for (legacy) Visual FoxPro, GlassDoor seems to have more than the other jobs sites. But I haven't had much response (zilch) from those listings despite some 15 years history at a Fortune 500 company, about 150 on the list. I suspect it's because I'm not a young programmer anymore, but which VFP programmers are? Or not living local when those jobs pop up. Or not having expertise with more than FP/VFP. (I've had side projects in JAVA, JavaScript, VBScript, etc over the years but frankly limited exposure to other/newer languages.)

That makes two companies I've worked with doing conversions (to Visual Basic & Java) and then not needed afterward. I'm counting this year as a 'sabbatical', next year who knows?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top