search

microsoft / ODBC-Specification

Microsoft ODBC Specification
Other
121 stars 40 forks source link

Clear up inconsistency in spec about SQL_DESC_DATA_PTR == NULL <-> column/parameter is unbound #130

Closed matthew-wozniczka closed 6 years ago

matthew-wozniczka commented 6 years ago

This is a problem already in the current ODBC 3.8 spec.

On the page for SQLBindParameter, it states (for ParameterValuePtr):

An application can set the ParameterValuePtr argument to a null pointer, as long as *StrLen_or_IndPtr is SQL_NULL_DATA or SQL_DATA_AT_EXEC. (This applies only to input or input/output parameters.)

This implies that doing so leaves that parameter successfully bound. On the other hand, on the page for SQLSetDescField, it states (again for ParameterValuePtr):

The column specified by the SQL_DESC_DATA_PTR field of the ARD is unbound if the TargetValuePtr argument in a call to SQLBindCol is a null pointer or if the SQL_DESC_DATA_PTR field in the ARD is set by a call to SQLSetDescField or SQLSetDescRec to a null pointer. Other fields are not affected if the SQL_DESC_DATA_PTR field is set to a null pointer.

The description under SQLSetDescField should be updated.

...Actually, while writing this up, I noticed it doesn't mention SQLBindParameter in the latter passage, but I think it does state that SQLBindParameter is equivalent to a certain sequence of calls to SQLSetDescField, so I think it's still inconsistent.

matthew-wozniczka commented 6 years ago

Ah, I didn't notice it was being specific about the ARD in

if the SQL_DESC_DATA_PTR field in the ARD is set by a call to SQLSetDescField or SQLSetDescRec to a null pointer

I guess it's not inconsistent (but pretty confusing). Is there a single place in the spec that clearly defines when a column/parameter is considered 'bound'?