John,

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

Something that does not have its own DML is by definition not a database engine. Tell me the LOCAL (thus not sending the SQL statement to the backend) ADO implementation of:

UPDATE Orderlines SET TotalPrice = Price * Quantity * m.VatPerc WHERE TotalPrice AND ItemNo IN (SELECT ItemNo FROM Items WHERE Pricechanged = .T.)

or

REPLACE TotalPrice WITH TotalPrice = Price * Quantity * m.VatPerc FOR artnr = "BIKE"

You can't do this without the language specific methods of using the methods and properties in the object model. ADO itself does not provide you with anything to do this. IOW ADO does not have a DML in itself.

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

ADO.NET is little more that a storage layer, with some properties and methods to obtain and write the data from/to a remote source (either via ODBC or OLEDB). This category of software falls in the range of middleware. The statement above is saying: Handling data trough ADO.NET is slow and cumbersome. Note the word "Hanlding". The statement does not imply that ADO.NET is a local database engine, because it's not. Yes I think you're trying to read something that is not there.

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

ADO.NET might have some properties and methods of filling in, copying, filtering and some limiting ways of computing data out of collections but the capabilities to do datamunging operations like joining (not to be confused with relating), seeking, use of indexes, DML operations like REPLACE ALL, UPDATE, DELETE ALL are not present, or very limited. The operations like filtering and COMPUTE are sorry a piece of method to do what should be possible in the first place: A FULL SUPPORT FOR A SQL DML ON THE LOCAL DATASETS. ADO.NET is object based and its implementation is far from relational. If you're spoiled with VFP DML set with its SQL and xBase implementation, you're truly lost in ADO because it does not have a thing that qualify as DML. You've got to solve it by iterating through the collections to get what you need. The underlying problem is the OO based solution of handling data in the first place. Data should be handled relational, not object based.


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

Server:

CURSORTOXML(....)
RETURN cCursor

Client:

cCursor = oServer.GetData(..)
XMLTOCURSOR(...)

I agree that it would be nice if the VFP team could make it more transparent in VFP, but it is certainly workable.


Walter,