Limitations of Storage Objects

Storage objects are subject to the following limitations. Whether these limitations always exist is provider-specific.

• Number of storage objects—Some providers can support only one open storage object at a time, while others can support multiple open storage objects. If the provider supports only one open storage object at a time, any method that attempts to open a second storage object returns a status of DBSTATUS_E_CANTCREATE for the column or parameter, whether or not the objects are constructed over the same column, over different columns in the same row, or over different rows. A consumer determines whether a provider supports one or many storage objects by calling IDBProperties::GetProperties for the DBPROP_MULTIPLESTORAGEOBJECTS property.
• Exclusionary behavior of storage objects—Because of the way storage objects are implemented by some providers, using a storage object might prevent the use of other methods on the rowset. That is, after a storage object is created and before it is released, methods other than those on the storage object might return E_UNEXPECTED. By calling IDBProperties::GetProperties in the DBPROP_BLOCKINGSTORAGEOBJECTS property, a consumer determines whether storage objects might prevent the use of other methods.
• Length of storage object must be known—Some providers need to know the number of bytes of BLOB data that will be sent before any of the data is sent. This is usually related to a similar requirement in the underlying DBMS. For more information, see "Getting and Setting BLOB Data with Storage Objects," later in this chapter.
• Type conversions and storage objects—A storage object is essentially a stream of uninterrupted bytes. When getting or setting rowset or parameter data of type DBTYPE_IUNKNOWN, the storage object reader cannot request data conversions. The reader must be able to handle the storage object writer's implementation of the storage object.