Folks,
In regards to MIchel's posting of VFP vs Access messages... I hope this is something that can be passed along for reference.. I can NOT claim authorship, but I can claim to have been part of this thread up on the MS newsgroups..

This is from the MS Newsgroups, where there have been a number of people asking why VFP is still being used and/or what the difference is between Access and VFP...

Just something for you to think about when people start putting Foxpro down again..

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?

Mike,

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!

Thanks,


Richard Katz

Thanx!!

Tony Miller
Vancouver, Wa