>>>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. BTW, while there is a DML component of SQL, I would not classify SQL itself as part of the DML of VFP or VB...

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

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