Visual FoxPro 9.0: Best tool on the market for getting things done

Even though FoxPro has long been overshadowed by more glamorous products, it's still one of the best tools on the market for getting things done. With new enhancements in version 9.0, it's not likely to go the way of the dodo anytime soon. 

by David T. Anderson

Today, applications are still being written and deployed in Visual FoxPro, but there has been a marked decline in further adoption and deployment among U.S. companies. This is due primarily to the fact that Microsoft has marginalized the product in comparison with its flagship .NET languages, such as C# and VB.NET. This lack of marketing support is a hot-button issue among the VFP community.

While it may be true that managed code and strict compilers can result in "safer," less buggy, and more durable code, a single FoxPro developer can write a full-blown desktop or Web application in a comparatively short amount of time. The effort required to deal with complexity is left primarily to implementing application and business logic, not trying to understand a massive framework or wrestle with data binding.

So why should you care about a product that receives only the occasional nod from its maker? Because, Visual FoxPro is still here and it is still relevant. It serves a need that is underserved by any other single product in its category. Further, because of its ability to run on cheaper, older hardware, run legacy code, and still do everything a modern programming language is expected to do, it will remain the product of choice for renegade workgroups, small resource-constrained offices, independent software developers, and many governments and government-run agencies.

A Strong Ancestry
To understand the staying power of FoxPro, it helps to understand its lineage. In the mid 80s Jet Propulsion Laboratory (JPL), like most government agencies, was provided with micro and personal computers. These stand-alone machines let engineers crunch large sets of data without jockeying for time on the mainframe. Spreadsheets and stat packages were often used, but were cumbersome and could easily result in data loss.

A database was a logical solution for dealing with these large amounts of data, so Wayne Ratliff wrote a program with its own database and added set of commands that could be executed on that data. " Vulcan " had an interactive dot prompt that allowed engineers to use a short set of commands to work through their data as physical data sets using phrases that were easy to remember. These simple English-like commands could be combined together into programs that could be executed from DOS. These programs became applications—and a new kind of application developer was born, the bandit, renegade, ad-hoc developer. The program eventually became Ashton-Tate's dBase.

"dBASE was different from programs such as BASIC, C, FORTRAN, and COBOL in that a lot of the dirty work had already been done. The data manipulation is done by dBASE instead of by the user, so the user can concentrate on what he is doing, rather than having to mess with the dirty details of opening, reading, and closing files, and managing space allocation." — Wayne Ratliff

Within a few years of its release, a number of dBase clones hit the market. FoxBase made its reputation by being significantly faster and more robust than the original. In addition, the Fox team was agile and more responsive to the user community. Through regular patching, timely support via CompuServe and significant releases, it stayed close to its roots while innovating faster by adding productivity tools in direct response to requests from users.

