It's not only the datatypes that differ.
Even if you only use MySQL, there have been changes in version upgrades.
For example, UNION and subqueries.
I don't know how a generic interface would handle that.
Exactly.
SQL (ANSI 92 or something like that) is supposed to be a 'standard' that all database engines are supposed to support. I must admit I do not know exactly what this standard defines, nor what the databases support exactly... But what I've heard is that practically NONE of the popular databases implement the full standard. Instead they have diverged to try to force 'vendor lock-in' among other things.
The divergence consists of:
- different levels of support (not all databases support subqueries or 'union' or triggers or stored procedures)
- different names for built in functions/operators (e.g. 'CONCAT' vs '+'; also the various databases apparently have different syntax for 'JOIN' operations)
- different datatypes
By restricting yourself to a small set of datatypes and simple queries then you can go a fair ways. This is how ADODB works I believe. There are a few wrapper functions to take care of major differences and if you use those religiously, you shouldn't have many problems. Of course, by restricting yourself, you often throw away a HUGE opportunity to do any database optimization. (Not sure how relevant this is in typical web apps though - maybe not a big deal.)
I may be blowing this issue out of proportion, not having first hand knowledge of these problems. However, I am on mailing lists for several open source projects, and it frequently occurs that even though some of these projects do use ADODB, people will report problems with MSSQL or ORACLE due to subtle syntax differences even though their abstraction library is supposed to provide 'database independence'.