This topic provides information that is relevant for CDSCs that support both HDATA and VDATA.

When a top-level Command is created, it has no bindings, and isn't associated with any particular table. It's not until its first binding is added that the CDSC can determine whether it is associated with VDATA or HDATA (based on which table the new binding belongs to). Thereafter, for each new binding, the CDSC has to make sure that the new binding belongs to the same table as the existing ones.

However, the next query might not be from the same top-level table. For example, the first query might be from VDATA and the next one from HDATA. After the first query, the Provider clears all of the bindings from the Command in preparation for adding the bindings for the variables in HDATA. When the bindings collection becomes empty, the CDSC must dissociate the (top-level) Command from its table, so that it can be used with whatever (top-level) table the next incoming binding belongs to. If the CDSC fails to do this, the Command remains associated with VDATA, and will reject a binding for an HDATA column.

However, this switching between tables applies only to top-level Command objects. For child Command objects created by the CDSC as a result of a Table binding at the parent level, the Command must always be associated with the bound parent Table, and shouldn't change its allegiance in response to changes in its bindings collection. In the XML CDSC C++ source code there's a member variable CDataBindings::m_bStayAttachedToTable that's used to control this.