Back in the 80's and 90's there were a lot "consultants" out doing VFP work. The quality of their work was poor. They did what many are still doing - they'd hang a grid on a form and call it a program. Some of the most expensive non-Excel spreadsheets the corporate world had ever seen.

It had nothing to do with VFP. The people that wrote "real" VFP programs survived and are doing well. Some have made bunches of money and continue to develop with VFP. There are classes of developers that are never asked what tool (or more likely "tools" these days) they work with because it doesn't matter.

You mention corrupt indexes - many projects never have that problem - programs I wrote 6 and seven years ago (in VFP 5 evun!) are still doing their job. A lot of the problem was that new developers moving to VFP started depending on all those VFP-tools-shops for stuff that they used to build themselves. As the framework guys move to NET - we'll be hearing complaints like:"All those NET programs look the same." Or Why can't the program do this - and on - and on! What goes around - comes around.

To write high quality solutions with VFP requires a lot of effort. It is not an easy language to learn. Hopefully NET will be easier for the people leaving VFP!



So

>I am simply stating what I have heard and seen. A typical scenario:
>
>- a department, for whatever reason, does not enlist IT's help, and selects a software package for their department.
>- The package has been written in VFP, storing in DBF's
>- The IT shop typically has no VFP programmers on staff. They develop their own apps in VB / Java / whatever their standard is. Probably storing data in SQL or Oracle
>- At some point in time, IT is brought into the picture. Possible reasons:
> 1) There were some problems. Possibly caused by bad indexes/dbfs and the vendor was unable/unwilling to fix the problem
> 2) The system became corrupted and no one was backing up. IT is brought in to add this system to their backup routine
> 3) The vendor has disappeared
>