Migration (Best Way)

[Guest_imported]

Hi!

I have a fox pro 2.6 application(DOS) and I would like to convert it into VFP 6.0 application (Migration).

Do you know which is the best way to migrate? or
Do you know any tips that you can tell me about the best way to migrate?

Also I have another one In FoxPro (Windows) that I need to migrate to VFP 6.0, is this more easy than the other one?

Do you know about a Software that help me with migration?

Do you thing is better to do again all the software in VFP 6.0, just checking the other application?

This is the first time that I will do this migration I hope that you can tell me something that can help me, I will appreciate it

Thanks

MR

 

[foxdev]

Do you thing is better to do again all the software in VFP 6.0, just checking the other application?

Count me as one vote in favor of this approach. You can keep the pure, non-UI procedural code where it makes sense, but I would design a fresh, object-oriented system. Robert Bradley
Support operation moo!
Visit the OpCow page

http://www.agrainofhope.org/opcow.shtml

to help in this cause

 

[GrigoreDolghin]

Hello.

I completely agree with Robert.

Don't migrate your app. If you'll do this, you'll get a ugly interface and a FPD app runned under windows (it will have a poorer performance than pure DOS).

Rewrite completely the app. You can try a OO aproach and use all the power of VFP (buffering, updatable views, etc.)

Hope this helps. Grigore Dolghin
Class Software
Bucharest, Romania

 

[weedz]

Guys, you've got my vote.

HTH,
Weedz (Wietze Veld)
My private project:

http://www.crowncap.demon.nl\info\crwnbase

And especially for VFP rookies:

http://fox.wikis.com/wc.dll?Wiki~VFPRookieMistakes~VFP

 

[BongoB1]

It is so easy to say re-write it in VFP because of all of the benefits, but if there is little money to pay to reinvent a system that currently works, it seems to me that it makes sense to take the existing .spr, .mpr, .prg, etc. files and recompile them using VFP.

I support several applications that were written in 2.6 and have been recompiled with VFP6.0 with improvements in both functionality and stability without reprogramming everything. I admit that it would be more fun if they were in native VFP code but the bottom line is that these customers are not willing to pay for fixing something that isn't really broken.

Check your 2.6 code for long variable names which 2.6 agnores but VFP will treat as written. Also, reports may need to be adjusted to keep detail bands from overflowing. VFP is also touchy about dates. Look at the strictdate setting.

Good luck

 

[Guest_imported]

Thanks to all of you for your comments....

I wil try to check the code and I will see which option is better...

MR

 

[rgbean]

MR,
You may also want to check my comments in thread182-53462.

Rick