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. Thus, 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.