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 Mike Lewis 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

Status
Not open for further replies.

AbleA

Programmer
May 23, 2000
20
0
0
GB
Visit site
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?&nbsp;&nbsp;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>
 
Andy, there is only one migration path that you will ultimately be happy with:&nbsp;&nbsp;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.&nbsp;&nbsp;FPW screens simply don't translate well to VFP forms, and they definitely don't fit the OOP model.&nbsp;&nbsp;I know this isn't what you want to hear, but I've tried a half-dozen FP-to-VFP &quot;transport&quot; conversions, and what you end up with is so convoluted that you'll become disgusted with VFP.&nbsp;&nbsp;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.&nbsp;&nbsp;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>
 
I can't see going to VFP5 when VFP6 is available.&nbsp;&nbsp;If you upgrade, upgrade to 6<br>John Durbin
 
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?&nbsp;&nbsp;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!&nbsp;&nbsp;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!&nbsp;&nbsp;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.&nbsp;&nbsp;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.&nbsp;&nbsp;You'll get very frustrated, and you will think every hour <i>why did they make this harder than it used to be?</i>&nbsp;&nbsp;<br><br>But after you learn and get comfortable with it, you'll never want to go back to the old way.&nbsp;&nbsp;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.&nbsp;&nbsp;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>
 
If you're doing any complex reads in 2.6 you'll definately welcome 6.&nbsp;&nbsp;Have you picked up a book and checked it out?<br><br>John Durbin
 
I'm not sure what would count as a complex read.&nbsp;&nbsp;All my screens are modal, usually one screen per read but in a couple of cases up to six screens in a read.&nbsp;&nbsp;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!&nbsp;&nbsp;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 &quot;real world&quot; (i.e. here).&nbsp;&nbsp;I already have VFP3 which, feature-wise, would appear to be a reasonable stepping stone into OOP.&nbsp;&nbsp;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.&nbsp;&nbsp;Man, its been a while and thankfully I've forgotten much.&nbsp;&nbsp;READ VALIDS, eck.&nbsp;&nbsp;READ EVENTS in VFP will blow you away.&nbsp;&nbsp;Maybe you can play with VFP 3 to get the hang of OOP, classes, inheritance, etc and wait for ver 7.&nbsp;&nbsp;I'm unsure when that will be released though but if it's early next year that gives you 6 months.&nbsp;&nbsp;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.&nbsp;&nbsp;Dude, what are you waiting for?&nbsp;&nbsp;lol<br>John Durbin
 
I actually DO want to use VFP, get to grips with OOP, add ActiveX controls, fly to the Moon, etc, etc.&nbsp;&nbsp;Not to mention being able to use variable names longer than 10 characters.&nbsp;&nbsp;In fact, sad to say, I'm quite excited at the prospect.&nbsp;&nbsp;BUT, my role in life is to develop and support one particular application used within the company I work for.&nbsp;&nbsp;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.&nbsp;&nbsp;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.&nbsp;&nbsp;&nbsp;<br>
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top