>Database independent is a lofty goal, but, IMO, it's not a good one. It means all your SQL has to be very generic and prohibits you from taking advantage of specialized processing, commands, datatypes, etc. You are prohbited from using stored procs and have to do all the SQL statements yourself inside the application.

Good is in the eye of the beholder. Your SQL need not be too generic, if you're willing to maintain separate versions of some SQL statements - that's compared to having to have separate versions of everything on each database. Doing SQL inside the app is much more flexible, IMO, because you can cook the where clause any way you like beforehand, within the same code that uses the results, not in a separate location (i.e. db server). That also means the code isn't as much distributed, so it's all maintained in one place - which is important to me, fewer places to forget :).

Let's not forget that some of the TSQL code can get really ugly, because of the workarounds one has to use for the functions absent in it. Just yesterday I saw a devious kludge which imitated a bitset() function.