> Sorry for the length of this posting, but if you are familiar
> with both Visual Foxpro and Jet 3.5, I really could use your
> help.  Let me say first and foremost that I'm not trying to get
> into a religious war... I'm just seeking information to help my
> company make the best possible decisions.

> My company has developed some products in VFP that serve as
> analytical, decision-support tools for healthcare
> professionals. By necessity, these apps interactively crunch
> LOTS of data... they demand very fast, complex, multi-table
> analytical operations. Our top management is delighted with the
> features, performance, and look/feel of our products. However,
> at the same time, they have little appreciation for function
> when it clashes with business objectives like developing our
> products with market-share, well-accepted tools such as VB5.

> Thus, I am trying to research an elusive comparison between VFP
> and VB/Jet. Specifically, when you compare VFP's database
> engine against Jet 3.5, which one is superior in terms of
> performance and flexibility? In particular, we need to know the
> power/speed of Jet insofar as its ability to handle fast
> lookups on indexed multi-million record files, its ability to
> support programmatic creation, manipulation, and discarding of
> innumerable temporary read/write tables, and also its ability
> to provide very flexible, near instantaneous manipulations of
> multiple, interrelated tables that might have between 1000 and
> 100,000 records each.

> For example, in VFP it's easy and extremely fast to do a couple
> of pass-through queries, then create an index on each resultant
> client-side cursor and relate the resultant cursors on a common
> index expression (not necessarily related on a static field,
> but rather related on an expression... very important!).  One
> can make the cursors read-write with a single statement. One
> can then "walk the indices" of these two (or more) "related"
> cursors and do all kinds of powerful analytics, manipulations,
> and lookups nearly instantaneously. Many of these analytics and
> manipulations go far beyond what one can do with SQL alone.
> Then, with an additional statement, one can flip any records of
> interest into a permanent table or export them into an Excel
> file, etc. This is nirvanna for us insofar as meeting our
> functional objectives.

> Can Jet 3.5 support these kinds of operations, and do it really
> fast?  What about flexibility?  From what I've read, it seems
> that Jet might impose some show-stopping obstacles when it
> comes to supporting read/write cursors derived from SQL
> pass-through queries and the like.  Is this easy to work
> around?

> Thanks very much!!! If any VFP/Jet gurus out there would like
> to discuss this further in real time, I would love the
> opportunity to do so... on my dime.

> - Mark S. Frank

> Paul, thanks for your reply.  I agree with your comments.

> There seems to be an interesting dichotomy between what one might
> refer to
> as "database analytics" vs the kind of database programming that is
> seen
> in the majority of VB applications (i.e., transaction-oriented)

> In my mind, database analytics requires capabilities to rapidly
> retrieve
> subsets of data from one or more sources and subsequently perform a
> series
> of additional analytical operations where those retrieved subsets are
> related into and compared with several other subsets of data...
> basically
> an iterative process of "drilling down", "splitting off", and "summing
> up"
> along the way.  Many of the necessary comparisons/relationships
> between
> the data sets cannot be supported by SQL alone, but are well suported
> by
> the capabilities of the VFP database engine.

> As a rule of thumb, I believe that the more an application needs an
> esthetically pleasing transaction-oriented user interface, the more
> appropriate is VB.  The more OLAP-oriented and analytically driven
> need be
> an application, the more appropriate is VFP.

> Mitch,

> Your comments are valid, but the comment about the VB interface being
> less kludgy and more more powerful just doesn't hold water. In the
> hands
> of a talented VFP programmer vs an equally talented VB programmer, I
> would wager that you would see scant differences between their two
> interface capabilities. Both products have their pros and cons even at
> the interface level.

> While there are aspects of the VB interface that are better than VFPs,
> there are items where it also works the other way around. VB is good
> for
> what it is good for, and VFP is good for what is good for. Having
> worked
> with VFP and VB, the biggest obstacle is learning to work _with_ each
> of
> these languages, and not try to force a VB approach down the throat of
> VFP app, or vice-versa. If you do that, you _will_ get a "kludgy" and
> "less powerful" interface. Interface-wise, VFP and VB are pretty
> evenly
> matched. The difference is almost entirely in the talent of the
> respective programmers. Now, if you would like to discuss Delphi...

> -Tom

