OLE DB Error Objects

Automation error objects do not support two capabilities required by OLE DB:

• The ability to return multiple error records from a single call.
  
  
• The ability to return provider-specific error information.

For example, each service component, even one in the chain of service components, might want to add its own error information and a provider might want to expose error information that is unique to it.

To solve this problem, OLE DB extends Automation error objects. In particular, it adds the ability for an error object to contain multiple error records. That is, an Automation error object effectively contains a single error record and looks like this:

Automation error object

An OLE DB error object contains multiple error records and looks like this:

OLE DB error object

Support for OLE DB error objects is optional. Providers can choose to generate them from all of their interfaces, from some of their interfaces, or from none of their interfaces. OLE DB error objects can be created by any method call. Although they are most commonly created when the method returns an error or warning, such as the DB_E_ERRORSINCOMMAND code returned by ICommand::Execute or the DB_S_ERRORSOCCURRED code returned by IRowsetUpdate::Update, they can also be returned when the method succeeds completely and returns S_OK or S_FALSE.

OLE DB Providers are not required to generate error objects, even if a method on an interface that supports error objects returns an error. In this case, even though ISupportErrorInfo returns S_OK, calling GetErrorInfo returns a null value. However, the provider is required to clear any existing error objects when any method on an interface that supports error objects is called, whether that method returns an error or not. Thus, the consumer can be assured that, if an error object does exist after calling a method on an interface that supports error objects, that the error object describes the outcome of that method.