imho you need some database layer abstraction, at least you certainly don't want to sprinkle your code with SQL strings all over.-f0dder
Of course I want a (one, singular) data abstraction layer. But I don't know why I would want a second one so that I'd have the opportunity (say) rephrase all of my stored proc calls to work through Oracle.
-CWuestefeld
My database needs have always been pretty simple, so I've never worked with stored procedures - syntax of those are probably different from db to db, but invoking them pretty similar?
I don't think so. I know the target is SQL Server, and I have another SQL Server available to me for development; why in the world would I want to develop against something different, and risk getting to production only discover we'd made a mistake?
-CWuestefeld
Obviously depends on what you're doing - for a big and complex project, it's not feasible switching to a different db provider (banking software, anyone?

), for smaller systems it can be nice being able to demo features on a laptop that doesn't have a network connection.
Supporting multiple database backends is, again, probably not something you want for complex systems, but for simpler stuff (web community, blog, simple shopping system, and things of similar scale) it's nice enough if you can just plug it into whatever's available.
BTW, I definitely don't want SQL strings all over. In fact, my rule is NO SQL strings anywhere -- everything goes through a stored proc (although I haven't quite figured out how to square this with LINQ, if indeed I decide to use it).
-CWuestefeld
Haven't tried using LINQ, but the snippets I've seen look pretty nice compared to spaghetti SQL strings... good enough that I probably wouldn't mind using it. And I guess it's a bit more portable than stored procedures?

But I guess stored procedures are run on the db server, and can thus have some efficiency benefits compared to pulling data out of the db and processing client-side...