This article explains what are the issues or options we have if we use generic data objects such as IDbcommand, Idbconnection etc in place of specific data objects such as SqlCommand or SqlConnection.

ADO.NET is designed wrapper a set of generic interface that abstract the internal data processing functionality. The main advantages of generic data providers is you can abstract the data access layer so that you can minimize the impact of changes of data source I mean the same code will work with different database server. The core interfaces are IDbConnection, IDBCommand, IDataReader and lot many. The specific data objects like SqlCommand or OleDbConnection implement these generic data access interface. One should keep some of the basic differences in mind as mention below while programming with generic interfaces.

1. There is some small cost associated with a virtual call made through an generic interface.
   
   
2. You can not leverage certain expanded functionality when you use the generic interfaces like ExecuteXmlReader method is implemented by the SqlCommand object but not by the IDbCommand interface.
   
   
3. You do not have generic base exception type, so you must catch provider-specific exception types, such as SqlException, OleDbException or OdbcException.
   
   
4. When you use the generic interfaces, you cannot take advantage of database-specific types that are defined for the managed providers for example you cannot take advantage of SqlDbType in SqlClient and Oracle-specific types in the Oracle provider. Using specific database types is helpful for type checking and parameter binding.

NOTE: THIS ARTICLE IS CONVERTED FROM C# TO VB.NET USING A CONVERSION TOOL. ORIGINAL ARTICLE CAN BE FOUND ON C# CORNER (WWW.C-SHARPCORNER.COM).