Should SQL_ATTR_MAX_LENGTH statement attribute apply to nested results?

[mikepizzo]

SQL_ATTR_MAX_LENGTH can be applied to a statement in order to limit the number of results returned on that statement.

What if the statement has nested results? Should SQL_ATTR_MAX_LENGTH on the parent apply to nested collections as well?

If I prepare the statement and call SQLGetNestedHandle for nested collections, can I set SQL_ATTR_MAX_LENGTH on the nested handles before I execute the statement?

What other statement attributes can I apply to a nested statement handle prior to executing the parent?

[mikepizzo]

Presumably the application CAN set SQL_ATTR_MAX_LENGTH (and other statement attributes) on nested statement handles obtained prior to executing the statement, and setting after executing may result in Option Value Changed.

[pprudich]

Is this comment intended to refer to SQL_ATTR_MAX_ROWS instead of SQL_ATTR_MAX_LENGTH? A similar discussion could be had for either, but when you say "limit the number of results" I interpret that as limiting the row count, not the length of single column.

SQL_ATTR_MAX_ROWS also has that interesting stipulation about the driver not emulating the limit client-side. In practice, I expect that driver writers could frequently push down some sort of limit to a data source to limit the size of the result set, but not as easily limit the number of rows of nested collections.

[mikepizzo]

I did mean SQL_ATTR_MAX_ROWS but, as you say, both could apply.

It may be interesting to limit the number of rows, as well as size, of the nested result. Depending on the implementation, this might have to be set prior to executing the command on the parent handle; it may not be possible to change it once the parent has been executed, which is similar to the existing case:

The value of this attribute can be set on an open cursor; however, the setting might not take effect immediately, in which case the driver will return SQLSTATE 01S02 (Option value changed) and reset the attribute to its original value.

Separately, the (existing, 3.x) wording of this state is confusing. "...might not take effect immediately" implies that the setting might take effect later, which I would hope is not the case if we are changing the attribute back to the original value...

[mikepizzo]

Note: this seems to be a subset of issue #89.

[mikepizzo]

Closing as duplicate of #89.