OLE DB Error Objects and Threads

Like Automation error objects, OLE DB error objects use the Automation DLL to maintain one error object per thread. Because the consumer is not required to retrieve the error object, the Automation DLL might be holding the error object generated by the previous method when a new method is called. Therefore, providers that return error objects must call the SetErrorInfo function with a null pointer at the start of each method in an interface that can generate error objects. This clears the current error object on the thread and ensures that any error object available after the method returns applies to the current method.

Because providers at each level must clear the current error object, providers should be careful not to transfer ownership of an error object to the Automation DLL and then call a method in a lower-level provider. Doing so might result in the lower-level provider clearing the just-created error object from the thread and losing the information it contains. To prevent this problem, the provider should first call local methods and then post its error object.

The system error information set and retrieved by calling the Automation SetErrorInfo and GetErrorInfo functions is defined to be thread-specific. During an asynchronous operation, in which the error condition occurs on a background thread, the consumer must call GetErrorInfo inside its IDBAsynchNotify::OnProgress(COMPLETE) implementation in order to be assured that it receives the correct error object.