> > > > The advantage of VB is that you can work with any type of DBMS.
> > > However,
> > > > if your applications are going to be based on FoxPro tables in
> the

> > > > foreseeable future then I would stay with VFP.

> > > Paul, thanks for your reply.  I agree with your comments.

> > > There seems to be an interesting dichotomy between what one might
> > > refer to
> > > as "database analytics" vs the kind of database programming that
> is
> > > seen
> > > in the majority of VB applications (i.e., transaction-oriented)

> > > In my mind, database analytics requires capabilities to rapidly
> > > retrieve
> > > subsets of data from one or more sources and subsequently perform
> a
> > > series
> > > of additional analytical operations where those retrieved subsets
> > are
> > > related into and compared with several other subsets of data...
> > > basically
> > > an iterative process of "drilling down", "splitting off", and
> > "summing
> > > up"
> > > along the way.  Many of the necessary comparisons/relationships
> > > between
> > > the data sets cannot be supported by SQL alone, but are well
> > suported
> > > by
> > > the capabilities of the VFP database engine.

> > > As a rule of thumb, I believe that the more an application needs
> an
> > > esthetically pleasing transaction-oriented user interface, the
> more
> > > appropriate is VB.  The more OLAP-oriented and analytically driven
> > > need be
> > > an application, the more appropriate is VFP.

> >    I agree with both of you. VFP sounds like a better solution. My
> > opinion is that when working with data that VFP is vastly superior
> to
> > VB
> > but the VB interface is much less clugy and much kore powerful. Just
> a

> > thought... but I might consider going client/server and throwing
> your
> > data into SQL-Server.... it can't be a complete argument without
> > including this option.

> > Mitch Hiller

> > > The advantage of VB is that you can work with any type of DBMS.
> > However,
> > > if your applications are going to be based on FoxPro tables in the

> > > foreseeable future then I would stay with VFP.

> > Paul, thanks for your reply.  I agree with your comments.

> > There seems to be an interesting dichotomy between what one might
> > refer to
> > as "database analytics" vs the kind of database programming that is
> > seen
> > in the majority of VB applications (i.e., transaction-oriented)

> > In my mind, database analytics requires capabilities to rapidly
> > retrieve
> > subsets of data from one or more sources and subsequently perform a
> > series
> > of additional analytical operations where those retrieved subsets
> are
> > related into and compared with several other subsets of data...
> > basically
> > an iterative process of "drilling down", "splitting off", and
> "summing
> > up"
> > along the way.  Many of the necessary comparisons/relationships
> > between
> > the data sets cannot be supported by SQL alone, but are well
> suported
> > by
> > the capabilities of the VFP database engine.

> > As a rule of thumb, I believe that the more an application needs an
> > esthetically pleasing transaction-oriented user interface, the more
> > appropriate is VB.  The more OLAP-oriented and analytically driven
> > need be
> > an application, the more appropriate is VFP.

>    I agree with both of you. VFP sounds like a better solution. My
> opinion is that when working with data that VFP is vastly superior to
> VB
> but the VB interface is much less clugy and much kore powerful. Just a

> thought... but I might consider going client/server and throwing your
> data into SQL-Server.... it can't be a complete argument without
> including this option.

> Mitch Hiller

> Your comments are valid, but the comment about the VB interface being
> less kludgy and more more powerful just doesn't hold water. In the
> hands
> of a talented VFP programmer vs an equally talented VB programmer, I
> would wager that you would see scant differences between their two
> interface capabilities. Both products have their pros and cons even at

> the interface level.

> While there are aspects of the VB interface that are better than VFPs,

> there are items where it also works the other way around. VB is good
> for
> what it is good for, and VFP is good for what is good for. Having
> worked
> with VFP and VB, the biggest obstacle is learning to work _with_ each
> of
> these languages, and not try to force a VB approach down the throat of

> VFP app, or vice-versa. If you do that, you _will_ get a "kludgy" and
> "less powerful" interface. Interface-wise, VFP and VB are pretty
> evenly
> matched. The difference is almost entirely in the talent of the
> respective programmers. Now, if you would like to discuss Delphi...

> -Tom

> > > > The advantage of VB is that you can work with any type of DBMS.
> > > However,
> > > > if your applications are going to be based on FoxPro tables in
> the

