>I haven't done any serious work in .net yet. I am aware of the basic object structure of the data access through the adapters into the datasets, and that you can access there not just the "actual" row but any row through the object model. What I haven't found yet is a way to do workstation work / set based handling of the the data in the dataset. I am talking about subsets of 100 to 10000 rows. Writing into a local instance of MSDE/SQL Server to massage those seems inelegant, any pointers how to best handle this ?

Well, you can do anything with a dataset, that you can with a VFP cursor (except index it, not sure about that). But, what would is the advantage to processing the data on the client or in the business layer? Write your data access code so it gets the data from the data store in the format you need it. If you need to process a large set of data, let SQL Server do it. That is what the database server is for.

I think you are not seprrating the 'requierment' of doing something with the 'implementation' of doing it. In VFP you do it the VFP way, in .Net you don't, you do it the .Net way. Does that make .Net bad at doing it? I don't think so.

So, if you can't show me a reason to bring those 100 or 10,000 records out of the database and across the wire to 'process' them, then I would recommend you do it in the SQL Server.

The only question comes, well, what if I don't have a sql server. Well, even VFP lets you create stored procedures that you can call. Technically the are being processed on the client anyway, but that is the nature of a file server based data store like VFP data. If you don't want to do that, populate a dataset with the 10,000 records and process then in a nice object oriented way, and write the changes back out. It's is certainly doable.

>Seems ludicrous, that MS cannot (technically ?<g>) do the same for VFP tables. Workstation work sometimes nowadays needs these data sizes, and

I'd love to see the next version of VFP expand the capacity of DBF files. Of course, that's another thread.

>since it is not "production data" with security and backup needs, SQL server seems like overkill. 2 GB was sufficent in the times where the disk

SQL Server is very scalable. There is no reason you can't use it for a system that will never have more than 10 megs of data if you want. Once again, a topic for a different thread.

BOb