For information about the next fetch position when the rowset is first created, see IRowset::GetNextRows.
If the underlying command contains output parameters, IRowset::RestartPosition should not reset those parameters.
If the rowset was generated as a result of a procedure call and the rowset is forward-only, the procedure may be re-executed to satisfy the call to IRowset::RestartPosition. This may cause other side effects. Additionally, if the stored procedure has been changed, the rowset may have a different schema. If the rowset is able to restart the next fetch position without re-executing the procedure, IRowset::RestartPosition should not re-execute it.
How expensive IRowset::RestartPosition is depends on the provider, the rowset characteristics, and the tables underlying the rowset. If the rowset supports IRowsetLocate, IRowset::RestartPosition is always an inexpensive operation.
If the rowset is sequential, IRowset::RestartPosition might require re-execution of the underlying command. For some providers, this is always the case. For other providers, a rule of thumb is that rowsets built from a single table are not expensive to restart, but rowsets built by joining two or more tables are expensive to restart. If the provider re-executes the command to restart the next fetch position, the new rowset might return a different set of rows, differently ordered columns, and, in extreme cases, a different set of columns. Re-execution of a command by IRowset::RestartPosition does not reinherit accessors.
A provider that reports DBPROP_QUICKRESTART as VARIANT_FALSE may require that all existing row handles are released prior to successfully processing a call to IRowset::RestartPosition.
A consumer can determine whether a provider can quickly restart the next fetch position by attempting to set DBPROP_QUICKRESTART to VARIANT_TRUE. Setting this property to VARIANT_TRUE does not guarantee that the rowset can be quickly restarted because the provider is not required to honor the property. This behavior is necessary because the provider cannot evaluate the command at the time the property is set. For example, the consumer can set DBPROP_QUICKRESTART to VARIANT_TRUE and then change the command text.
In implementations that require re-execution of a command to reposition the next fetch position to its initial position, the provider is responsible for caching all parameters required by the command.
If IRowset::RestartPosition returns DB_S_COLUMNSCHANGED and the consumer subsequently calls methods in IColumnsInfo or IColumnsRowset, these methods must reflect the new metadata. Existing rowset accessors are not updated to reflect the new metadata. That is, IAccessor::GetBindings returns exactly the same information it would have returned before IRowset::RestartPosition was called. If such accessors are subsequently used, such as in a call to IRowset::GetData, the provider must revalidate them. If none of the columns bound by the accessor have changed, the accessor can be used successfully. If any of the columns have changed, the appropriate error or warning is returned.