Mark,

I know "jack" about the JET engine, but want to say some things anyway. . .

By "politically correct" I suppose that you mean that VFP is only rarely seem *anywhere* whereas Access is *EVERYWHERE*.

It may also be related to the "problem" that the iminent demise of VFP has been prognosticated by a few for a very long time now (but, I remind you, nowhere near as long as the demise of COBOL has been predicted).

As for the rumour-mongering, surely by now most of us can see that it is only and exactly that - a rumour of the first order! There is not one shred of evidence to support any such conclusion. Some nervous nellies associate lack of advertising with proof of demise. That's a poor yardstick to use for such a major conclusion!

As for the visibility of ACCESS vs VFP, that *IS* a problem, BUT only in the way that one sees more Chevys than one sees Mercedes'. Should we all run out and buy Chevies because EVERYONE seems to be driving them???
For years VFP has had NO PEER when it comes to data manipulation SPEED and FLEXIBILITY. Yes, it is decidedly *not* EASY to learn/use, but once you have "paid the price" (gone through the learning curve) it is *THE BEST*.

VFP also has much much larger CAPACITIES than ACCESS, and this matters in countless applications.

I suppose that I am "preaching to the converted" but I *DO* think its worth raising these kinds of issues with the decision-maker who wants to be "politically correct".

Probably the most succinct answer I could offer is "since VFP is the best tool for this job, it *IS* THE POLITICALLY CORRECT choice!

good luck,
Jim N

>Sorry for the length of this posting, but if you are familiar with both VFP and Jet 3.5, I really could use your help.
>
>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. Rather than dealing with the needs
>imposed on a typical client-server transaction-processing application, our applications instead demand very fast, complex, multi-table analytical operations in which VFP seems to really excel.
>
>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 being "politically correct" in the marketplace... and they don't have the technical expertise to understand, when considering our products' requirements, that VFP is probably the best and perhaps only way to get there.
>
>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, how does Jet 3.5 stack up? 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.
>
>By the way, I know that when compared to earlier versions of Jet, there was no comparison... Jet simply sucked when matched against VFP. Also, from what I've read, it seems that Jet imposes some show-stopping obstacles when it comes to supporting read/write cursors derived from SQL pass-through queries and the like.
>
>For example, in VFP it's very simple and extremely fast to do a couple of queries, then create an index on each 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!), and one can even make the cursors read-write by exercising a USE AGAIN command on the cursors. One can then "walk the indices" of these two (or more) "related" cursors and do all kinds of wonderful analytics, manipulations, and lookups nearly instantaneously. Then, with only one 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 needs.
>
>Can Jet 3.5 support these kinds of operations, and do it really fast?
>
>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
>msf@satexas.com