A few issues I see with this approach. I'm curious as to your opinion on them:

1) It does nothing to prevent SQL injection attacks. I can pass in something like "select * from table ; delete * from table", which would qualify as a select statement, but would execute both the select and the delete statement. Very dangerous and hard to catch.

2) Aren't you losing all the benefits of running stored procs by using sp_executesql? None of the queries are running against pre-compiled sprocs that way, and some queries can be very long and complex (much more than 1000 characters).

Again, I really like the idea of a data access layer (it's been on our development list for a while now). I'm just not sure what the best approach is for it. I prefer to require the client to access all data through stored procedures (we develop a web based app), which makes it hard to develop a generic interface.

Just my $0.02. I'm curious to hear what other people think.

Greg Walker

DBA

ExpenseWatch.com