>They did data manipulation on the back-end server. VFP devs want to do it all local, like they always had before.
>
>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.

I still don't see the reasoning behind pulling data to a local machine to manipulate it rather than doing it on the database server (anyone hear the can of worms opening?). I guess it's because I've been doing just that with VFP for so long.

Generally all I worry about in my application is my SQLDataSource configuration (stored proc calls and parameters) and what types of controls I want to use (bound or not). Layout takes more time than anything else (in ASP.NET).