>Gino, to emphasize a point in the the previous replies: From the information included in your post, it sounds like you have not used VFP's database engine at all, but rather have measured the Jet ISAM driver's speed at processing a Foxpro table and compared that to Jet's speed at reading an MDB.
>
>I can promise you this: If you compare the speed and flexibility of VFP's database engine (using its native tables) with Jet (using its native tables), Jet won't come close, especially when you go above, say, 200K records.

I have gone well above 200K records, and found that the TOTAL time to return ALL the records from the query was much faster in VFP. Unfortunately (or fortunately), none of my clients have ever asked to view 200K records at one time. For this reason, a buffered view of the data is sufficient. While VFP has something similar through Views, use is still somewhat sketchy, filled with work-arounds and complications. I have been working VFP exclusively now for 2 years, and have spend an excessive amount of effort working around limitations in the product.

VB makes development so much quicker and easier, it comes down to this: the clients can either wait a month longer for their product to be produced, or a few seconds longer for their query results.

>
>Here is a reply on this topic from a company that specializes in both VB and VFP C/S solutions.
>
>> There is no comparison between the access speeds of VFP and VB. VFP is
>lightyears faster on every operation, even with largest data sets and VB using
>the fastest RDO statements. The only reason we program in VB/ODBC is because
>some of our clients are a little uncomfortable with VFP and prefer a more
>"mainstream" solution such as VB/SQL-Server.
>>
>>(name omitted)
>> Senior Software Engineer
>> VisualSoft, Inc.

This was clearly a loaded statement. The speed of VFP may be lightyears (which BTW is a measure of distance, not time) faster on queries, but load time, development time, and interface response time is _visibly_ much slower.