An additional argument for staying with Visual FoxPro now was that if we switched to some other programming language, it too might also be obsolete when a move from Visual FoxPro was mandatory.  There was certainly no interest in rewriting the system twice in the coming decades!

Further discussion revealed that part of the concern was with data sharing in the organization.  The Visual FoxPro data is all housed in a server at one location where most of the manipulation and reporting is performed.  A couple of locations remote to this server access it for simple queries.  Wouldn’t we have to rewrite the system if we wanted to centralize the data — using SQL Server or some other database system?

This turns out to be one area where Visual FoxPro has much flexibility.  It does not have to rely on the native FoxPro data layout.  It can access SQL Server (and many other types of data) just as well.  Although it would be more complicated than converting the data and throwing a switch, it would be much more economical than a complete system rewrite and could be staged, moving parts of the data to the shared environment as it became desirable to share that particular data.  Additionally, it would be possible to replicate the data to be shared and keep all the existing processes unchanged.

The bottom line is that Visual FoxPro continues to be a viable development solution for a wide variety of applications.  I certainly recommend continuing to use it in existing applications and would not totally dismiss using it for new applications.

Part of the selection process was to catagorize the records selected.  When some catagories came up with no records found, it was clear that there was a problem with the new selection process.  A correction was made and a rerun of the selection yielded very similar but different counts. 

The new process gave slightly higher counts in most categories, lower in others.  Part of this was correctly attributed to the time frame involved:  part of the criteria was based on activity in the previous 12 months — the selection in the new process was run later so that there was some new activity, but also records where the activity was just over 12 months old would not have been selected.

To find out the cause of any other differences, the two different selection files were compared.  It was found that there were about 1000 (out of 35000) records selected by the new process that had not been selected by the old process.  There were also about 900 records selected by the old process that weren’t selected by the new process. 

Analysis of these records uncovered the fact that the old process was selecting records that were supposed to be skipped and not selecting other records that were supposed to be selected!  It also uncovered about a dozen records that the new process missed selecting.

The moral of this little story is that just because the new doesn’t match the old that the new must be wrong.  But there is more!  It also suggests that it is wise to audit existing processes from time to time.  In this case, it was clear that most of the selection criteria were being handled properly — it was more recently added criteria that wasn’t being correctly handled.

Even if you have no plans to replace a data selection process, perhaps now would be a good time to schedule an independent audit to verify that you are getting what you think you should be getting!

We quickly determined that the only possible route to save the business from a serious outage was to build a replacement application as soon as possible.  The most critical functions were identified and these were developed first.  It was also necessary to create a program to extract the data from the current application.

The new application was completed and tested and the customer started using it before the old application stopped working entirely.  Additional, less critical functions were added at a more leisurely pace!

This was certainly a rare situation, but could happen to anyone.  We prefer not to work with such deadlines, but if we must, we are able to identify and focus on the critical functions and get the customer up and running with as little disruption as possible.

We welcome you to come back regularly to find out about new developments in fixing and avoiding software train wrecks. 

We will also share about things we are doing in the community and ways you might get involved!