http://msdn.microsoft.com/en-us/library/ms710963(v=vs.85).aspx
The problem is that in most cases of data at execution, the application is allowed to store a pointer value which identifies the parameter to be supplied (in our case, the Parameter object). This is passed instead of the buffer since a DAE SQL_PARAM_INPUT or SQL_PARAM_INPUT_STREAM doesn't need a bound output buffer.
In this case, however, the pointer value stored must be a pointer to the output buffer itself, not the Parameter object, as the driver needs the address of the output buffer.
We can't even search through all the bound parameters (this->bindings_) and find the parameter with a matching buffer because SQLParamData doesn't tell us what type of parameter is needed. The only way I can think to get around it is to actually store the parameter number (rather than a pointer) for all other parameter types and assume that tokens less than SHRT_MAX are parameter numbers and all other values are bound output buffers to search through bindings_ for.
http://msdn.microsoft.com/en-us/library/ms710963(v=vs.85).aspx
The problem is that in most cases of data at execution, the application is allowed to store a pointer value which identifies the parameter to be supplied (in our case, the
Parameterobject). This is passed instead of the buffer since a DAESQL_PARAM_INPUTorSQL_PARAM_INPUT_STREAMdoesn't need a bound output buffer.In this case, however, the pointer value stored must be a pointer to the output buffer itself, not the
Parameterobject, as the driver needs the address of the output buffer.We can't even search through all the bound parameters (
this->bindings_) and find the parameter with a matching buffer becauseSQLParamDatadoesn't tell us what type of parameter is needed. The only way I can think to get around it is to actually store the parameter number (rather than a pointer) for all other parameter types and assume that tokens less thanSHRT_MAXare parameter numbers and all other values are bound output buffers to search throughbindings_for.