Be careful, by getting and using the SQL handle directly you may change the internal state without the odbcpp library knowing and thus later have it generate unexpected errors.
At this time, this function is not thread safe.
You cannot bound a column by name and by index at the same time. There is nothing that prevents this from happening. You have to watch out.
You cannot change the binding after a call to statement::fetch().
The dynamic record binding changes the target type from the SQL type to the corresponding C type. The table below shows the different conversions.
With older versions of the ODBC libraries, the cancel() function may actually free the statement under the hood.
With older versions of the ODBC libraries, the cancel() function may actually free the statement under the hood.
At this time, the function handles the SQL_STILL_EXECUTING return code as an error and generates an exception. I think that calling the rows() function first will prevent this problem.
Some ODBC drivers may not support all the orientations. If you do not specify the orientation nor the offset, the simple SQLFetch() function will be used as it has the same effect as the SQL_FETCH_NEXT orientation.