>
I guess you mean "development language"-neutral rather than database neutral. If you thought database neutrality was important you'd be more of a fan of Remove Views ;-)
>

It is the UI that should be db agnostic. In order to harness the full potential and scaleability of a database, one needs to use db-specific features. For example, Oracle has something known as context indexes. Definitely important if you need unicode (and I mean real unicode support).

If you use RV's, then the back-end is only a repository. For that, you might as well just use mysql...< s >...



>
IMHO the Fox example could be read by a Java, ASP.NET or VB.NET developer and replicated with ease, minus the TEXTMERGE bit. That would be true of most cases where SQL is built for SPT IMHO.
>

And if it is encapsulated in a stored proc, then any client - without modification - can invoke its services....


>
You are fortunate that your recent development work allowed you to focus exclusively on Oracle. Others have customers with existing investment in SQL Server, Oracle of various vintages, Sybase, Cache... we cannot afford to rely on Oracle-specific processes to service all these customers. I guess that is the price of database-neutrality which is surely as relevant as language-neutrality.
>

If you choose to program to the lowest common denominator, then your apps - from a db standpoint - likely perform at a level far below their potential.

Having stored procs - with common interfaces - written for each rdbms is not that big of a deal. When you do that, you can capitalize on things sql server does well and you can capitalize on what oracle does well. If you rely on common vanilla sql, then you are simply using the backend as a data repository - which is OK. That however, is not the stuff that the best performing/most scaleable apps are made of....