Hi John,
>Sounds a lot easier than
>

select * from MyLargeResultset into cursor MyNewLargeResultset readwrite
>index on mytag tag mytag
>

Maybe it is too easy <g>.

I also heavily use foxpro's agressive caching and automatic data/memory overlay in my current main job - datamining and adhoc queries on GB sized tables generated from an OOP based "framework" encapsulating often used scenarios. Coupled with the turnaround of the interpreter a combination hard to beat for that task, even if I sometimes have to restructure because of the 2 GB barrier.

But for more traditional application development I am starting to see in .Net a vision probably superior to vfp. In vfp the ease and speed of the cursor make it the swiss army knife. Granted, it is sooo tempting to open a cursor for a single combo which has a few fields needed for validation and/or business reasons in other columns - but neither resource friendly or multi-tier best practice. The fact that cursor handling speed in some situations (even excluding index searches !) is superior to array handling is IMHO more a showing a weakness on the implementation of memory arrays compared to fantastic table handling - even in a C fll you get real sped only if you use C arrays instead of vfp memory variables.

The inertia keeping the 5 record / 6 column cursor alive in most vfp apps is the effort it would take to switch to a more fitting implementation - and I see LINQ as targeted in the direction to enable you to switch your program internal data stores the same way we can switch database backends. My biggest beef with ADO.NET was that I could not query it the same way as the backend (idiotic from developer skills *and* maintaninance POV), which we can with vfp's cursors and SQL - but this is adressed as well, even if the syntax looks weird to us. We get a programmers interface into data structures from SQL server over collections and hash tables down to OS internal structures - great idea. Large local masses of data - as important as they are to most of us - should be a special case, and otherwise more fitting structures should be used. And yes, I agree the perf of that special case has to be adressed to make the great vision more palatable<g>.

Is all the above an attempt to enhance windows sales via easing developers tasks - I'ld bet on it. Will it be worth to be part of a less backward compatible tool set and also again kept inside the MS umbrella ? The tools are top notch, but here in germany dependency on MS OS is becoming a "political" burden. Not a large burden as of now, but the problems selling fox based apps were nearly non-existant in the early nineties as well. Time will tell - and I will continue to use the fox for the tasks it is taylor made for.

my 0.03 EUR (a bit more, as it is a long post for me <g>)

thomas