To stay with FoxPro or not.......your thoughts?

[Newmc]

Hello,

I support a fruit processing plant that has made extensive use of both FoxPro 2.6 and Visual FoxPro 6.0 to capture and analyze all data associated with their processes. I am not a programmer although I have done some design work with access.

The owner of the plant (who is also the FoxPro programmer) is 67 and getting ready to retire. I have been asked to help them map out their strategy for the future.

My question is this, should they stay with FoxPro and find someone else to maintain and develop the database, or should they migrate to a different database that would be easier to maintain? If migrating is the answer, what database should they migrate to? Your input will be deeply appreciated.

 

[ramani]

HI Newmc,

There is hardly anything in your question as to why it should not. Is it because the owner is 67 and retiring?
Is the fruit processing company going to process something else after he retires?. Sorry that I am so critical.. but you are putting a question which is not in good taste to this community here... atleast to me.

Have you found that VFP is short of something on which you are commenting ?.

Leaving the citicism, you can very well continue with VFP and migrate the FP 2.6 codes to VFP platform. May be you need a VFP knowlegeable man to work out your requirements.

That is true with any language.. you need the right professional. Unless the retiring man leaves and the new person has his own knowledge in another platform and he wants to make that his way, I dont find any reason that the VFP things need to be changed.

Sorry to be critical ramani
(Subramanian.G),FoxAcc, ramani_g@yahoo.com

 

[wgcs]

Another database won't be intrinsicly "easier to maintain" than VFP databases... what's most important is the design of the databases and data-accessing programs.

Your company has a large investement in creating the VFP/FPD access logic and User Interfaces, so, if it's all holding together well, migrating to another "platform" would only entail a large investment of time and money just to get back where you are now.

VFP is very capable, and not hard to learn: It would probably be most cost effective to find someone with some VFP experience to continue the day-to-day maintenance and improvements to the existing system, and convert the FP Dos parts to VFP.

 

[FoxEgg]

Dear Newmc,

I can see Ramani's point... in a nutshell, perhaps
worded differently; why (on earth) would
you ask people in a VFP forum whether or not
and then where you should migrate an existing
Fox program; especially when those whose
advise you seek volunteer their intellectual
effort and time to help others with VFP
programming problems... What is seemingly
worse is that it seems that you do not appear to
have put any intellectual effort into looking at
what has been done by your 67 year old...



In this forum, your question makes no sense to
me.... (Why don't you post it in the Access
Forum... I could not imagine what they might
say !!)

But in the spirit of the forum... I'd recommend
dBase II... or Paradox... and another Forum.

Hope this helps.

J.

Oh and remember, one day you will be 67 too.

and Hey ...

... do I get a star for this one ???

 

[darrellblackhawk]

It depends!

Since you probably have quite a bit invested in the current application, and if it's working well, I'd stay with Foxpro.

You'll need to map out the application and get the owner/programmer/soon to be gainfully unemployed person to document his work to date.

You may want to bring in a consultant that can profile and reverse engineer the app with the help of the owner, document the requirements, and produce quality workflow procedures. That way, you'll get a non-biased view of the current state-of-affairs, and documents that help in moving forward when the former owner is off sailing.

No matter which path you take, you'll need to at least know where you stand vis-à-vis the application.

Otherwise, you'll be in bad shape when problems arise. And they will - I can assure you.


Darrell
'We all must do the hard bits so when we get bit we know where to bite'