>>Like I said, I can understand WHY it has to be this way, but I do feel cheated having being made available to some brilliant DB commands in fox, only to have to be brought back down to reality with a different product.
>
>Kevin,
>
>VFP has a native database engine, VB does not. Simple as that. So it's not truly an apples-to-apples comparison.
>
>Just out of curiosity, have you tried the same operations in VB.NET using the ODBC driver instead of the VFP OLEDB provider? It might perform quicker.
>
>Laterness,
>Jon

Jon;

I guess I am being a bit argumentative but do not mean to be.

I think there is a direct relationship you could make between Visual FoxPro and VB.NET, when they are being used to create data based applications, which is what the topic is. In that case we realize as Kevin pointed out there is so much code to write (ADO.NET is “interesting”) and then we have the speed comparison issue of course.

As you pointed out the two products are different but again they are being used for the same purpose. With VB 6.0 and ADO I used SHAPE to create relationships between tables and ADO.NET makes things of that nature easier but still the amount of code necessary to use data and the amount of time to write it is measurable and seems a step backwards compared to VFP.

At a recent class I attended we spent one week working with ASP.NET. To get data from one form to another took not only work but requires a modeling tool for complex applications to remember what data came from what form to populate an object. It was very interesting and requires a good deal of thought and planning as well as organization to work in that manner.

Tom