Made to Order Software Corporation Logo

odbcpp: Bug List

Member odbcpp::environment::get_data_source (data_source_type_t type, data_source_vector_t &sources)
At this time you cannot distinguish between user and server data sources.

Member odbcpp::handle::get_handle () const

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.

Member odbcpp::object::addref () const

At this time, this function is not thread safe.

Class odbcpp::record

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().

Member odbcpp::record_base::bind_impl ()=0

The dynamic record binding changes the target type from the SQL type to the corresponding C type. The table below shows the different conversions.

Member odbcpp::statement::cancel ()

With older versions of the ODBC libraries, the cancel() function may actually free the statement under the hood.

Member odbcpp::statement::close_cursor ()

With older versions of the ODBC libraries, the cancel() function may actually free the statement under the hood.

Member odbcpp::statement::fetch (record_base &rec, SQLSMALLINT orientation=SQL_FETCH_NEXT, SQLLEN offset=0)

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.

Generated on Mon Sep 19 12:52:27 2011 for odbcpp by  doxygen 1.6.3