Database independent ADO.NET
One of the main complains about ADO.NET it's that you cannot write code that is database independent.
There are a number of libraries to accomplish it, and the latest DAAB version also supports it.
I think the designers of ADO.NET acknowledged something that we don't want to: each database engine is different, we will write different SQL code, and we will need different APIs.
The most visible difference is parameter markers. SQL Server native ones are prefixed with '@'. In OleDB we used '?' which required the SQL driver to parse the sentence and change them to '@'. In .NET all the Data Providers use their native parameter markers, so you have ':' for Oracle, '@' for SQLServer/Access, etc.
This implies that is very difficult to write a parameterized SQL sentence that can be database independent. 'SELECT * FROM CUSTOMER WHERE CustomerId = @CustomerId' won't work in Microsoft's Oracle Data Provider even if we are using the generic IDb APIs.
Even if ADO.NET provided a generic API and even if it supported the same parameter markers in each Data Provider, we all know the SQL sentences are different in each database engine. Doing a SELECT * FROM CUSTOMER always works, but when you need to deal with autonumbering, database-specific types (think uniqueidentifier in SQL Server), outer joins, then it's not possible to use the same SQL sentences.
Suppose you _can_ write generic SQL, because you have simple SQL statements that are supported in all the databases you need, or the places where you need different statements are not many.
Then you code:
IDataReader reader = myAbstractCommand.ExecuteReader(“SELECT CustomerID FROM CUSTOMER);
while (reader.Read()) short customerId = reader.GetInt16(0);
And then you run Anakrino, open the OracleDataReader class, and find:
public virtual short GetInt16(int i) {
throw ADP.NotSupported();
}
...
Writing database independent code is a dream. Let's wake up.