Hi Alan,

I do have reasonable knowledge of what is in ADO.NET so it is reasonably safe to say what's in and what is not.

First of all. A database engine has its own permanent storage format. ADO.Net does not.
ADO.NEt relies on a real database engine to gets its data unless you put it in manually (programming), in which case more or less you program is the database. Even worse is its data management. If the recordsets get large, it cannot flush them to a temp file, but instead it eats up your virtual memory.

Second, once the data is in ADO.NET, there are only a few basic database operations you can do with it for datamunging purposes:

Sorting, filtering, summarizing. You also can set a relation, but that is about it. For many operations you can do in VFP with a single SQL Select statement, CALCULATE, SEEK, LOCATE, SCAN, REPLACE (and using SETtings like SET ORDER, SET FILTER, SET NEAR, SET CARRY, ...) etc, you'll most of the time end up with writing algorithms (whether or not using classeS) iterating through collections. The number of DML functions is extremely poor. No SQL support at all.

Third, without relying on a backend database it is not much more than a temporary data storage place.


O.K., I know you don't want to get involved here, but this is all in the papers. You can grab it there. The ones with practical experience will of course say that there is a way arround it, by avoiding to do datamunging on the front - end, but using the backend to do it for them.

Now at this point, there is a great difference between practical and theoretical.
Practically, you would avoid complex data munging at all in .NET. You'll attempt to let the database server take care of it. You'll be attempted to adjust the design of either the application itself or the database structure.

Theoretical there should be no need to do your datamunging on the database server. The database server is what it says a database server: to serve data, NOT to do application tasks. Loading your server with SPs which do complicated application specific datamunging tasks because it is very difficult to do in the client side or middle tier IMO is architectually wrong. Appart from the fact that most database servers are not well equiped to do those mixed set/record oriented tasks, Those tasks really don't belong there. You will risk serious performance problems when loading your server with such resource intensive tasks esspecially when the number of users grow.

It is sad that this problem is not widely recognized (except in some of the ERM/ERP packages). Data munging of data at the least belongs in a middle tier on a different network node, where the middle tier is well equiped and has enough resource to mung the data and pass it to the front-end. Maybe better is to do this on the client as the client generally has enough resources to do this quickly without hurting performance of another user connected to the database.

All this is one reason why the VS.NET team has to improve their data centricness (And they will do, reading messages from KenL and YAG) to handle data better than it does now.

HOWEVER, if you don't do very complicated database task andyou can your data in the required form from the server directly (SPT) and don't have complex requirements for post process this data into other data or information used for displaying in your GUI, reporting, or other out put.
And you don't have to deal with large datasets on the client side.
And don't have a requirement for complex meta data processing etc,

You might be perfectly happy with .NET and ADO.NET though it still requires significant more coding that it would in VFP.

Walter,