I haven't met a developer who works that way in years. Most VFP developers I've worked with have been working with result sets from sqlserver in the form of a cursor(s) for years. Those cursors are basically no different than the result set in .net basically (especially given linq's abilities for sub queries and query in memory). I guess I've been lucky.


>I haven't had time to look much at VS2010, but I agree.
>
>One other thing I've thought of regarding VFP devs moving to .NET. Even today, many devs think in terms of having the entire table available. SEEK, LOCATE, etc are used. They should be thinking in sets of data.
>
>>Not disagreeing, but MS's newer stuff seems to be moving away from the "SP is best" mantra more towards local manipulation. Makes sense- most of us have more RAM than the biggest cursor VFP ever allowed, so memory-resident data collections aren't such a negative any more. Unless it's stored as XML, in which case still it can bring a machine to its knees. ;-) But MS has new lightweight mechanisms to handle that too. Not auto span-to-disk but equivalent if it allows any feasible persistent local collection on which you can munge furiously.
>>
>>Until 2010 I'd have said there's a chasm between "different" and "equivalent." VFP people who always used backend for everything made an easy jump to NET even prior to typed datasets and couldn't see the fuss. People who like using the local PC rather than leaving it to a database server saw a huge lack of "equivalence". Well, the gap is narrowing IMHO. MS said it would 5 years ago and it's proving to be true. Shame we weren't at this position before VFP got Foxed, but c'est la vie.