Object Oriented Dilemma

Working on the abstract Data Access Layer has forced me to explore the object oriented capabilities of VB.NET.

The purpose of the the abstract DAL project is to allow DotNetNuke to run on any SQL compliant database. To achieve this goal I am following a Provider design pattern where the application defines a base class for data access operations. Based on this base class, unlimited derived classes can be built to provide the actual data access implementation. A couple object oriented techniques satisfy this requirement: Interfaces and Abstract Classes.

Abstract classes are closely related to interfaces. They are classes that cannot be instantiated, and are frequently either partially implemented, or not at all implemented. One key difference between abstract classes and interfaces is that a class may implement an unlimited number of interfaces, but may inherit from only one abstract (or any other kind of) class. A class that is derived from an abstract class may still implement interfaces. Abstract classes are useful when creating components because they allow you specify an invariant level of functionality in some methods, but leave the implementation of other methods until a specific implementation of that class is needed. They also version well, because if additional functionality is needed in derived classes, it can be added to the base class without breaking code.

So it sounds like abstract classes are the best option. Or does it?