when to migrate from FPW to VFP

[repete]

I have a FPW 2.6a system that has in excess of 175 reports, 135 screens, 125 tables (largest has 400,000 records), and 250 programs, and falls into the "mission critical" category of systems. The development of this system has suffered from many sins in its 5 years of development, having at least 6 different developers over a period of 5 years. It suffers from quick fixes, and fragmented development of functionality, apart from multi-user inadequacies, and errors in the data results.

Reading the threads on FPW 2.6 issues with NT, fast PC's, and the like, when running this system, we have suffered all if not most of these. They are all surmountable, but all take time to surmount.

It is possible that I may be responsible for the development of this system over the next 12 months, and am undecided as to which is the best way to go with a system that is large, critical to the organization, and is sloppy in its generation of results. Reality teaches me that version 1.0 of anything has the potential to be 'buggy', however any re-development of this system has to work well because of its importance to the organization. As always, money is tight, the completed system needs to be ready to use in June 2001.

I know both FPW and VFP are great products, and yes therre may be other solutions to consider, but the best software is the software you know, and I know Foxpro, so for that reason my 2 alternatives are FPW or VFP. I can see that eventually the development of this system should move to VFP, however the question I have is this. Should I move direct to VFP now, or get rid of the design problems in the FPW2.6a system ?

Remember.... I am not super-human, don't know everything there is to know about FPW, and even less about VFP, but I'd like any suggestions ? I'm not so much interested in each products ability to do what I want to do, I have no doubts there. What I am interested in hearing about, are peoples experiences in what to do with an unstable FPW system - move as soon as possible to VFP development or battle on with FPW to get it right, and then make the move.

ps (I've posted this in FPW and VFP threads)

regards

Pete Bloomfield
Down Under

 

[BlindPete]

I was there myself about 2 years ago... I ported a legacy FP2.6 DOS project to VFP5 in about an hour. A week later it ran stable, but it looked like hell. I ended-up re-developing all the reports from scratch (no small task). I ended up replacing all the screens with forms too.

Bonus! all the data logic remained unchanged. I replaced the reports 1rst. Then the screens to forms as I could. Basically I replacing the client EXE every Sat for 3 or 4 months. It was a lot of work, but it would have been a lot more work to start over in another language. I also worked alone... which sucked.

The legacy system was also developed by several different people, none of whom were still around. It was mostly undocumented and had band-aid ontop of band-aid. As I replaced each screen with a form, it was neccessary to dive into the logic. I found many errors and fixed them that way. Ultimately streamlineing the code considerable.

In the end you will know a lot of VFP. BTW the orginal 1rst cut project was 1.89 MB the final fully VFP client is barely 600k...

I say convert it to VFP6 rather than re-develop.


Pete
blindpete@mail.com

What your mother told you is true! You will go blind! (from moonshine anyway)

 

[foxdev]

If you want to learn VFP and its flavor of OOP, then my opinion is to completely redesign and redevelop it in VFP.

If, instead, you are pretty happy with the current system but just want it to work better, I'd say stick with FPW.

I've done quite a few "conversions" where I take an FPW system and make it run under VFP. I always ended up ultimately unhappy, though, and eventually redesigned and rebuilt the whole thing in VFP. If time is critical, though, you probably can't go the redesign route.

Robert Bradley

http://www.foxdev.com/

 

[repete]

thanks for the replies.

Pete, I can understand the change from the screens to the forms. I'd rather scrap a lot of what is there, and start over with new forms, as this is where a lot of my problems are at present. But reality warns me that there would be a period of time where I have no operational system because of that development.

At the moment, when the current FPW26 screens require some change, I am finding myself replacing logic issues at the same time, so I can relate to that also.

I didn't understand your comment that reports had to be re-developed. Why so ?

Another question...... I have Visual Studio 5 (with VFP 5.0) currently. Moving from FPW26 to VFP 5.0 is ok ? or should I upgrade to VFP 6.0 before the change from FPW26.

And yet again, another question...... the data in this system has grown 50% from last year's activity, with an expectation that next year will see another 50% increase, so the largest file will be around 650,000 records and 33meg. I know this is well within capacities, but some of the system's functionality slows down dramatically. Hardware changes this year (from last year) have helped enormously, but (and finally my question) will a move to VFP from FPW26 also help performance ?


Pete Bloomfield
Down Under

 

[Shanachie]

Last spring, I moved my client's FPW2.6 app to VFP6.0 because the network admins were blaming some network problems on the app. FPW2.6 was "too old to be reliable in our current environment." I found that porting the entire app (25 screens, 10 reports, 30 tables) took about 2-3 days, mostly making things line up right on the screens and reports.

The network problems didn't go away and they were forced to deal with them. (Once they took it seriously, it got fixed fast.)

The bonus was that the app ran considerably faster. I didn't expect that but the client was delighted. They asked me to rewrite the entire app in VFP6.0.

It's just about done, implementation around mid-Jan. It's a whole lot slicker, runs even faster, is just all round better. And redesigning allowed the app to better fit the business process. (Well, actually, redesigning the app allowed them to redesign the business process so the result is a tremendous improvement.)

I'd lived with FPW2.6 for five years and I now wish I'd prodded them into moving much sooner. When I have to go back to 2.6 now, I shudder. Remember, when 2.6 was under development, Win3.1 was state-of-the-art. A few things have changed since then. (;>)

Shanachie