>
ADO.Net certainly is NOT a local data engine. At best its an storagelayer between the front and backend.
>

I understand that is your opinion....

>
It does not have its own DML and relies on the backend implementation.
>

So.....

>
Further it is slow and cumbersome in about any comparison to the VFP way of handling data.
>

You were just stating above that ADO .NET is not a data-engine. Yet here - you concede that it has at least some data-handling capabilities. You have just contradicted yourself here. I am sure I will get some nasy-grams by some who say I am splitting hairs - but is it not a semantic point by any means.

Further, you are making an assertion without offering any backup. A dataset holds a collection of tables - which I can iterate through. Also, relations and constraints (domain and entity) can be enforced on the client - ergo - ADO .NET indeed is a local data engine component. Datatables, command objects, etc - are extremely flexible and easy to work with.

>
The only advantage here is that it is an object based architecture that makes data passing through tehe boundaries of comm easier.
>

It is not only not the only advantage - it is a signficant advantage. It is an advantage that was enjoyed by ADO COM as well. FYI - when ADO passes data around - it does so by way of XML - it does all the work behind the scenes.


>
There is no way you describe some outgrown middleware thing like ADO.net as a dataengine...
>

I just did....

< JVP >