>Another more important problem for me is the question about how much processing do you offload onto the database server. If you do most of your data manipulation in T-SQL, it tends to put a lot of processing on the server itself, rather than dividing it between different layers.
>
>To me, writing your own data access class is unnecessary given the various frameworks out there that have done this already and much better than I could do given the cost of a good framework vs. my lost "opportunity cost" spent chiseling my own wheel out of stone. But that's just my preference. BTW, Hank Fay found an interesting tool for .NET datamunging, including local cursors a la Fox (http://www.queryadataset.com.) It picks up where ADO.NET leaves off. Most interesting...
>
>

Now that is the kind of thinking I agree with the most. I use a framework (MM) that already has all the data access done for me and I can concentrate on solving the business process I was hired to do. I do however use different backends even within the same application. Just the other day I needed to create an export tool within the application to move data from one backend to another. It was so easy it surprised even me. I wrote code in the base class that was essentially changing the data access class name and now I can retrieve data from one backend, switch the name of the Data access class and then save it back in.
Tim