>Here I find another issue wich bothers me: It probably depends on which mechanism you use of which SQL commands are supported. As you'd probably know the SQL standard is very complex. Therefore it would not surprise me that there are significant differences between the data-access mechanisms regarding SQL support, which could be a problem when upgrading and maintaining your app.
>

I am not sure where the big complexity is?? You have a DDL, DML, and a DCL. I find if you remain ANSI 92 compliant, you are in pretty good shape.

>Within VFP these issues are not likely to occur.

Once again, if you are generic, the data engine you use should not be THAT much of a concern. Of course, in the real world, it is never as simple as swapping out one back end for another... There are always bumps in the road...

>You're right in VB it isn't because it isn't supported natively. Within VFP it is. I tend to use SQL in VFP very much. Remember that SQL views are build out of SQL commands, so it *IS* part of the VFP DML, as it already was in FPD 2.0 (maybe earlier).
>
One point that I do stand correction on. The DML does over Updates, Inserts, Deletes, as well as Queries..... However, I think you are placing way to much importance of native functionality. If you are that much of a native functionality purist, you should not use ActiveX controls...

Fine, how about this. Since VB has a Data Environment now, THAT NATIVELY SUPPORTS ADO, could we not then say that VB NATIVELY SUPPORTS DATA ACCESS VIA ADO???? Yes, I think we can.....

Thanks Walter for clearing that up...


>This pretty much sums up my objection to those external data-access mechanisms.

So you don't ever use ODBC - where the full VFP language is not at your disposal. You don't use SQL Server. That is after all, an external data mechanism....

>>Also, be careful about preaching the speed thing. Lets get a few million rows of data in a WAN environment. You use a DBF. I'll use SQL. We'll see which one is faster and easier to work with... DBF's have thier place. However, don't sell the performance issues as something that DBF's alone have. That simply is not the case.......
>
>If you read carefully, i did say one of the . And for your test, it still depends on the situation, The resultset of your SQL query still has to go trough the WAN, whereas VFP is able to cache data (on OS level) wich gan give VFP a boost, Especially when index data is cached.
>

Walter, try and open a multi-million record DBF on a WAN.... It is not as intantaneous as you think.. As for SQL, only the result set comes back. And, if I want, I can operate asyncronsously... You really don't want to take me on here... But if you must, please do....Also, this thing you allude to VFP caching data on the OS level. Could you go into that further. Do you mean the client or the server??

And, FWIW, SQL Server can cache data as well. However, those caches are on the server.... Once again, you really don't want to take me on here....