Open matthew-wozniczka opened 7 years ago
Another edgecase would be the async mode of the nested statement, does it follow the current state of the parent connection (like normal statements), or the parent statement?
Many of the statement attributes you would not want automatically copied to the nested handle. We should decide if there are specific ones that should be copied and, if so, call them out. In any case, nested handles should not change when the parent changes.
Probably can't be changed: Currency, Scrollability, Sensitivity, CursorType, ... (anything applied at execute) Should call out things that don't have an effect (or prohibit changing).
Proposal:
Nested statement handles are considered open when their parent is open. Any descriptor fields that cannot be set when a cursor is in the open state cannot be set on a nested statement handle when a cursor is open on its parent.
The following attributes on the child handle reflect the settings on the parent handle and cannot be changed on the child. If changed on the parent, that change is visible through the child: SQL_ATTR_DYNAMIC_COLUMNS SQL_ATTR_ASYNC_ENABLE (ODBC 1.0) SQL_ATTR_CONCURRENCY (ODBC 2.0) SQL_ATTR_CURSOR_SCROLLABLE (ODBC 3.0) SQL_ATTR_CURSOR_SENSITIVITY (ODBC 3.0) SQL_ATTR_CURSOR_TYPE (ODBC 2.0) SQL_ATTR_SIMULATE_CURSOR (ODBC 2.0) SQL_ATTR_USE_BOOKMARKS (ODBC 2.0) SQL_ATTR_KEYSET_SIZE (ODBC 2.0) SQL_ATTR_ASYNC_STMT_EVENT (ODBC 3.8) SQL_ATTR_ASYNC_STMT_PCALLBACK (ODBC 3.8) SQL_ATTR_ASYNC_STMT_PCONTEXT (ODBC 3.8) should individual async_stmt events/callbacks/contexts be supported on nested handles?
The following attributes can be set on the child statement handle prior to executing the parent statement. If the driver does not support setting on an open cursor, it returns SQLSTATE 01S02 (Option value changed) and resets the attribute to its original value if called on an open cursor. SQL_ATTR_MAX_LENGTH (ODBC 1.0) SQL_ATTR_MAX_ROWS (ODBC 1.0) SQL_ATTR_RETRIEVE_DATA (ODBC 2.0)
The following attributes can be set on the child statement handle at any time it is not in the DATA_AVAILABLE/NEED_DATA state.
SQL_DESC_BIND_OFFSET_PTR SQL_DESC_BIND_TYPE SQL_DESC_ARRAY_STATUS_PTR SQL_DESC_ROWS_PROCESSED_PTR SQL_DESC_ARRAY_SIZE SQL_DESC_BIND_OFFSET_PTR SQL_DESC_BIND_TYPE SQL_DESC_ARRAY_STATUS_PTR SQL_DESC_ROWS_PROCESSED_PTR SQL_ATTR_FETCH_BOOKMARK_PTR (ODBC 3.0) SQL_ATTR_APP_ROW_DESC (ODBC 3.0) SQL_ATTR_ROW_ARRAY_SIZE (ODBC 3.0) SQL_ATTR_ROW_BIND_OFFSET_PTR (ODBC 3.0) SQL_ATTR_ROW_BIND_TYPE (ODBC 1.0) SQL_ATTR_ROW_STATUS_PTR (ODBC 3.0) SQL_ATTR_ROWS_FETCHED_PTR (ODBC 3.0) SQL_ATTR_ROW_OPERATION_PTR (ODBC 3.0) SQL_ATTR_PARAM_BIND_OFFSET_PTR (ODBC 3.0) SQL_ATTR_PARAM_BIND_TYPE (ODBC 3.0) SQL_ATTR_PARAM_OPERATION_PTR (ODBC 3.0) SQL_ATTR_PARAM_STATUS_PTR (ODBC 3.0) SQL_ATTR_PARAMS_PROCESSED_PTR (ODBC 3.0) SQL_ATTR_PARAMSET_SIZE (ODBC 3.0) SQL_ATTR_APP_PARAM_DESC (ODBC 3.0) SQL_ATTR_ENABLE_AUTO_IPD (ODBC 3.0) (applies next SQLPrepare)
The following don't apply and are ignored on a nested statement handle: SQL_ATTR_QUERY_TIMEOUT (ODBC 1.0) SQL_ATTR_METADATA_ID (ODBC 3.0) SQL_ATTR_NOSCAN (ODBC 1.0)
We should fully describe the initial state of a new newly-opened nested handle.
Are any statement attributes inherited from the parent?
If so, do they 'follow' the value set in the parent? In other words, if the value of the attribute is changed in the parent, would that implicitly change the value in the child? (I would say no)
Which statement state does it start in? (depends on context, but should be specified)