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

when to migrate from FPW to VFP

Status
Not open for further replies.

repete

Programmer
Nov 14, 2000
151
AU
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
 
Pete,

Sounds like the typical dilemma developers throughout the
word face. I have been in a similar position to this many
times and would offer the following from my own experience.

First, is there a need to change (to VFP).
Is that what the users want?
Is it what you want?
Is it practical - will they gain/lose functionality?


Second, what resources do you have?
FPW experience V VFP experience
Costs to users and to company
Time to complete project
Additional resources - ie training, support.

Although developers for FP Dos & FPW are becoming extinct,
given the time to have this successfully up and running in
7 months, I would stick with what you know best. The system
seems to be of a medium size and if you are new to the software it will take you the best part of 6 months to really know how it works inside out.

You mention there are endless bugs, quick fixes to code,
endless developers contributing to a situation which no-one wants to touch, but in reality, that is not an uncommon
situation.

As stated earlier, this dilemma will have no good solution
but as you are not responsible for what has happened previously, I would summarise your reasons as to why it would be best to stick with what you have - and then in the background make moves to have it re-written over a more
realistic timescale with proper planning and training.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top