> > > > foreseeable future then I would stay with VFP.

> > > Paul, thanks for your reply.  I agree with your comments.

> > > There seems to be an interesting dichotomy between what one might
> > > refer to
> > > as "database analytics" vs the kind of database programming that
> is
> > > seen
> > > in the majority of VB applications (i.e., transaction-oriented)

> > > In my mind, database analytics requires capabilities to rapidly
> > > retrieve
> > > subsets of data from one or more sources and subsequently perform
> a
> > > series
> > > of additional analytical operations where those retrieved subsets
> > are
> > > related into and compared with several other subsets of data...
> > > basically
> > > an iterative process of "drilling down", "splitting off", and
> > "summing
> > > up"
> > > along the way.  Many of the necessary comparisons/relationships
> > > between
> > > the data sets cannot be supported by SQL alone, but are well
> > suported
> > > by
> > > the capabilities of the VFP database engine.

> > > As a rule of thumb, I believe that the more an application needs
> an
> > > esthetically pleasing transaction-oriented user interface, the
> more
> > > appropriate is VB.  The more OLAP-oriented and analytically driven

> > > need be
> > > an application, the more appropriate is VFP.

> >    I agree with both of you. VFP sounds like a better solution. My
> > opinion is that when working with data that VFP is vastly superior
> to
> > VB
> > but the VB interface is much less clugy and much kore powerful. Just
> a

> > thought... but I might consider going client/server and throwing
> your
> > data into SQL-Server.... it can't be a complete argument without
> > including this option.

> > Mitch Hiller

> Now you've piqued my curiosity. What do you think about Delphi????

> Michael Copeland
> Genesis Software

> > Mitch,

> > Your comments are valid, but the comment about the VB interface
> being
> > less kludgy and more more powerful just doesn't hold water. In the
> > hands
> > of a talented VFP programmer vs an equally talented VB programmer, I

> > would wager that you would see scant differences between their two
> > interface capabilities. Both products have their pros and cons even
> at
> > the interface level.

> > While there are aspects of the VB interface that are better than
> VFPs,
> > there are items where it also works the other way around. VB is good

> > for
> > what it is good for, and VFP is good for what is good for. Having
> > worked
> > with VFP and VB, the biggest obstacle is learning to work _with_
> each
> > of
> > these languages, and not try to force a VB approach down the throat
> of
> > VFP app, or vice-versa. If you do that, you _will_ get a "kludgy"
> and
> > "less powerful" interface. Interface-wise, VFP and VB are pretty
> > evenly
> > matched. The difference is almost entirely in the talent of the
> > respective programmers. Now, if you would like to discuss Delphi...

> > -Tom

> > > > > The advantage of VB is that you can work with any type of
> DBMS.
> > > > However,
> > > > > if your applications are going to be based on FoxPro tables in

> > the

> > > > > foreseeable future then I would stay with VFP.

> > > > Paul, thanks for your reply.  I agree with your comments.

> > > > There seems to be an interesting dichotomy between what one
> might
> > > > refer to
> > > > as "database analytics" vs the kind of database programming that

> > is
> > > > seen
> > > > in the majority of VB applications (i.e., transaction-oriented)

> > > > In my mind, database analytics requires capabilities to rapidly
> > > > retrieve
> > > > subsets of data from one or more sources and subsequently
> perform
> > a
> > > > series
> > > > of additional analytical operations where those retrieved
> subsets
> > > are
> > > > related into and compared with several other subsets of data...
> > > > basically
> > > > an iterative process of "drilling down", "splitting off", and
> > > "summing
> > > > up"
> > > > along the way.  Many of the necessary comparisons/relationships
> > > > between
> > > > the data sets cannot be supported by SQL alone, but are well
> > > suported
> > > > by
> > > > the capabilities of the VFP database engine.

> > > > As a rule of thumb, I believe that the more an application needs

> > an
> > > > esthetically pleasing transaction-oriented user interface, the
> > more
> > > > appropriate is VB.  The more OLAP-oriented and analytically
> driven
> > > > need be
> > > > an application, the more appropriate is VFP.

> > >    I agree with both of you. VFP sounds like a better solution. My

> > > opinion is that when working with data that VFP is vastly superior

> > to
> > > VB
> > > but the VB interface is much less clugy and much kore powerful.
> Just
> > a