When FoxPro was released, it provided DOS programmers with a windowing interface. The Fox team had already provided cross platform compilers that allowed a developer to deploy in Unix or DOS, and over subsequent releases Windows and the Mac. Next came FoxPro2, which brought "Rushmore" (FoxPro's famous data performance enhancements), as well as in-line SQL commands and graphical screen and report writers.

Visual FoxPro
Visual FoxPro, (now owned by Microsoft) brought OOP, a fully relational data store, and remote data access. So by 1995, FoxPro developers were natively using SQL, doing OOP, and writing n-tier, cross platform applications—and all the while running legacy code written back in dBase II.

For FoxPro developers, Fox has simply been a safe application development path; your investment in the technology was not compromised by innovations made by the vendor. Unfortunately, the same can no longer be said with regard to marketing or other products made by the same vendor. This has lead to today's misconceptions about FoxPro and its place in the developer's world.

. Everything you need to write, deploy, and maintain n-tier, high-availability, desktop, Internet, COM and Web services development is in the box or available from a third-party vendor. It contains a robust object-oriented language and a fully relational, notably fast, database that supports tables under two gigs or one billion records, and a stand-alone OLEDB data provider. Even the IDE, with fully extensible design surfaces, has significant portions of its tools and wizards built in its own language (with released source). There is also strong compatibility with SQL Server, excellent COM interop—including Office automation, powerful XML processing and functionality, and it's still backward-compatible with code written 20 years ago!

So Where Does VFP Fit in Today?
It's Still the Choice of Professionals Who Need to Get the Job Done
Especially if that person's primary job isn't writing software.

In the words of Lt. John Harvey :

"My day job is that of a lieutenant for the Shelby County Sheriff's Office in Memphis , TN where I am the bureau commander for Information Systems. I have developed systems that are currently in use by our agency, the Memphis Police, all local law enforcement agencies, and most federal agencies such as the FBI, ATF, Marshals, and the Secret Service. My latest "big project" is a laptop-based system for our Fugitive Bureau where the officers access data via wireless modems and WiFi. They are able to pull up mugshots, arrest reports, etc, as well as print the arrest tickets from the field. The middleware is Webconnection (a VFP Web Product) and we pull data from VFP, SQL Server, and the Tandem Mainframe."

I asked him if he thought he could have done what he's done in .NET. His response was "I have three .NET developers here that I run rings around."

This is not because the applications are better suited to run in Fox than in .NET. It's because a sheriff's officer was able to start using a tool interactively, automate his work, migrate his programs into an application, expand the application to integrate with other systems, and ultimately create a suite of invaluable tools.

It's Still the Choice of Developers with a Significant Investment in Existing Code
Chris Jeffries is a vice president of development at Human Resources MicroSystems. Their suite of HR applications rivals the power and functionality of SAP and PeopleSoft systems. The core of the application was written in Visual FoxPro and .NET and they have products that target small to medium sized organizations, as well as large enterprises.

Chris states:

"... there are, by my guess, billions of data records stored in FoxPro worldwide and the FoxPro DML is the best way to manage those records. The language is the most approachable language in the programming world and is easily understood by those with minimal skill."

On migrating to .NET:

"We are spending more time developing new solutions in .NET than we are in VFP, but our core business is still in VFP. The desktop application will most likely remain in VFP because it's just too big to re-write in .NET due to resource constrictions. .NET forms, reports, and other aspects of the VFP desktop app would have to be re-written from scratch to provide the same kind of end-user flexibility."

It's Still the Choice of Managers with Constrained Resources
Visual FoxPro can run on hardware that is over eight years old, and it's still fairly snappy. This may seem like a ridiculous fact, but if you have ever worked in Third World markets, or with military or government agencies, you know that being able to run on older hardware is a non-negotiable requirement. The ability to distribute and scale applications written in FoxPro without worrying about licensing is often a big part of the buying decision as well.

It's in these same environments that IT resources are at a premium, and rarely available for maintenance of old systems. But because of FoxPro's high discoverability, it is fairly easy for someone to figure out what it takes to maintain or even extend the application.

Garrett Fitzgerald , a VFP MVP says it this way:

"FoxPro has long been the bread and butter for companies that don't want to (or can't) spend the money to chase the latest technology. Mom and Pop stores don't tend to need a .NET/SQL Server solution to run their businesses, and can't justify spending the money to do it correctly. FoxPro is peppy, even on lesser hardware—compare the requirements for both. However, when properly written, Fox apps can (and have) handled data sets up into the 100s of gigs."

On why he continues to choose VFP: "Because I can be highly productive and deliver excellent value to my customers using VFP. "

It's the Swiss Army Knife of Data-centric Applications
I find that having delivered applications in VFP, I have a grasp of the entire software development process. I understand issues from design to development to maintenance and migration. I understand the ins and outs of database design, object-oriented design, user interface design, business object design, data access layers, COM and Web services, and enterprise design patterns.

Why should you care about Visual FoxPro? Because it's everywhere, it's powerful, it's quick to learn, it's cheap, and the guy who wants your job knows what it can do—and because certain kinds of programming jobs lend themselves to quick and dirty ad-hoc data manipulation.

In other words, I like being a .NET developer who understands this tool, rather than one who doesn't. Even if I were to never write another FoxPro app again, it will always be installed on my machine.

David T. Anderson is a member of Alden Anderson, LLC. He recently completed a contract tester assignment with the Visual FoxPro team at Microsoft testing the data enhancements made to Visual FoxPro 9 and implementing performance benchmarks such as the Transaction Processing Council's TPC-H. With 22 years of application development experience in the PC industry for government, military, educational institutions, and private industry, David uses his experience relating Enterprise Architecture and Organizational Maturity to assist organizations in determining the most appropriate software processes for their needs.