>Hi Bill,
>
>when I first got serious about SQL Server, I think sometime around 1998, I picked up what looked like the best books on the topic. And what they said was very clear: don't put everything in SP's on the server, as you will limit scalability. Thus I was taken aback when the .Net data handling was suggested to be in SP's (well, in V.1 it had to be, practically speaking). Had they not read the people I had read, who were supposedly the best in the industry?
>
>And then, just this last year, I read that the new recommendation in .Net is not to put all your data manipulation in SP's, because it will limit scalability. It sounds like the chickens came home to roost.
>
>Now, doing your CRUD and triggers on the client does NOT mean pulling all the data local. It means doing munging on the client with just those records that are needed, and then sending updates to the server. BTW: SQL Server creates a plan just as well for SQL selects and updates etc. sent from the client as it does for SP's: it's all based on the signature.
>
>And then, as JR notes, there is Oracle. And all the others.

And there are developers who do Oracle projects.

I do SQL Server. I do it very well. No lack of projects.

I deal with data on the server unless there is a pressing need not too (or it is something extremely simple and quick). I find no reason to use network bandwidth unnecessarily or slow things down on a machine that is not optimized for data.

>
>Just my $.02. Which actually used to buy 2 pieces of penny candy when I was a kid. <s>
>
>Hank
>
>>>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).