John,

>>>>In VFP you have numerous commands regarding data manipulation like native SQL support. Within VFP controls can be bound to the data directly. In general it easier to work with data within VFP than in VB using whatever data-engine.
>>>>
>>>In VB, you can bind controls to data, via ADO. I can use native SQL in VB.
>>
>>Does VB has SQL commands natively ?
>
>Natively, no, who cares...it is semantics... I can do it through ADO, or another data-access mechanism of my choosing.

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.

Within VFP these issues are not likely to occur.

>BTW, while there is a DML component of SQL, I would not classify SQL itself as part of the DML of VFP or VB...

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).

>>I don't know much of data accessing within VB, right, but I do know that there are/where several technologies wich didn't give me the impression that VB is suitable for data intensive programs. What if want to upgrade my program and they invented yet another technology which is faster or better. Do I have to rewrite my program all over again ? I'm glad I stayed with one of the most stable and fastest database engines around without having to worry about that one.
>>
>
>The first sentence pretty much sums of the credibility of your argument... That said, many VB developers HAVE NOT migrated to ADO. Rather, they have stuck with DAO/RDO. So, if you don't wish to take advantage of the new stuff, you don't have to...

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

>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,