I wish to migrate a multi-user application executable from FoxPro 2.6 for Windows to a suitable Visual FoxPro platform.<br><br>I briefly tried migrating the app to VFP 3, using the simplest of the migration options, but even then additional work proved necessary which, at the time, I couldn't justify spending the time on.<br><br>I already have VFP 3.0 Professional, but would like to know if there are good reasons to skip this stage and go straight to a later version.<br><br>Particular areas of concern are:<br>- Is the migration path any easier if a later version is used?<br>- Are there any nasty bugs which a later version resolves?<br>- Is VFP 3 particularly slow? Are later versions any quicker?<br>- Are there any pitfalls with the migration process which I should be aware of? <p>Andy Blay<br><a href=mailto:a.d.blay@talk21.com>a.d.blay@talk21.com</a><br><a href= > </a><br>
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 John Tel on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Migration from FPW 2.6 1
- Thread starter AbleA
- Start date
-
1
- #2
Andy, there is only one migration path that you will ultimately be happy with: a rewrite.<br><br>There are really no major advantages of running a 2.6 program in VFP, and as you've discovered there are lots of gotchas. FPW screens simply don't translate well to VFP forms, and they definitely don't fit the OOP model. I know this isn't what you want to hear, but I've tried a half-dozen FP-to-VFP "transport" conversions, and what you end up with is so convoluted that you'll become disgusted with VFP. Its not VFP's fault, its just that you can't dress an alligator in a tutu and expect it to dance.<br><br>But if you absolutely must try it, then yes, a later version would be suggested. Numerous bug fixes occured in VFP 5, so go with at least that. <p>Robert Bradley<br><a href=mailto: > </a><br><a href= - Visual FoxPro Development</a><br>
- Thread starter
- #4
Many thanks to you both for your advice.<br><br>I hate to admit it, but I suspect that I'll stick with 2.6 a bit longer (after all, better the devil you know...)!<br><br>The only trouble is, 2.6 seems to have a habit of throwing wobblies at certain points in the PC upgrade path (for example, the two processor speed-related issues documented in the Microsoft Knowledge Base), so I wonder what the next glitch will be and how severe? Pity that VFP3 (at least) seems to share similar issues.<br><br>Of course, one benefit of a rewrite is that I'll get the chance to play with OOP! Question is, is this something to look forward to or might I bitterly regret it ever after?!<br> <p>Andy Blay<br><a href=mailto:a.d.blay@talk21.com>a.d.blay@talk21.com</a><br><a href= > </a><br>
AbleA wrote:<br><i>Of course, one benefit of a rewrite is that I'll get the chance to play with OOP! Question is, is this something to look forward to or might I bitterly regret it ever after?!</i><br><br>Believe me, this is something that is much easier if you have someone who can mentor you, even if only to help with the rough spots. It is a <i>completely</i> different way of thinking vs. traditional procedural programming, and your natural instincts will be to <i>force</i> your old programming practices into the VFP/OOP model. You'll get very frustrated, and you will think every hour <i>why did they make this harder than it used to be?</i> <br><br>But after you learn and get comfortable with it, you'll never want to go back to the old way. Probably like using a <i>bidet</i>, I imagine.<br><br>I've written an article here <br><A HREF=" TARGET="_new"> <br>in the section <b>Visually Impaired: Visual FoxPro for 2.6ers</b><br>that may be slightly useful. There are other excellent ones out there as well.<br><br>Best of luck, and we're all here to help. <p>Robert Bradley<br><a href=mailto: > </a><br><a href= - Visual FoxPro Development</a><br>
- Thread starter
- #7
I'm not sure what would count as a complex read. All my screens are modal, usually one screen per read but in a couple of cases up to six screens in a read. Doesn't feel particularly complex to me!<br><br>Although I'm interested in how VFP6 could help here, I would do my best to migrate to a full OOP application ASAP! As far as I am aware, this ditches the READ command.<br><br>Rather than read a book on VFP6, I thought it better to get opinions from the "real world" (i.e. here). I already have VFP3 which, feature-wise, would appear to be a reasonable stepping stone into OOP. However, it's the undocumented gotchas I want to hear about. <p>Andy Blay<br><a href=mailto:a.d.blay@talk21.com>a.d.blay@talk21.com</a><br><a href= > </a><br>
I meant complex by like implementing a foundational read, and those doggone screen sets, etc. Man, its been a while and thankfully I've forgotten much. READ VALIDS, eck. READ EVENTS in VFP will blow you away. Maybe you can play with VFP 3 to get the hang of OOP, classes, inheritance, etc and wait for ver 7. I'm unsure when that will be released though but if it's early next year that gives you 6 months. Wow, there was really alot of things added as I think...a true database container; triggers, rules, views, remote views, etc, etc since 2.6a<br>Oh, and row and table buffering and handling of conflicts isn't bad either. Dude, what are you waiting for? lol<br>John Durbin
- Thread starter
- #9
I actually DO want to use VFP, get to grips with OOP, add ActiveX controls, fly to the Moon, etc, etc. Not to mention being able to use variable names longer than 10 characters. In fact, sad to say, I'm quite excited at the prospect. BUT, my role in life is to develop and support one particular application used within the company I work for. This app has about 50 screens which I now believe I would have to completely rewrite in order to take full advantage of VFP's OOP environment. The time it would take to do this is extremely difficult to justify, hence my hesitation. <p>Andy Blay<br><a href=mailto:a.d.blay@talk21.com>a.d.blay@talk21.com</a><br><a href= > </a><br>
The FPW 2.6 application that I was hired to support was written peer to peer with about 10 users and file sizes of about 10 Megs.<br><br>Screen displays and reports were done in Crystal versions 4.5 and 5.0.<br><br>At the present moment, there are 80+ authorized users and file sizes run in the gigabytes.<br><br>I have VFP 6.0 and Crystal 7. <br><br>Conversion has meant rewrite, whether it is a FP program or a Crystal report.<br><br>I have also found no way to integrate the rewritten material into the main program.<br><br>Any help would be appreciated. <br>
- Status