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

I am not talking about traditional bus objects here. To be honest, creating cursors for 1 to a handful of people, "feels" sometimes like overkill as well in restaurant / barbershop apps. But fox shines with cursors and if you have to produce a non modal app with the opportunity to start many forms, this approach is "more scalable for self-perceived power users of the app" <g> in fox. So that is the way I do it in fox, even if the .Net approach "feels appropriate" for the problem size.

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

Doing what-if scenarios against production data ? That work should be done on a work station, and the end results should go into the production server.

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

Correct. You might need to adjust your best practices ("how do I design / deploy lookup tables the most efficient way"), but you are working in different frameworks. You will "win" if you use the strengths of each framework - and I am not disputing that .net has some very nice features ("watering mouth" would be a better description). Using SP's like you advocate has technical merits as well, but locks you a bit to that database vendor. If there is no technical "must" (performance, security) I prefer to work not on this tier - but that is only a preference.

The not "pure OOP" use of containership, the ease of eval() and ¯os, the possibility to datamunge your sources are also vfp niceties I've grown to like.

But having a dataengine always at my command (weak pun, I know) is at the moment besides personal inertia the reason I do most internal stuff with vfp. Some things I try out in .net, just to be able to respond intelligently if asked. Makes "business sense" for me as well, even if the task takes longer.

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

If every WS had SQL server installed locally that's the way I would jump.
But if I am called to a site where no vfp is installed, no laptop is allowed, it is always easier to do a xcopy temporary install of vfp from my "don't leave home without it" cd, which gets deleted when I leave.

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

Yup. But I am not betting on that as a feature of europa.

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

Yup as well. Rick's points about deploying MSDE are a part of my grumblings also. Working with "disconnected data" sometimes means that you have to remote a lot of records (think of insurance salesmen visiting their customers with laptops) from the network connected office processing. There you need a local data engine like MSDE or VFP via OLEDB to extract your bus objects out of the disconnected "personal" subset.

I still believe a "local data engine" makes sense in quite a few scenarios. If .Net consuming dbf's directly would mean reading the headers / field types at compile time to insure type safety (and erroring out if fed a bad .dbf at app-runtime) - ok by me, even if it is "not the fox way". Think of it as a "not-forward-only-datareader (with write capabilities)", where you access one row in a type safe way. But I also won't bet on this to happen <g>.

my 0.02 EUR

thomas