> > > thought... but I might consider going client/server and throwing
> > your
> > > data into SQL-Server.... it can't be a complete argument without
> > > including this option.

> > > Mitch Hiller

> I stand by my statement. I programmed in nothing but VFP for 2 years,
> am
> microsoft certified. Now I program in Both VFP & VB (although mainly
> VB). There is no doubt about the strengths of VFP... but its interface

> IS kludgy compaired to VB, and buggy compared to VB.

> I agree... both products have their pro's and cons... I simply
> maintain
> the position that VFP's strength is not in its interface abilities...
> it
> lies with its data manipulation abilities. My complaint with VFP from
> the beginning is that they only went half way. They should have
> rewritten FP from the ground up. Instead they kept the base of FP and
> attempted to build windows functionality around it. They made many
> comprimises doing that.

> Mitch

> > Mitch,

> > Your comments are valid, but the comment about the VB interface
> being
> > less kludgy and more more powerful just doesn't hold water. In the
> > hands
> > of a talented VFP programmer vs an equally talented VB programmer, I

> > would wager that you would see scant differences between their two
> > interface capabilities. Both products have their pros and cons even
> at

> > the interface level.

> > While there are aspects of the VB interface that are better than
> VFPs,

> > there are items where it also works the other way around. VB is good

> > for
> > what it is good for, and VFP is good for what is good for. Having
> > worked
> > with VFP and VB, the biggest obstacle is learning to work _with_
> each
> > of
> > these languages, and not try to force a VB approach down the throat
> of

> > VFP app, or vice-versa. If you do that, you _will_ get a "kludgy"
> and
> > "less powerful" interface. Interface-wise, VFP and VB are pretty
> > evenly
> > matched. The difference is almost entirely in the talent of the
> > respective programmers. Now, if you would like to discuss Delphi...

> > -Tom

> > > > > The advantage of VB is that you can work with any type of
> DBMS.
> > > > However,
> > > > > if your applications are going to be based on FoxPro tables in

> > the

> > > > > foreseeable future then I would stay with VFP.

> > > > Paul, thanks for your reply.  I agree with your comments.

> > > > There seems to be an interesting dichotomy between what one
> might
> > > > refer to
> > > > as "database analytics" vs the kind of database programming that

> > is
> > > > seen
> > > > in the majority of VB applications (i.e., transaction-oriented)

> > > > In my mind, database analytics requires capabilities to rapidly
> > > > retrieve
> > > > subsets of data from one or more sources and subsequently
> perform
> > a
> > > > series
> > > > of additional analytical operations where those retrieved
> subsets
> > > are
> > > > related into and compared with several other subsets of data...
> > > > basically
> > > > an iterative process of "drilling down", "splitting off", and
> > > "summing
> > > > up"
> > > > along the way.  Many of the necessary comparisons/relationships
> > > > between
> > > > the data sets cannot be supported by SQL alone, but are well
> > > suported
> > > > by
> > > > the capabilities of the VFP database engine.

> > > > As a rule of thumb, I believe that the more an application needs

> > an
> > > > esthetically pleasing transaction-oriented user interface, the
> > more
> > > > appropriate is VB.  The more OLAP-oriented and analytically
> driven

> > > > need be
> > > > an application, the more appropriate is VFP.

> > >    I agree with both of you. VFP sounds like a better solution. My

> > > opinion is that when working with data that VFP is vastly superior

> > to
> > > VB
> > > but the VB interface is much less clugy and much kore powerful.
> Just
> > a

> > > thought... but I might consider going client/server and throwing
> > your
> > > data into SQL-Server.... it can't be a complete argument without
> > > including this option.

> > > Mitch Hiller

> We all have opinions, and I stand by mine as well. I have hired lots of
> people that profess to have a lot of experience with VFP (and some have
> been MS certified). This has not led me to have a lot of confidence in
> Microsoft's certification process for VFP. In one way, I like it
> because, at the very least, I know that someone has done their homework
> and they know some real stuff about VFP, but in other ways, its the
> difference between taking a written driving test, and getting behind the
> wheel of an actual vehicle. Continuing the analogy, there are a lot of
> drivers who have many years of experience driving, but that certainly
> does not make all (or even most) of them good.