None of this is "news" ... it's simply an extension of DAO and "old" ADO.

For that matter, VFP cursors and views are handled in "memory" until they get "too big"; then VFP starts creating tempory datasets.

As some point, ADO.NET will also create "tempory datasets" ... even if only in the form of virtual memory; in either case, it means going to local disk.

And as with VFP, you should think hard before you start dragging "thousands of records" down the wire.

>Hi
>While I agree that a ADO.NET data set can represent an IN MEMORY database and we can add,edit records, relations and so, all these are IN MEMORY? What about local physical storage? What about handling thousands of rows? We need to save the dataset data to a local XML and load it again?
>I dare to say that, if we can say that ADO.NET has a "data engine", we cannot say that has a "database engine"
>Anyway, Codebase is available for .NET with properties and methods that can be used for local database acces (DBFs). It can be integrated and compiled to managed code (at least this is what they say).
>
>
>
>>>I understand "XML" to be just string information that happens to have a standard 'format'.
>>>Am I correct that XML (strings) can be 'decoded' by VFP (XMLTOCURSOR()) without the need/benefit of an "engine" and 'encoded' (CURSORTOXML()) similarly?
>>
>>Yes ... no (proprietary) "engine" required; just some "parsing" functions. The SOAP SDK contains "tools" to help manage XML. There are also Active-X controls available to display XML in tree views (similar to the standard Tree View control).
>>
>>>Then .NET essentially does those simple things AND MORE (e.g. relations, adding records, updating records, deleting records) and the thing(s) that do that is/are called "the engine"? ...So there exist databases with tables that are filled with XML 'strings' (describing/being the data) and this/these "engine" take care of all this stuff in them?
>>
>>That about sums it up: XML's self-describing and hierarchical nature lends itself to "database" definition.
>>
>>The term "engine" is not used in .NET; there simply exists a set of classes (dataset and data adaptor "objects" ... that have almost identical counterparts in Delphi) that are used to make connections to physical databases (via the data adaptors) and then create local "schemas" via "datasets". These datasets (similar to VFP "buffered" tables) have properties and methods that the can be used to perform table operations (which may subsequently be committed).
>>
>>As an example, a .NET grid is bound to a "dataset". This dataset is "disconnected"; it only exists in memory. A "data adaptor" would typically have been used to populate the dataset from a physical data source (which could have been a VFP data source). Internally, the dataset's data is represented as XML. A .NET dataset is like a VFP cursor, although the VFP cursor "looks" like a DBF (vs XML). The fact that a dataset uses XML really makes no difference to the "programmer" since one uses the properties and methods of the dataset "object" to access the data it represents.
>>
>>As per MSDN:
>>
>>An ADO.NET DataSet object is like an in-memory database. This object holds a collection of DataTable objects. Each DataTable object is a representation of the data that was retrieved via a SELECT statement or stored procedure execution. The data in a DataSet can be written out or read in as XML. DataSets also store schema information, constraints, and relationships between multiple DataTable objects. Through a DataSet you can add, edit, and delete data.