search

microsoft / ODBC-Specification

Microsoft ODBC Specification
Other
121 stars 40 forks source link

Can multiple nested statements be open on different rows of the same column, concurrently? #119

Closed matthew-wozniczka closed 7 years ago

matthew-wozniczka commented 7 years ago

Consider the following scenario.

  1. Application calls SQLFetch, which returns with SQL_DATA_AVAILABLE
  2. Application calls SQLNextColumn, then opens a nested statement on column N
  3. Application calls SQLNextColumn again, and opens another nested statement on column N (but on a separate row)

Can this happen? Section 6.2.1 says:

Multiple calls to SQLGetNestedHandle for the same ParentStatementHandle and Col_or_Param_Num return the same ChildStatementHandle (including any added/modified descriptor fields) unless that handle has been explicitly freed

which seems to forbid this. But it doesn't seem like the handle opened in (2) is implicitly closed by a call to SQLGetNextColumn (There is just Applications SHOULD call SQLCloseCursor on the nested handle when finished reading results., which has SHOULD), so it's unclear what should happen.

matthew-wozniczka commented 7 years ago

From the implementation point of view, it will be much easier to implement if only 1 'version' of a column needed to exist at a time (as is not the case if the example above involves SQL_METADATA_CHANGED).

Also, it brings up issues like, if the application could have two open nested statements on the same column but separate rows, would modifications to one of them affect the other (descriptors, statement attributes), and if they did, how would that work in the case of a variant column with different types on different rows?

I think it's a box better left unopened.

mikepizzo commented 7 years ago

Unless GD_CONCURRENT bit has been set in SQL_GETDATA_EXTENSIONS, calling SQLNextColumn should close any nested handles.

GD_CONCURRENT should not be supported for rowset size >1.