>I think it's a mistake to not have Stored Procs. Look at it this way ... if you code all the SELECT, UPDATE, etc. commands in your DataAccess class, you've just locked into one flavor of SQL. Right in your app. You put it in Stored Procs instead, and you only have to worry about tweaking the procs, not your actual code. Your code shouldn't care one way or the other.

Bonnie,
I'm not against SPs but I don't agree that it's a mistake either:)
If you do that with SPs you're coding it in Data Storage layer, if you do it in your application code then you're doing that in Data Access layer. In other words only changing the layer but still writing vendor specific code (maybe that is because I wasn't lucky to see vendor neutral code in that area ever). One way or the other someone have to write all that stuff. When it's in storage layer, most if not all, validation is done in storage layer. We do the validation in other layers too so validation is duplicated, no? Also if it's in storage layer, than customer really needs the db not my application. How do you handle such case? I have a solution myself but simply doesn't look good to me (marking each SP with a secret key that my application sends, if missing correct key still returns data but not the right one).
Cetin