So at last, I bring myself to write this so to try a bit to begin with the beginning.
We all know that around are many different database vendors, but when we think at databases we think at SQL. Which means Structured Query Language, which is also ISO and ANSI standardized.
In addition, .Net has a provider model that, at least on theory, forces you to use a pattern and an interface implementation in accessing the database. In plain english this means that all providers should expose same methods (implement the same interface), and behave consistently similar. Sounds a bit like the ODBC times for .Net.
Therefore, if you do not know better, you suppose that is fairly easy to change at runtime the database used, and that all will work fine.
Well, surprise, noooo! 
And hearing ISO and interoperability in some sentence and getting none (interoperability) is a bit ironic after all the bitter fights on document standards, and I really hope that this text will have some relevance after they are all but forgotten.
In this series or articles, I will try to share a bit from my experience in this field (nobody told me that it cannot be done so I've tried my hand at it…), present the problems, how to work around them, and what the future may hold for us (and if it help us or not). Also I will try to give you resources on dealing with these problems, resources that some could prove useful even if you just want to target one database and you do not know where to start (for that particular database).
And be warned some of the stuff will be a bit controversial.
In addition, I'm not touching the code generators for database abstraction layers (DAL), I do believe that you can have a piece of code that could work on any database (better said on reasonable number of them) without rebuilding the application and with decent performance. Of course that are instances in which other options could be better.