Myths about Visual Foxpro

--Richard Katz

The following are a question and response posted on the Microsoft Foxpro Programmers Exchance NewsGroup in September, 1997.

> Mike wrote:
> I've been reading alot of negative things about Visual Foxpro and a
> question comes to mind. If you guys who know foxpro really well don't like
> it, maybe I should get out before its to late.
> Also, why are you still using it?



What do you mean "still?" It's only been out for 2 years and 2 months now. Happy birthday to VFP..(g).

Seriously, here are 3 reasons:

  1. Learning VFP will put you years ahead in terms of being able to adjust to OOP/OOA/OOD in comparison to only using VB. VFP has good PEM functions, a class browser, and can handle multiple class libraries. VB has no class browser, no class libraries, and can't subclass. If some future version of VB does contain these, you will know enough to be able to use it before it's ever released.
  2. As a client/server development tool, VFP is easier, more problem oriented, more capable, offers better cursor and connection control, and has native SQL.
  3. The DBC is more stable and capable than the MDB. It can be logically divided among network drives and doesn't suffer from MDB compacting requirements.

Over several years, I've accumulated a number of common myths about VFP, Here are some of them debunked:

Myth 1: VFP based on the outdated xBase language as opposed to Visual Basic which is very modern.

Reality: Why is Basic more modern than xBase? dBase III was released in the early 1980s. Basic was created in 1960. Basic "without line numbers" even predates xBase by maybe a couple years. Error handling in Visual Basic still requires you to use "GOTO." If that's modern, I don't know what outdated means.

Myth 2: VFP is for legacy programmers.

Reality: It takes a lot of learning for legacy programmers to use VFP OOP capabilities properly. If you have used VB, you will shorten the learning curve as you learn to invoke object. But using VB by itself won't get you *over* the learning curve, because VB offers no place to go with OOP.

Myth 3: VFP is slower than Visual Basic

Reality: In many cases reported in this news group, VFP is actually faster. (I haven't saved the references). But it's a moot point when dealing with database intensive work. For manipulating local data, VFP is definitely faster. For manipulating client/server data, you won't gain any speed by converting to VB, (or even C++ for that matter).

Myth 4: Microsoft does not support VFP.

Reality: It is true that VB is Microsoft's strategic language of choice. This was true before Microsoft bought Fox Software. But Microsoft has definitely not abandonned VFP. Major releases of VFP (3.0, 5.0) have occured twice in the last two years. Minor releases (3.0b, 5.0a, 5.0 SP2) have occurred 3 times. The VFP development team is quite talented and is working on a new release VFP 6.0 also known as "Tahoe".

Myth 5: VFP is not truly a relational client/server tool.

Reality: VFP 5.0 supports full ANS SQL capabilities, including outer joins. These can be performed on both local and server data. While VFP also supports older xBase constructs such as SET RELATION, you do not need to use these to use VFP.

As a client/server tool, VFP offers GUI control of views and connections and is able to control connections better than VB. Additionally it provides both native SQL for server data as well as pass-through.

Myth 6: "We have to decide whether to use VB and Access/VBA or to use VFP."

Reality: There is no particular reason why this is an either-or decision. You can use VFP with Office tools just as you can use VB with them. Over the last 10 months, VFP 5.0 has maintained better compatibility than VB 4.0 or VB 5.0 and has had few if any installation conflicts with Office 97 and Office 95. I've used it with both under both Win95 and NT 4.0.

For local data, you can store information in the DBC and easily reach it from Access 95 or Access 97. Doing so provides you with better physical control of data storage than storing data directly in an MDB. There is also no reason why not to use both VB and VFP on the same project. VB is a good Windows development tool, but not primarily a database tool. Both tools can use the same controls. Using both of them might provide you with the best of both worlds, plus they are packaged together in Visual Studio.

In today's world, there are new development tools appearing at the rate of about 10 per day. Programmers are going to be better off knowing more than one language and need to be able to use class inheritance (or its equivalant, object delegation). You can use VFP without learning inheritance, and it has an easy to use "Save As Class" menu item, so VFP gives you a rather gentle introduction to OOP.

If anyone has any additional myths, plese post them!



Richard Katz