In the past this lock-in was unavoidable, but now persistence standards, particularly Java Data Objects (JDO) deliver the reality of total database independence. Without fear of lock-in or technical compromise, it is inevitable that enterprises will utilise whatever persistence mechanism best suits the job. Process integration does not mean data consolidation.

I will believe it when I see it. Only if you use a lowest-common-denominator subset of SQL can you have vendor independence, and that is too restraining. Some OO systems use the database as a mere file-system of sorts, and they can probably get away with that. But those kind of apps often reinvent a lot of stuff in code that *could* and perhaps should be done by the database.

A better solution for swappability would be to toss SQL for a more programmer-friendly language based on simpler primatives instead of the COBOL-like SQL.

It's interesting that you're proposals for fixing DB programming involve Imperative languages

Where have I said this? (A long time ago we had an argument about such, but I eventually caved in.) The language I propose could be seen as functional or logical. But, could be implemented sequentially for smaller libraries. That is the beauty of it.