Related Entries

Oracle with C#
Slashdot: Java vs .Net
Variable number of function arguments in C#
C# day 3
Mozilla intentionally breaks ASP.Net pages?

« JDeveloper 10g on Linux
» Semi-connected computing

Is ADO.Net portable?

Wondering why common database functions are named differently in different .Net providers.

One thing I noticed when I used Oracle provider for .Net from Microsoft is that all Oracle specific methods are named like Oracle*. Eg: OracleConnection, OracleReader, OracleException. Wouldn’t this mean that I will have to change my code if I switch from Oracle --a fat chance-- to SQL Server?

Similarly, FireBird dataprovider’s connection method is called FbConnection.

Compared to this, JDBC (and Python DB-API) is far better. As long as I stick to SQL '92 standards, I don’t have to change any code. Simply specify the driver and connection string in a properties file (example). Change the properties file as needed, instead of re-writing code and re-compiling.

One could argue that vendors simply chose to use their own function names. Or may be this is simply following Microsoft coding standards like intMyVariable :-) If namespaces are there to prevent such conflicts, why use another level of distinction?

Whatever the reason maybe, I don’t like this.

Bookmarks to remember: ADO Connection String Samples and ConnectionStrings.com.

Posted: September 23, 2003 06:27 AM
dotnet

  1. If you use the ODBC layer only (OdbcConnection, OdbcCommand, etc.), the .NET code should port fairly easily between various databases.

    Posted by: Sanjay on September 24, 2003 01:28 AM

  2. The same works if you use the OleDB layer. Most of the current database engines offer you an OleDB driver as well. The drawback is that the OleDB and ODBC is a bit slower than the native drivers.

    I wonder how hard it would be to write a wrapper around the native functions that give you an easy option of switching between the different database engines, much like the ADOdb library for PHP does.

    The one thing I do miss in .NET, and why I still prefer Java for database connectivity is the ease of use of the type 4 JDBC drivers. You only need 1 file, and you have complete database connectivity. No hassle of installing client software (if you ever installed the Oracle client software, you'll know what I mean). No problems if you want to use different versions in parralel.

    Just my 2 cents of course...

    Posted by: Pieter Claerhout on September 26, 2003 01:40 AM
//-->