For more detail, see the summary of new features. The archived version of the OTL Web pages is available.

 

Feature

Comment
12-May-2012: (New in OTL 4.0.265 (updated)):

  • This release has been successfully tested with DB2 LUW 10.1. #define OTL_DB2_CLI should be used with DB2 10.1.

  • This release has been successfully tested with SQL Server 2012. #define OTL_ODBC_MSSQL_2008 should be used with SQL Server 2012, and SQL Server 2008 Release 2.

24-Apr-2012, New (in OTL 4.0.265):

  • A problem was reported that the following line(s) in the OTL header file cause a core dump in HPUX:

         static OTL_STRING_CONTAINER delimiter(";");

    The problem is that for static-in-function non-POD (plain old data) variables, the HPUX C++ registers corresponding destructor calls as atexit() handlers, which get called when main() returns. This is problematic when static variables reside in a shared object, which may be unloaded before main() returns. Ideally, destructors of such static(-in-function) variables should get called before the shared object is unloaded. Most C++ compilers don't have such a problem. HPUX C++ does, and some old versions of AIX C++ (xlC) have similar behavior. The problem is fixed in this release.

  • The following compilation problem was reported when #define OTL_ODBC_TIMESTEN_WIN is used in compilation with VC++ in 64-bit mode (#define _WIN64) in Windows:

    error C2664: "SQLParamOptions" : cannot convert parameter 3 from "SQLUINTEGER *" into "SQLULEN *"

    The problem is fixed in this release.
19-Apr-2012, New (in 4.0.264 (updated)):

  • The F.A.Q. has been updated: a new Q&A has been added to answer the question of whether OTL can handle stored procedures that return multiple implicit result sets or not (when used with ODBC, MS SNAC, or DB2 CLI).

14-Apr-2012, New (in OTL 4.0.264):

  • A problem was reported that when otl_lob_stream::operator>>(std::string&) is reading a BLOB (binary large object) value containing 0 bytes ('\0') in it, the value gets truncated to the very first 0 byte. It was not a bug, it was a feature, meaning that std::strings were meant to be used with character strings (not binary strings), and the otl_lob_stream::operator>>() used std::string::operator+=(), which relied on the null terminator byte in the string. This release and higher will use std::string::append(const char*, size_t len) instead, which does the concatenation based on the "len" parameter. otl_lob_stream::operator(ACE_TString&) has the same behavior (when #define OTL_ACE is used) as otl_lob_stream::operator>>(std::string&) (when #define OTL_STL is used).
10-Apr-2012, New (in OTL 4.0.263):

  • More of C++11 features used in this release: copy / move constructors, copy / move assignment operators, etc., that were made private before, are declared " = delete" (as deleted) for GNU C++ 4.7.0 and higher for better compiler diagnostic and clarity of the interface.
6-Apr-2012, New (in OTL 4.0.262):

  • A problem in  otl_exception class reported: when Visual C++  8 or higher is used, and when the text of an SQL statement (stm_text data member) is longer than the sizeof(stm_text), Visual C++ runtime throws an error. The problem is fixed in this release.

  • This release introduces the use of many C++11 features available in g++ 4.7.0 or higher under the following new #define: OTL_CPP_11_ON. The OTL source code was modified to take advantage of the C++11 new techniques and features, which results in cleaner code. Support of C++11 features is not even in different C++ compilers, so it had to be conditionally compiled.

    When g++ 4.7.0 or higher is used, and when -std=c++11 is enabled on the compilation command line, I'd also recommend to add the following warnings: -Wc++0x-compat -Wzero-as-null-pointer-constant. The compiler will tell you what's not kosher in your source code. OTL build enables the warnings when -std=c++11 is enabled on the command line.
3-Apr-2012, New (in OTL 4.0.261):

  • This release introduces the following new OTL defined exception in order to avoid confusion about stored procedures returning result sets:

    • code 32040, this type of otl_stream can only have input variables.
30-Mar-2012, New (in OTL 4.0.260):

  • A memory leak was reported when OTL stream pooling (#define OTL_STREAM_POOLING_ON) is used. The symptom is reproducible when otl_stream::open() is called, and otl_stream::~otl_stream() right after that. The reporter of the problem says that the memory leak is present in more circumstances. The problem is fixed in this release.

  • More detail has been added to the descriptions of otl_connect::commit() and otl_connect::rollback() functions in order to clarify things.
24-Mar-2012, New (in OTL 4.0.259):

  • GNU C++ 4.7.0 was released a few days ago. This release of OTL compiles clean with G++ 4.7.0, and all unit tests work correctly.

  • A problem was reported that when OTL_UNICODE is enabled and a variable of the otl_long_string class is used instead of otl_long_unicode_string by mistake, it is hard to figure out what went wrong. This release closes the loophole by introducing the following two new OTL defined exceptions:

    • code 32038, otl_long_unicode_string should be used with strings when OTL_UNICODE is enabled, and otl_long_string should be use with strings when OTL_UNICODE is not enabled

    • code 32039, otl_long_string should be used with nonstrings when OTL_UNICODE is enabled
21-Mar-2012, New (in OTL 4.0.258):

  • GNU C++ 4.6.3 was released a few weeks ago. This release of OTL compiles clean with G++ 4.6.3, and all unit tests work correctly.

  • A problem was reported that when #define OTL_ODBC / #define OTL_ODBC_MULTI_MODE is used with the Oracle ODBC driver, and #define OTL_BIGINT / #define OTL_STR_TO_BIGINT / #define OTL_BIGINT_TO_STR, "bigint" values beyond 2GB do not get written / read correctly. The problem is fixed in this release.


29-Feb-2012, New (in OTL 4.0.257):

  • This release introduces the following new functions when OTL stream pooling is enabled: otl_connect::stream_pool_enable(), otl_connect::stream_pool_disable(), otl_connect::get_stream_pool_enabled_flag().
12-Feb-2012, New (in OTL 4.0.256):

  • A problem was reported that when OTL stream pooling is used with two identical SELECT statements, which have the same otl_stream buffer sizes, but have different sets of SELECT output column overrides (made via calls to otl_stream::set_column_type()), the stream pool doesn't distinguish between the two SELECT statements. The key in the stream pool was the SQL statement text + stream buffer size. This release extends the stream pool key to take the SELECT output column overrides into account.
11-Feb-2012, New (in OTL 4.0.255):

  • This release introduces basic optional native support for unsigned 64-bit integers in the form of the following new bind variable type: ubigint. Also, see OTL code example 243 (DB2), 698 (Oracle 11.2).

    NOTICE: For database APIs that have no native support for unsigned 64-bit ints, OTL extended numeric types can be used, which were introduced in OTL 4.0.245.
21-Jan-2012, New (in OTL 4.0.254):

  • The following compilation problem was reported in a 64-bit Linux, unixodbc 2.2.14, SQLite, and GNU C++ 4.6.1:

    error: cannot convert ‘SQLUINTEGER* {aka unsigned int*}’ to ‘SQLULEN* {aka long unsigned int*}’ for argument ‘3’ to ‘SQLRETURN SQLParamOptions(SQLHSTMT, SQLULEN, SQLULEN*)’

    The problem has been fixed in this release.
11-Jan-2012, New (in OTL 4.0.253):

  • The following compilation problem was reported in OTL/DB2-CLI (#define OTL_DB2_CLI), when it's compiled in a 64-bit Windows in the 64-bit mode: internal OTL_SQLLEN type (and others) were not of the proper size for a 64 bit Windows system. The problem is fixed in this release.
22-Dec-2011, New (in OTL 4.0.252):

  • A bug was reported that when an std::string has a null terminator in the middle, and it gets written into a VARCHAR table column via char[XXX] bind variable, nothing gets written beyond the null terminator. It's not quite a bug, it's a feature as far as the cliche goes. OTL binds "NULL terminated strings" with its char[XXX] bind variables.

    For strings with null terminators in the middle, raw[XXX] binding should be used instead. In this release, otl_stream's string (std::, or ACE, or user defined) operator>>/<< have been expanded to work with raw[XXX]. See also code examples 747 (Oracle, OCI7), 748 (Oracle, OCI 8 or higher), 749 (DB2), 750 (MS SQL). It's easy to convert these new code examples to use with other database types.

    A new entry has been added to the F.A.Q. to cover the topic of std::strings and embedded NULL characters.
19-Dec-2011, New (in OTL 4.0.251 (updated)):

  • This release compiles clean with GNU C++ 4.3.x and higher when the following command warning option is enabled:

           -Wc++0x-compat

    It's a C++0X / C++11 compatibility warning for GNU C++.

10-Dec-2011, New (in OTL 4.0.251):

  • A bug was reported in otl_connect::session_begin() (OTL for Oracle), when it's used with Oracle 11.2 and empty user id / empty password (a.k.a. external authentication, equivalent to "connect /" in SQLPlus), it fails to authenticate the credentials. The bug is fixed in this release.
24-Nov-2011, New (in OTL 4.0.250):

  • The following typos (bugs) were reported in copy and move constructors in the otl_column_desc class:

      otl_column_desc(const otl_column_desc& desc):
        ...
        dbsize(desc.dbtype),
        ...

      otl_column_desc(otl_column_desc&& desc):
       ...
        dbsize(desc.dbtype),
       ...

    which means that if otl_column_desc is used in containers (std:: or any other) that implement copy and / or move semantic, the dbsize data member will be copied / moved incorrectly.

    The bugs are fixed in this release. The impact of these typos seems to be pretty small, because any of the OTL unit tests or the use of otl_column_desc in actual OTL based C++ code haven't uncovered the typos until now. Typically, otl_column_desc is not used in any containers.
16-Nov-2011, New (in OTL 4.0.249):

  • A problem was reported in OTL/ODBC when it's used with the SQLite 3 ODBC driver in the SQLDescribeCol() function call when #define OTL_UNICODE is enabled. The problem is that the column name buffer size (4th parameter) is specified in bytes instead of Unicode characters. The problem is fixed in this release.
29-Oct-2011, New (in OTL 4.0.248 (updated)):

  • GNU C++ 4.6.2 was released on 10/26/2011. OTL 4.0.248 compiles clean with GNU C++ 4.6.2.

  • Two new code examples have been added:

    • example 745, which demonstrates how to use the UTF-8 client encoding with OTL and PostgreSQL. The PostgreSQL ANSI ODBC driver supports UTF-8 "out of the box".

    • example 746, which demonstrates how to use #define: OTL_ORA_CUSTOM_MAP_NUMBER_ON_SELECT, introduced in OTL 4.0.247.

13-Oct-2011, New (in OTL 4.0.248):

  • This release introduces the following new function: otl_stream::get_error_stream(). This function returns true if the stream is in the "error state" and requires "cleaning". See also code examples 65, 66, 67, 166.
11-Oct-2011, New (in OTL 4.0.247):

  • This release introduces the following new #define: OTL_ORA_CUSTOM_MAP_NUMBER_ON_SELECT. This #define can be used to override the OTL default numeric data type mapping on SELECT statements for Oracle.
08-Oct-2011, New (in OTL 4.0.246):

  • A problem was reported that otl_stream::describe_next_out_var() returns an incorrect result after otl_stream::skip_to_end_of_row() was called. The problem has been fixed in this release.
02-Oct-2011, New (in OTL 4.0.245):

  • OTL introduces the following new feature: extended numeric data types. Normally, that would be used for numeric data types that are not supported by the underlying database APIs, for example unsigned long long, long double, etc. It's done in a form of sets of #defines that specify the details of the new numeric data types. Also, see example 741, 742, 743, 744.
18-Sep-2011, New (in OTL 4.0.244 (updated)):

  • PostgreSQL 9.1 was just released, and I've already been getting questions on whether OTL supports it or not. All PosgtreSQL based unit tests + publicly available code examples run cleanly against PostgreSQL 9.1.

10-Sep-2011, New (in OTL 4.0.244):

  • A problem was reported when an SQL statement in an otl_stream has a bind variable declaration with a white space in it, the SQL statement silently fails at runtime. Ideally, an OTL defined exception should be thrown, instead of the stream returning incorrect results. Generally speaking, OTL doesn't allow white spaces in bind variable declarations. This release fixes the problem, and introduces the following new OTL defined exception, which gets thrown when a white space is found in a bind variable declaration: SQL Statement has a white space in bind variable declaration.


06-Sep-2011, New (in OTL 4.0.243 (updated)):

  • Fixed a few dead hyperlinks.

03-Sep-2011, New (in OTL 4.0.243):

  • A compilation problem (missing functions / operators in otl_stream class) were reported under the following set of OTL related #defines:

    #define OTL_BIND_VAR_STRICT_TYPE_CHECKING_ON
    #define OTL_ORA10G_R2
    #define OTL_ORA_TIMESTAMP
    #define OTL_STL
    #define OTL_EXCEPTION_IS_DERIVED_FROM_STD_EXCEPTION
    #define OTL_VALUE_TEMPLATE_ON
    #define OTL_ORA_DECLARE_COMMON_READ_STREAM_INTERFACE
    #define OTL_BIGINT ...
    #define OTL_STR_TO_BIGINT(str,n) ...
    #define OTL_BIGINT_TO_STR(n,str) ...

    The problem is fixed in this release.

  • Several potential problems (memory leaks, dereferencing NULL pointer, etc.) were reported based on results of the Microsoft Visual Studio 2005 "Team Edition for Software Developers" / "Code Analysis for C/C++". The problems have never been reported or found in tests as actual problems. This release fixes some of these potential problems, in order to make the Microsoft tool happy.
11-Aug-2011, New (in OTL 4.0.242):

  • Several potential problems (memory leaks, check for assignment to self in operator =, pointer may be NULL and could be dereferenced) were reported based on results of klocwork. The problems have never been reported or found in tests as actual problems. This release fixes the potential problems, in order to make klocwork happy.
31-Jul-2011, New (in OTL 4.0.241 (updated 2)):

  • The following new code example was contributed to the OTL examples: 740. It demonstrates how to use OTL with MySQL stored procedures that have output parameters. MySQL ODBC driver doesn't seem to support stored procedure output parameters. The code example demonstrates a technique that works around the limitation of the MySQL ODBC driver. If somebody knows how to work with stored procedure output parameters in a more regular way, any info would be highly appreciated.

30-Jul-2011, New (in OTL 4.0.241 (updated)):

  • This release compiles clean with GNU C++ 4.6.1, which was released about a month ago.

23-Jul-2011, New (in OTL 4.0.241):

  • A compilation problem was reported with Visual C++ 6.0, when #define OTL_ORAX (ORA7, ORA8, ...ORA11G_R2) and OTL_STLPORT are used. The problem is fixed in this release.

  • A compilation problem was reported in otl_input_iterator when it's compiled with GNU C++ 4.6.0 and when 64-bit ODBC Unix/Linux header files are used. The problem is fixed in this release.

  • This release introduces the following new #define: OTL_ORA_CUSTOM_FREE_TEMP_LOB. It addresses a problem of proper utilization when temporary Oracle LOBs get created via dbms_lob package, and get passed back into C++/OTL based code. When this #define is enabled it adds a call to OCILobFreeTemporary(), which deallocates the corresponding OCI resources correctly.

  • This release introduces the following new #define: OTL_STLPORT_USES_STD_ALIAS_NAMESPACE. It addresses a problem when OTL is used with STLPort (#define OTL_STLPORT is enabled), and when STLPort is configured to use __std_alias namespace.
19-Jun-2011, New (in OTL 4.0.240):
7-Jun-2011, New (in OTL 4.0.239):

  • The following compilation problem was reported under OTL/OCIx: error C2039: 'get_prefetched_row_count' : is not a member of 'otl_stream'. The problem is fixed in this release.

  • otl_stream::inc_next_ov() under OTL/OCIx was reported to be public yet undocumented. The function (and one  more similar function) was made protected.
1-Jun-2011, New (in OTL 4.0.238):

  • The following bug was reported in otl_stream::get_dirty_buf_len(): the function sometimes returns -2 instead of 0 when used with SELECT statements under OTL/OCIx. The bug is fixed in this release. Also, a few code examples have been added (examples 736, 737, 738, 739) for Oracle, DB2, and MS SQL Server (a.k.a. major database types). The code examples can be easily modified for OTL supported minor database types.

  • A compilation problem was reported when OTL was used with C++/CLI (Managed C++) and VC++ 2008. The problem was that nullptr was #defined as 0 when it's a legitimate keyword in C++/CLI. The problem is fixed in this release.
25-May-2011, New (in OTL 4.0.237):

  • The following bug was reported in otl_stream::get_dirty_buf_len(): the function doesn't return 1 (one) when rows, say, get inserted into a table. A typical actual sequence of returned values goes like this: 0,2,3... The bug is fixed in this release.


04-May-2011, New (in OTL 4.0.236):

  • Visual C++ 10 supports C++11 rvalue references and move semantics. This release adds (conditionally compilable for VC++ 10) public move constructors and move assignment operators to OTL classes (otl_column_desc, otl_long_string / otl_long_unicode_string) that already have public copy constructors / copy assignment operators (a.k.a. copyable /  assignable classes), and which also have pointers to big chunks of memory  allocated as separate memory blocks on the heap. Now the same classes are  movable, which makes them more efficient with STL containers.


30-Apr-2011, New (in OTL 4.0.235):

  • Visual C++ 10 supports C++11 rvalue references and move semantics. This release adds (conditionally compilable for VC++ 10) private move constructors and move assignment operators to OTL classes that already have private copy constructors and copy assignment operators, in order to keep the classes from being used in STL containers. The reason why such classes got private copy constructors and copy assignment operators in the first place was that they allocated unsharable database APIs resources.


20-Apr-2011, New (in OTL 4.0.234):

  • The following Open VMS C++ compiler warning was  reported  for a number of lines:

               %CXX-W-CASTQUALTYP, type qualifier is meaningless on cast type.

    The warning is fixed in this release.
19-Apr-2011, New (in OTL 4.0.233):
03-Apr-2011, New (in OTL 4.0.232):

  • GNU C++ 4.6.0 came out on March 25. This release fixes the following g++ 4.6.0 compilation warning: Line 23402, variable byte_lob_len is set but not used.
25-Mar-2011, New (in OTL 4.0.231):

  • The following compilation warnings were reported when OTL compiles with GNU C++ 4.5.1:
       
    warning: tmp.tagTIMESTAMP_STRUCT::year may be used uninitialized in this function
    note:tmp.tagTIMESTAMP_STRUCT::year was declared here
    warning: tmp.tagTIMESTAMP_STRUCT::month may be used uninitialized in this function
    note: tmp.tagTIMESTAMP_STRUCT::month was declared here
    warning: tmp.tagTIMESTAMP_STRUCT::day may be used uninitialized in this function
    note: tmp.tagTIMESTAMP_STRUCT::day was declared here
    warning:tmp.tagTIMESTAMP_STRUCT::hour may be used uninitialized in this function
    note: tmp.tagTIMESTAMP_STRUCT::hour was declared here
    warning: tmp.tagTIMESTAMP_STRUCT::minute may be used uninitialized in this function
    note: tmp.tagTIMESTAMP_STRUCT::minute was declared here
    warning: tmp.tagTIMESTAMP_STRUCT::second may be used uninitialized in this function
    note: tmp.tagTIMESTAMP_STRUCT::second was declared here
    warning: tmp.tagTIMESTAMP_STRUCT::fraction may be used uninitialized in this function
    note: tmp.tagTIMESTAMP_STRUCT::fraction was declared here


    The warnings are fixed in this release.
17-Mar-2011, New (in OTL 4.0.230):

  •  The following compilation problem was reported when OTL 4.0.229 is compiled with DB2 Client 8.x header files: "symbol SQL_ATTR_INFO_PROGRAMNAME is not defined". The problem is fixed in this release.
05-Mar-2011, New (in OTL 4.0.229):

  • A Visual C++ compilation error was reported when #define OTL_ODBC and #define OTL_ORA_UTF8 are defined together in the same compilation unit: error C2039: 'set_nls_flag' : is not a member of 'odbc::otl_var'. The error is fixed in this release.

  • The following new #define is introduced in this release in order to address a "memory access violation" error when OTL_ODBC and OTL_ORA_UTF8 enable two different instances of OTL in two separate compilation units in the same program: OTL_CONTAINER_CLASSES_HAVE_OPTIONAL_MEMBERS.

  • This release introduces a new function in the otl_connect class: set_prog_name(). The function allows an "application name" to be set that shows up in the output of DB2 command line processor's "list applications" command.
24-Feb-2011, New (in OTL 4.0.228 (updated))
  • Suryadi Wen, a database developer from Canada contributed some useful information on Oracle otl_subscriber for the following question in the OTL F.A.Q.: Why don't my Oracle otl_subscriber receive notifications on INSERT or UPDATE or DELETE statements?

5-Feb-2011, New (in OTL 4.0.228):
  • A memory leak was reported in OTL/OCIx when  the same otl_stream is used with an otl_long_string that has an  internal buffer and then with another otl_long_string that uses an external buffer. The memory leak is fixed in this release.
26-Jan-2011, New (in OTL 4.0.227):

  • A missing defined(__MVS__) clause in a  #if statement was reported in OTL 4.0.226, line 9797, which results in a compilation error when compiled with C++ on z/OS, IBM mainframes:

    #if (defined(_MSC_VER)&&(_MSC_VER==1200)) // VC 6++

    It should read as follows:

    #if (defined(_MSC_VER)&&(_MSC_VER==1200)||defined(__MVS__)) // VC 6++ or C++ in MVS

    The problem is fixed in this release.


25-Jan-2011, New (in OTL 4.0.226):

  • The following compilation problem was reported for VC++ 2010, when #defines OTL_ORA8I, OTL_STL, OTL_ANSI_CPP, and OTL_EXPLICIT_NAMESPACES are enabled at the same time:

    otlv4.h(32933): error C2143: syntax error : missing ';' before '<'
    otlv4.h(32933): error C2059: syntax error : '<'
    otlv4.h(32933): error C2065: 'T' : undeclared identifier
    otlv4.h(32933): error C2059: syntax error : 'public'
    otlv4.h(32933): error C2143: syntax error : missing ';' before '{'
    otlv4.h(32933): error C2447: '{' : missing function header (old-style formal list?)
    otlv4.h(32933): error C2039: 'output_iterator_tag' : is not a member of 'oracle::std'
    otlv4.h(32933): error C2146: syntax error : missing ';' before identifier 'iterator_category'
    otlv4.h(32933): error C2433: 'output_iterator_tag' : 'inline' not permitted on data declarations
    otlv4.h(32933): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
    otlv4.h(32933): error C2065: 'T' : undeclared identifier

    The problem is fixed in this release.
31-Dec-2010, New (in OTL 4.0.225 (updated (2)):
  • The following new example has been added in order to demonstrate how use OTL/OCIx with PL/SQL functions that return reference cursors: example 735.


25-Dec-2010, New (in OTL 4.0.225 (updated)):
  • The following new code examples have been added in order to demonstrate how to use OTL with numbers larger than signed 64-bit integer (>19 digits). The main assumption is that there is a "Big Number" class that can hold many enough decimal significant digits.

    • Oracle: example 729, 732 (Unicode)
    • DB2: example 730, 733 (Unicode)
    • MS SQL Server: example 731, 734 (Unicode)
       
18-Dec-2010, New (in OTL 4.0.225):
  • A compilation error was reported when OTL_STLPORT and OTL_ORA11G_R2 are defined together. The error was introduced in OTL 4.0.223 in the following fixes for Visual C++ 10. The compilation problem is fixed in this release.

  • A problem was reported in otl_lob_stream::len() when OTL is used with Oracle 9i. The function may return random values under some circumstances. The problem seems to be specific to an OCI9 call, which doesn't initialize an output variable. The problem is fixed in this release: the variable gets initialized before the call.

  • GNU C++ 4.5.2 was just released (16-Dec-2010). This release of OTL compiles clean with GNU C++ 4.5.2, and all unit tests run fine.

  • CODE CLEANUP. Incoming C++0x standard is going to introduce "nullptr" as a new keyword, which is already supported by Visual C++ 10. nullptr is a "new NULL pointer" that is of nullptr_t type, and it's convertible to any pointer type, but it's not interchangeable with 0. OTL #defines  nullptr as 0 for C++ compilers that don't support nullptr yet. All 0s (zeroes) in the OTL header file that are NULL pointers have been replaced with nullptr in this release.
03-Dec-2010, New (in OTL 4.0.224):
  • The following bug was reported when OTL/ODBC + Unicode (UTF-16) is used with MS ACCESS ODBC driver: Invalid precision value. The problem was in an SQLBindParameter() ODBC call in the columnSize parameter. The bug is fixed in the this release.
25-Nov-2010, New (in OTL 4.0.223 (updated)):
  • This release has been successfully tested with MySQL 5.5


24-Nov-2010. New (in OTL 4.0.223 (updated)):
  • The following new code examples to demonstrate how to the SQL MERGE statement with OTL have been added in this release:

    • Oracle 9i and higher, example 726
    • DB2, example 727
    • MS SQL Server, example 728

29-Oct-2010. New (in OTL 4.0.223):

  • A bug was reported  in the following conditional compilation that checks for Visual C++ 10: (_MSC_VER >= 1500). _MSC_VER for Visual C++ 10 is 1600. The bug is fixed in this release of OTL.

  • A bug was reported that when otl_output_iterator is derived from class _Outit under Visual C++ 10. _Outit actually belongs to namespace std, which OTL didn't declare correctly. The bug is fixed in this release of OTL.
23-Oct-2010. New (in OTL 4.0.222):

  • A bug was reported that when #define OTL_STL is used, the OTL header file uses "using namespace std", which pollutes the global namespace with names from namespace std. This release of OTL fixes the problem.

  • A compilation warning (C4996) was reported when OTL is compiled with Visual C++ 2010 in Debug mode and when  #define OTL_STL is enabled. The Debug mode of Visual C++ 2010 enables "#define _SECURE_SCL 1" by default, that is, it enables the so called "Checked STL Iterators", which are supposed to help debug STL iterators in custom C++ code. When _SECURE_SCL is set to 0, the compilation warning doesn't show up. The problem was that Visual C++ 2010 changed its implementation of STL. Now, it requires additional helper classes for Checked Iterators to function properly. OTL defines otl_input_iterator, and otl_output_iterator, which need those extra helper classes. The problem is fixed in this release. Checked Iterators now can be used with OTL otl_input_iterator, and otl_output_iterator.
22-Sep-2010. New (in OTL 4.0.221 (updated)):
  • This release of OTL has been successfully tested with PostgreSQL 9.0 and DB2 9.7.2.

13-Sep-2010. New (in OTL 4.0.221):
  • The following OTL defined compilation error has been relaxed / eliminated in this release: #error OTL_BIGINT is not supported when OTL_ORAXX and OTL_ODBC. This means that OTL supports "bigint" functionality when more than one instatiation of OTL is enabled in the same module. For example, when OTL_ODBC and OTL_ORA11G are defined, or OTL_DB2_CLI and OTL_ORA7 are defined. Special thanks to Konstantin Vasilyev from Russia for providing the necessary code changes.
29-Aug-2010. New (in OTL 4.0.220 updated (2)):
  • The following code example for TimesTen has been added to show how to use TT_BIGINT (64-bit integers)
    with OTL: example 725.

08-Aug-2010. New (in OTL 4.0.220 (updated)):
  • GNU C++ 4.5.1 was just released (end of July, 2010). This version of OTL compiles clean with GNU C++ 4.5.1, and all unit tests run fine.

06-Aug-2010. New (in OTL 4.0.220):
  • This release introduces support for the following ODBC/DB2-CLI data dictionary access function: SQLStatistics().
17-July-2010. New (in OTL 4.0.219):
  • A problem was reported that the otl_stream "auto-commit" flag is not available (after public data members of the otl_stream class were made private/protected at some point in time in OTL 4.0). This release introduces the following new getter function for getting the flag: otl_stream::get_auto_commit_flag().
27-June-2010. New (in OTL 4.0.218 (updated)):
  • I've been asked to add similar code examples (of the bulk interface and LOBs) for MS SQL Server, and DB2 at least. Here they go:
26-June-2010. New (in OTL 4.0.218):
  • This version of OTL introduces OCI7 (classic OCI) support for the bulk interface for small Oracle LONG RAWs (up to 64KB in size) via raw[XXX] bind variable data type, and the bulk interface for Oracle LONGs (the upper limit is not clear, theoretically it could be up to 2GB) via char[XXX] bind variable data type. For more detail, see examples 720, 721.
23-June-2010. New (in OTL 4.0.217):

  • This version of OTL introduces support for the bulk interface for small Oracle BLOBs (up to 64KB in size) via raw[XXX] bind variable data type, and the bulk interface for Oracle CLOBs (the upper limit is not clear, theoretically it could be up to 2GB) via char[XXX] bind variable data type. For more detail, see examples 718, 719.

    Versions of OTL below 4.0.217 support the bulk interface for small BLOBs (up to 32KB in size).
19-June-2010. New (in OTL 4.0.216):

  • Examples for PostgreSQL have been modified to show the use of the bulk interface (buffer sizes > 1 for INSERT / UPDATE / DELETE statements) for PostgreSQL 8.2 and higher. Versions of the PostgreSQL ODBC drivers higher than the version of the PostgreSQL server can be used together. For example, server version 8.1 works with PostgreSQL ODBC driver version 8.4 (and this version of the driver supports the bulk interface even with PostgreSQL server 8.1).

05-June-2010. New (in OTL 4.0.216):

  • An Oracle error was reported in otl_stream::create_stored_proc(), when it's used with Oracle 10.2. The bug is fixed in this release.
28-May-2010. New (in OTL 4.0.215):

  • A few C++ compilation warnings were reported when compiling with the latest cygwin (version 1.7.5, I believe). The warnings have been fixed in this release.
     

19-Apr-2010. New (in OTL 4.0.214, updated (2)):

  • GNU C++ 4.5.0 was released recently. OTL 2.0.214 compiles clean with g++ 4.5.0, and all OTL tests from the OTL test suite run correctly.

18-Apr-2010. New (in OTL 4.0.214, updated):

  • Visual C++ Studio 2010 (version 10) was released recently. OTL 2.0.14 compiles clean with VC++ 10, and all OTL tests from the OTL test suite run correctly.

02-Apr-2010. New (in OTL 4.0.214):

  • A bug was reported that when OTL/OCIx (x>=8) is used together with the LOB stream class, in case of an UPDATE statement that updates 0 rows, OTL throws the Oracle "Invalid LOB locator" exception. otl_lob_stream::close() function was modified to accommodate this special condition, and OTL code examples 56, and 57 were modified to show how to use it.

  • A bug similar to the first bug was found, when  OTL/OCIx (x>=8) is used without the LOB stream class, in case if an UPDATE statement updates 0 rows. The bug is fixed in this release.
19-Mar-2010. New (in OTL 4.0.213, updated):

  • What's New Page has been updated to reflect the traffic to the OTL Web site.

10-Mar-2010. New (in OTL 4.0.213):

  • This release introduces the following new #define in order to address compatibility issues with some frameworks, and transaction monitors: OTL_ROLLS_BACK_BEFORE_LOGOFF.


07-Mar-2010. New (in OTL 4.0.212):
28-Feb-2010. New (in OTL 4.0.211, updated):

  • GNU C++ 4.4.3 was released a month ago. This release of OTL compiles clean with g++ 4.4.3.

25-Feb-2010. New (in OTL 4.0.211):

  • A bug was reported that when otl_stream is instantiated with an otl_connect object that is not connected to the database, OTL/OCI10G throws an otl_exception with seemingly random error message and error code. This release introduces the following new #define that can be used as a workaround: #define OTL_STREAM_THROWS_NOT_CONNECTED_TO_DATABASE_EXCEPTION. The #define needs to be enabled before including the OTL header file. OTL will throw the not-connected-to-database exception in case if the otl_connect::connected flag is 0.


18-Feb-2010. New (in OTL 4.0.210, updated):

  • A problem was reported that T-SQL stored procedures that have INSERTs / UPDATEs / DELETEs don't work with OTL. An explanation has been added to the OTL F.A.Q.

20-Jan-2010: New (in 4.0.210):

  • A complition problem was reported when #define OTL_EXCEPTION_IS_DERIVED_FROM_STD_EXCEPTION is defined and g++ 4.1.2 is used. The problem is fixed in this release.
17-Jan-2010: New (in 4.0.209):

  • This release introduces a new Oracle SQL tool neutral syntax for bind variables. The rationale for the new feature is that OTL extended bind variable syntax should be transparent for the SQL tools. Also, see code example 717.


03-Jan-2010: New (in OTL 4.0.208):

  • OTL 4.0.181 introduced otl_stream::check_end_of_row() (and the otl_stream manipulator endr) in order to address the "row-tearing" problem in SELECT statements. This release of OTL extends the check_end_of_row() function (and the endr stream manipulator) to do the end-of-row checking for INSERT / UPDATE / DELETE statements as well as calls to stored procedures / anonymous PL/SQL blocks. the endr (end-of-row) stream manipulator is designed to be similar to C++ standard std::endl and std::ends stream manipulators at least by usage, for example:

          s>>f1>>f2>>endr;
       ...
       o<<f1<<f2<<endr;
          ...
    What it means is that when endr is called at the end of each operator >>/<< chain, it calls otl_stream::check_end_of_row(), which check the "end of row" condition. At least syntactically it looks very similar to the following:

         o<<f1<<f1<<endl;

    endr is recommended for use in long term projects, when over time the table layout may change, and the OTL based C++ code may get out of sync with the table layout. At least, the end-of-row check will catch that. See also the following new code examples:

    • Oracle (OCI7): example 710;
    • Oracle (OCI8 and higher): example 711;
    • DB2 CLI: example 712;
    • MS SQL Server: example 713;
    • Sybase: example 714;
    • MySQL: example 715;
    • PostgreSQL: example 716.

    For database types that are not in the list (above), the same code can be used with appropriate  database type specific #define's, and table columns.
27-Dec-2009: New (in OTL 4.0.207 updated (2) ):

  • The following PostgreSQL code samples have been added (by popular demand!) in order to show how to use OTL with PostgreSQL XML data type. See examples: 706, 707, 708, 709.

20-Dec-2009: New (in OTL 4.0.207 updated):

  • A few questions were asked whether OTL supported Unicode for MySQL / MyODBC or not. OTL/ODBC 4.0.207 has been successfully tested with MySQL / MyODBC 5.1 connector (which is the latest version at this point in time). A set on new OTL code examples has been added to demonstrate how OTL/ODBC works with MyODBC 5.1 connector and Unicode.


13-Dec-2009: New (in OTL 4.0.207):

  • A problem was reported that otl_stream::eof() doesn't return 1 after a call to otl_stream::clean() when the stream was instantiated with a SELECT statement. The problem is fixed in this release.
12-Dec-2009. New (in OTL 4.0.206):

  • A problem was reported that otl_stream::create_stored_proc_call() function doesn't recognize  PL/SQL global stored procedures with no parameters (Oracle). The bug is fixed in this release. Also, an example of a global stored procedure without any parameters was added to code example 153.
29-Nov-2009. New (in OTL 4.0.205 updated):

  • NEW GNU C++ COMPILER VERSION. G++ 4.4.2 was released back in mid-October. OTL 4.0.205 was verified to compile clean and tested with G++ 4.4.2.

26-Nov-2009: New (in OTL 4.0.205):

  • A problem was reported that in OTL/OCI10-11, otl_subscriber class doesn't report simultaneous UPDATE / INSERT / DELETE events that are happening to the same row. The problem is fixed in this release.

    Happy Thanksgiving to everybody in US!
22-Oct-2009. New (in OTL.4.204):

  • A problem was reported in OTL/OCI8-11 (under #define OTL_ORA8-11). The problem is that otl_connect leaks memory when used in a series of unsuccessful rlogon() calls (database connection requests are unsuccessful because, say, TNS name couldn't be resolved, or the database account credentials are invalid). The problem is fixed in this release.
1-Oct-2009. New (in OTL4.0.203):

  • DB2 UDB 9.7 was released this past summer. This release has been successfully compiled and tested with DB2 9.7. DB2 9.7 introduced new data type: timestamp(N), where N in [0..12]. OTL only supports precision up to 9 digits (nanoseconds). So, otl_datetime::frac_pecision can be set as high as 9. I'll implement DB2 9.7 timestamp's precision in [10..12] range at some point in the future when somebody requests the feature.

29-Sep-2009. New (in OTL4.0.203):
20-Sep-2009. New (in OTL4.0.202):

  • Oracle 11g Release 2 (11.2) was released recently. This release of OTL introduces support for Oracle 11.2 via #define OTL_ORA11G_R2. Also, OTL 4.0.202 supports signed 64-bit integers natively for both 32-bit and 64-bit platforms (via OCI 11.2's new feature for signed 64-bit ints) when OTL_ORA11G_R2 is defined. So, there is no need to use string-to-64-bit-int / 64-bit-int-to-string emulation (#define OTL_BIGINT_TO_STR, OTL_STR_TO_BIGINT) for Oracle 11.2. For more detail, see two new code examples for Oracle 11.2:

    • native support for signed 64-bit ints for Oracle 11.2
    • direct path data loading via optimizer hint /*+APPEND_VALUES*/ for Oracle 11.2

  • TimesTen 11.2 was released recently at the same time as Oracle 11.2 (Oracle Corporation actually acquired TimesTen back in 2005). OTL 4.0.202 was tested successfully with TimesTen 11.2
5-Sep-2009. New (in OTL 4.0.201):

  • I was asked to provide a few code examples for the new features introduced in OTL 4.0.200:

    • Oracle OCI7 (classic OCI), examples 690, 691
    • Oracle OCI8 and higher, examples 692, 693
    • MS SQL Server 2008 SNAC, examples 696, 697
    • For other supported database types, examples can be derived from example 690-697.

  • OTL Web Site Stats Report was added to the "Users' Comments / OTL Web Stats" page.

  • A problem was reported that operator<<(ostream&,const otl_value<otl_datetime>&) can't be overloaded because the OTL header file already defines such an operator. New #define OTL_DISABLE_OPERATOR_GT_GT_FOR_OTL_VALUE_OTL_DATETIME is introduced in this release to disable operator<<(ostream&,const otl_value<otl_datetime>&) in the OTL header file.

  • Documentation bug was reported in otl_subscriber::OnException() function. OTL 4.0.200 code cleanup changed the function signature (OTL_CONST_EXCEPTION was added to the function's parameter), but the change was not reflected in the manual. The documentation bug is fixed in this release.
30-Aug-2009. New (in OTL 4.0.200):

Gerrit Hobbelt from Netherlands contributed a few ideas, bug reports, bug fixes, and some code for new functionality. I adapted most of them and had to rework the rest for this new release of OTL. I also fixed a couple of unrelated bugs:

  • BUG: When a fractional part ("fraction") of otl_datetime has more decimal significant digits than MS SQL Server 2005/2008 can handle, say, the fractional part is .1234 for a datetime table column, or .12345678 for a datetime2 table column, MS SQL Server returns an error. It is actually a known feature of MS SQL Server. MSDN Web site describes a workaround, but it isn't clear whether it would work with the rest of the database types, supported by OTL. This release of OTL uses the otl_datetime.frac_precision to truncate the decimal significant digits beyond the specified precision. Such databases as Oracle, or DB2 don't return an error when the second fractional part is larger than the corresponding timestamps data types can handle. However, the timestamp values don't get rounded up or truncated correctly by the databases. So, it's recommended that the timestamp values should be within the specified precision. OTL will truncate the redundant decimal significant digits, which is more correct than it was before.

  • BUG: In two OTL tracing statements, calls to otl_stream::describe_next_out_var(), otl_stream::describe_next_in_var() may return 0 pointers, which may results in the program crash. In this release, the checks for 0 pointers were added to the OTL tracing statements in order to prevent the program crash.

  • BUG: When #define OTL_ODBC is used, an otl_connect object doesn't recover well after an unsuccessful call to SQLAllocHandle(). The otl_connect object could be destroyed and recreated again as a workaround, but it's not desirable. The bug is fixed in this release.

  • BUG: A problem was reported that when Oracle RAW columns are used with :v<raw[XXX]> bind variables, and when a RAW NULL value is written into the stream, then sometimes all the subsequent RAW values get written as NULLs. The bug is fixed in this release.

  • BUG: A problem was reported that when :v<varchar_long> is used in the WHERE clause of a SELECT statement with PostgreSQL, it doesn't work. The problem was that very few database types allow <varchar_long> to be used in a WHERE clause, and OTL didn't implement it properly. The bug is fixed in this release.

  • TYPOS: Two typos were fixed in  "operator >>" in OTL tracing statements. "operator >>"'s were changed to "operator <<" to show the right operator names. Anybody who has "OTL tracing based log parser" scripts may want to run tests to check to see whether the scripts still work correctly.

  • CODE CLEANUP: A few references to otl_exception& within the OTL header file were changed to OTL_CONST_EXCEPTION otl_exception&. #define OTL_CONST_EXCEPTION is defined as const under #define OTL_ANSI_CPP, otherwise it is empty.

  • NEW FUNCTIONALITY: OTL used the US date format in OTL tracing statements. This release introduces the following two new #defines that parameterize the data format in OTL trace statements: OTL_TRACE_FORMAT_DATETIME, OTL_TRACE_FORMAT_TZ_DATETIME.

  • NEW FUNCTIONALITY: This release introduces two new functions:
  • NEW COMPILER VERSION: This release compiles clean with GNU C++ 4.4.1, which was released a month ago.

  • OTL LICENSE: The OTL license hasn't changed since 1996. It was a one clause Free Software license. I heard a fair amount of criticism about the OTL license being a "non-license", etc. This release (and subsequent releases) will use the official, two-clause text of Open BSD license:

    // ORACLE, ODBC and DB2/CLI Template Library, Version 4.0.200,
    // Copyright (C) 1992-2011, Sergei Kuchin (skuchin@gmail.com)
    //
    // This library is free software. Permission to use, copy, modify,
    // and/or distribute this software for any purpose with or without fee
    // is hereby granted, provided that the above copyright notice and
    // this permission notice appear in all copies.
    //
    // THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
    // WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
    // MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
    // ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
    // WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
    // ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
    // OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
    //
    // a.k.a. as Open BSD license

    See the OTL header file (otlv4.h) for more detail .

    The first clause states the same thing as the OTL old license. The second clause states that "The Software" is provided "AS IS". If anybody has any concerns about this change in the text of OTL license, please, let me know.
15-Aug-2009. New (in OTL 4.0.199):

  • Copy constructor and assignment operator were reported to be missing from otl_long_unicode_string class. The bug is fixed in this release.

  • A link to OTL code example 454 (for PostgreSQL) was reported to be broken. The link is fixed in this release.
02-Aug-2009. New (in OTL 4.0.198, updated):

  • OTL 4.0.198 has been successfully tested with the 32-bit PostgreSQL 8.3.7 and the 32-bit pgODBC 8.03.04 driver in Windows. 64-bit pgODBC was reported to have problems when the bulk interface was used (otl_stream buffer size >1). I encourage everybody to report problems like that to the development team of the PostgreSQL ODBC drivers.

08-Jul-2009. New (in OTL 4.0.198, updated):

  • OTL 4.0.198 has been successfully compiled and tested with GNU C++ 4.4.0, which was released a couple of months ago. OTL compiles clean with GNU C++ 4.4.0.

18-Jun-2009. New (in OTL 4.0.198):

  • A problem was reported that MS SQL Server's BACKUP command fails when executed via otl_connect::direct_exec(). The problem is the BACKUP command returns from direct_exec() right away, and the output from the BACKUP commands is supposed to be retrieved by calls to SQLGetDiagRec() in a loop. MS SQL Server has a separate category of such commands: BACKUP, DBCC, etc. direct_exec() deallocates the underlying SQL statement resource right after it gets control back, which is the problem. In order to work around the problem, the otl_stream class has been extended to process MS SQL Server commands such as BACKUP, DBCC, etc. The following new #define and otl_stream function are introduced in this release:


    Also, see examples 688, 689.
6-Jun-2009. New (in OTL 4.0.197):

  • A problem was reported that when OTL defined "Incompatible data types in stream operation" exception is thrown from an INSERT statement based otl_stream, no good rows get inserted into the table. This behavior is inconsistent with, say, when a "primary key violation" exception is thrown. The difference between the primary key violation and the incompatible data types in stream operation exception is that the latter is contained to the OTL code itself. The following new function is introduced in this release for efficient otl_stream recovery: reset_to_last_valid_row().
3-Jun-2009. New (in OTL 4.0.196):

  • A bug was reported that under #define OTL_ODBC_MULTI_MODE, when the following code runs against  a MySQL database, otl_null() doesn't get written into the F2 table column correctly:
    ...
     otl_long_string f2(6000);
     otl_stream o;
     o.set_lob_stream_mode(true);
     o.open(1,
            "insert into test_tab (F1,F2,F3) values"
            "(:f1<int>,:f2<double>,:f3<varchar_long>) ",
            db
           );
     o.set_commit(0); 
     int i,j;
     otl_lob_stream lob;
     for(i=0;i<=7;++i){
      o<<i;
      if(i==0||i==2||i==4||i==6)
        o<<i+12.56;
      else
        o<<otl_null(); // doesn't work correctly
      o<<lob;
      for(j=0;j<50;++j)
       f2[j]='*';
      f2[50]='?';
      f2.set_len(51);

      lob.set_len(51+23);
      lob<<f2;
      f2[22]='?';
      f2.set_len(23);
      lob<<f2;
      lob.close(); 
     }
     db.commit();
     ...

    It's not known at this time whether it's a bug or a feature of MyODBC driver. The same code works correctly at least with DB2 and MS SQL Server ODBC drivers. The otl_stream's internal buffers reinitialization algorithm was changed in this release to work around this "feature" of MyODBC. The change is not specific to MyODBC.
25-May-2009. New (in OTL 4.0.195):

  • A bug was reported that under some circumstances when OTL/ODBC is used with PostgreSQL, and when #define OTL_ODBC_ALTERNATE_RPC is defined, OTL throws the "function sequence error" when a SELECT statement is instantiated in an otl_stream. The bug seems to be different from the bug that was fixed in OTL 4.0.194. The new bug is fixed in this release.
20-May-2009. New (in OTL 4.0.194):

  • A bug was reported that under some circumstances when OTL/ODBC is used with PostgreSQL, and when #define OTL_ODBC_ALTERNATE_RPC is defined, OTL throws the "function sequence error" exception when a SELECT statement is instantiated in an otl_stream. This bug is fixed in this release.

  • #define OTL_ODBC_ALTERNATE_RPC has been added to the PostgreSQL code examples to reflect the latest recommendations for PostgreSQL and OTL.
New (in OTL 4.0.193):

  • A bug was reported that the following function was missing:

    class otl_stream_read_iterator{
    ...
       void get(const char* var_name, double& n);
    ...

    The bug is fixed in this release.
New (in OTL 4.0.192):
New (in OTL 4.0.191):

  • A problem was reported that OTL 4.0.190's new RPC mechanism broke some OTL/ODBC based C++ code. This release reinstates the old RPC, SQLRowCount() mechanism, and adds the following new #define to accommodate the PostgreSQL ODBC driver quirks: OTL_ODBC_ALTERNATE_RPC. Those who need precise RPC counts for PostgreSQL may want to enable the new #define.
New (in OTL 4.0.190):

  • A problem was reported  that PostgreSQL ODBC driver on a bulk INSERT statement returns one row count per inserted row instead of one row count with the total of "rows processed". It doesn't contradict the ODBC specification, though. However, OTL relies on just one row count, which is not what the PostgreSQL ODBC driver returns. OTL 4.0.188 already worked around this problem, but otl_stream::get_rpc() still returns 1 instead of the actual number of affected rows. This release changes the "get rpc" scheme a little bit, at least for ODBCVER >= 3.0 in order to get the right RPC count from the PostgreSQL ODBC driver. This new scheme (ODBC attribute SQL_ATTR_PARAMS_PROCESSED_PTR for SQL statements) works fine with the rest OTL supported database types.
New (in OTL 4.0.189):

  • The following buffer overrun was reported in OTL/ORA7:

     int describe_column
     (otl_column_desc& col,
      const int column_num,
      int& eof_desc)
     {
        sb1 name[241];
        nlen=sizeof(name);
        int temp_rc=odescr
           (&cda,
            column_num,
            &dbsize,
            &dbtype,
            &name[0],
            &nlen,
            &dsize,
            &prec,
            &scale,
            &nullok);
        if(temp_rc==0)name[nlen]=0;
        ...

    It happens very rarely, and it's not clear why it happens at all, when the odescr() function returns success (0), and at the same time it doesn't modify the output nlen parameter. The bug is fixed in this release.
New (in OTL 4.0.188):

  • A problem was reported when OTL is used with the PostgreSQL ODBC driver and an INSERT statement in the bulk interface mode (otl_stream buffer size >1), more rows than expected could be inserted into the table in some cases. OTL relies on the underlying ODBC driver to return a correct "rows processed count" (RPC) when SQLRowCount() is called right after the INSERT statement gets executed. PostgreSQL ODBC driver always returns 1, which makes OTL believe that the RPC from INSERT was 1, and OTL doesn't have to set the SQL_ATTR_PARAMSET_SIZE attribute of the INSERT statement. This release of OTL works around the RPC feature of the PostgreSQL ODBC driver, and inserts the correct number of rows into the table.

  • This release introduces basic support for SQLGetTypeInfo() (data dictionary ODBC/DB2 CLI  function) . The function returns a list of data types supported by the database server. How to call ODBC data dictionary functions, see the corresponding OTL code examples.

  • MySQL OTL code examples have been reworked to show a technique of doing a multi-row INSERT by using the multi-row VALUES clause in an INSERT statement when the otl_stream buffer size is set to 1. This technique is a workaround of the lack of the bulk interface support in MySQL.
New (in OTL 4.0.187):

  • A problem was reported in Oracle 10g, when #define OTL_ORA_TIMESTAMP is defined, that it takes 10 times longer than usual to retrieve Oracle TIMESTAMP values. The Oracle 10g JDBC driver seems to have the same problem. #define OTL_ORA7_STRING_TO_TIMESTAMP/OTL_ORA7_TIMESTAMP_TO_STRING can be used as a workaround for the problem. See example 473 for more detail. The same technique can be used under #define OTL_UNICODE.
New (in OTL 4.0.186):

  • A bug was reported that when in OTL/ODBC when the following flavor of otl_connect::rlogon() is used, the auto-commit parameter has no effect if it's set to 0. The bug is fixed in this release.
New (in OTL 4.0.185):

  • This release introduces the following new #define: OTL_ORA_MAP_BIGINT_TO_LONG. It enables mapping from <bigint> to singed 64-bit longs for 64-bit OCIs on LP64 platforms.

  • OTL_ODBC_TIME_ZONE, OTL_ODBC_STRING_TO_TIMESTAMP, OTL_ODBC_TIMESTAMP_TO_STRING were introduced a few releases ago as a way to work with TIMESTAMP WITH TIME ZONE (PostgreSQL, Oracle) / timestampoffset (MS SQL Server 2008) via ODBC. A bug was reported that when #define OTL_UNICODE is enabled, and the #define's above are enabled as well, the code doesn't return the right results. The bug is fixed in this release. See also examples 685, and 686.

  • A bug was reported that when an empty, numeric, PL/SQL, STL-vector based container is being passed into a stored procedure call, it causes the program to crash. The bug is fixed in this release.
New (in OTL 4.0.184):

  • The OTL online manual is reformatted in order to make it more readable (function lists have been put in HTML tables). Comments and suggestions to improve the manual are welcome.

  • otl_stream::get_dirty_buf_len() is extended to work with SELECT statements, Oracle PL/SQL reference cursors, and stored procedures that return implicit result sets: it returns the number of rows in the stream buffer that are yet to be read.

  • A bug was reported that otl_refcur_stream::rewind() causes the Oracle "fetch out of sequence" error. The reporter of the bug pointed out that to "rewind the reference cursor" means to re-execute the master PL/SQL block the reference cursor belongs to. otl_refcur_stream::rewind() can't be easily eliminated because it is derived from otl_read_stream_interface, when #define OTL_ORA_DECLARE_COMMON_READ_STREAM_INTERFACE is enabled. Instead, otl_refcur_stream::rewind() was made private in this release.

  • A bug was reported that the new "CHECK-END-OF-ROW" feature, which was introduced in OTL 4.0.181, is no longer available. The bug is fixed in this release.

  • A bug was reported that the explicit :#N<raw[XXX]> override for SELECT statements maps to <raw_long>, and that the bulk interface (stream buffer size >1) for Oracle doesn't work as a result. The bug is fixed in this release.
New (in OTL 4.0.183):

  • The following Visaul C++ 8 compilation warning was reported for OTL 4.0.182, line 13840 under #define OTL_FUNC_THROW_SPEC_ON, and #define OTL_ODBC:

    C4297: 'function' : function assumed not to throw an exception but does

    The warning is fixed in this release.
New (in OTL 4.0.182):

  • This release extends the functionality of the otl_stream::create_stored_proc_call() function: it can handle stored procedures / functions that have more than one output reference cursor parameters and also input / output parameters in addition to the reference cursor parameters. The following new global constant was added to indicate the new type ot stored procedures: otl_mixed_refcur_stream_type. See also example 153 for more detail.

New (in OTL 4.0.181):

  • A bug was reported that in a WHERE clause in a SELECT statement, :v<raw[XXX]> doesn't work under #defines OTL_ORAXXX, and the following OTL defined otl_exception gets raised:

         Not all input variables have been initialized

    The problem is fixed in this release.

  • This release introduces otl_stream::check_end_of_row() function (or its operator>>() form) and the "END-OF-ROW check failed" otl_exception, in order to address the "row tearing" problem. The problem is that, say, a SELECT statement has two int columns, and the loop to read rows from the SELECT statement actually reads three int values at a time, for example:

    otl_stream sql(10,"select a, b from some_table",db); // only TWO columns

    while(!sql.eof()){
        int a, b, c;
        sql>>a>>b>>c; // this causes "row-tearing"
        // ...
    }

    The way OTL uses the C++ stream idiom is said to be unsafe, and that it potentially could cause a "row-tearing" problem, which could be very hard to troubleshoot and maintain. The check_end_of_row() function addresses the problem, so, in order to make sure the code is safe and maintainable, here's how the example above can be rewritten:

    otl_stream sql(10,"select a, b from some_table",db); // only TWO columns

    while (!sql.eof()){
        int a, b;
        sql>>a>>b;
        sql.check_end_of_row();
        // ...
    }

    or this way

    otl_stream sql(10,"select a, b from some_table",db); // only TWO columns

    while (!sql.eof()){
        int a, b;
        sql>>a>>b>>endr;
        // ...
    }

    In case if the number of columns in the SELECT statement changes, and the actual loop is not changed, the check_end_of_row() function (or its alternative operator>>() form) will throw this exception.

    I personally don't believe that the OTL design is too bad to cause "row-tearing" that is hard to troubleshoot. Usually,  a SELECT statement has columns of more than one data type, so when the "row is torn", OTL will throw the usual "incompatible data types in stream operation" exception, and it will be obvious that the code is wrong.

    Those developers, who think that the "row tearing" is a serious problem and don't want to use the check_end_of_row() function, can use the OTL stream read iterator, which provides JDBC-like getter interface.

    otl_stream::check_end_of_row() function is not mandatory, so OTL will continue to work as before.


New (in OTL 4.0.180):

  • This release introduces the following new function: otl_stream::get_dirty_buf_len(). The feature was requested by a couple of developers (from Canada and China).

New (in OTL 4.0.179):

  • A documentation bug was reported that :v<long> (bind variable) is not always a signed 32-bit integer on 64-bit platforms. The documentation has been corrected in this release to provide a more detailed explanation on the topic.

  • OTL 4.0.176 was refactored to make undocumented class public data members in OTL private or protected. A compilation problem was reported around the area of those previously public data members. The following method has been added to the otl_stream class (for all flavors of OTL) in order to address the compilation issue:

      int get_connected() const {return connected;}

  • Several projects asked for the following code to be included into the OTL header file:

    #if defined(OTL_INCLUDE_0)
    #include "otl_include_0.h"
    #endif

    The rationale for it is that these projects need to include their own credentials to the OTL header file, so that, when the corresponding binary file gets generated, the credentials will be present in the binary as a string. Therefore, the exact version/build number of the binary can be easily identified.

New (in OTL 4.0.178):

  • The following deficiency was reported in the OTL tracing:

    ...
    (0) MY OTL TRACE ==> otl_stream(this=0012FEFC)::open
    (buffer_size=5, sqlstm=select * from test_tab where f1>=:f<int> 
    and f1<=:ff<int>*2, connect=004332CC); 
    (1) MY OTL TRACE ==> otl_stream(this=0012FEFC)::operator <<
    (char*: ftype=1, placeholder=:f2, value="Name10"); 
    (2) MY OTL TRACE ==> otl_stream, executing SQL Stm=insert into 
    test_tab values(:f1     ,:f2          ), current batch size=10, row offset=0
    ...
    (3) MY OTL TRACE ==> otl_stream, executing SQL Stm=
    select * from test_tab where f1>=:f      and f1<=:ff     *2, buffer size=5
    (4) MY OTL TRACE ==> otl_stream, fetched the first batch 
    of rows, SQL Stm=select * from test_tab where f1>=:f      and f1<=:ff     *2, RPC=5
    ...

    (2), (3), and (4) don't have the stream address, which makes it difficult to keep track of different instances of OTL streams that have the same SQL statement, and especially when the streams are used in different threads. The deficiency is fixed in this release. The OTL trace for the example above is going to look like this:

    ...
    (0) MY OTL TRACE ==> otl_stream(this=0012FEFC)::open
    (buffer_size=5, sqlstm=select * from test_tab 
    where f1>=:f<int> and f1<=:ff<int>*2, connect=004332CC); 
    (1) MY OTL TRACE ==> otl_stream(this=0012FEFC)::operator <<
    (char*: ftype=1, placeholder=:f2, value="Name10"); 
    (2) MY OTL TRACE ==> otl_stream(this=0012FEFC), executing SQL Stm=
    insert into test_tab values(:f1     ,:f2          ), 
    current batch size=10, row offset=0
    ...
    (3) MY OTL TRACE ==> otl_stream(this=0012FECC), executing SQL Stm=
    select * from test_tab where f1>=:f      and f1<=:ff     *2, buffer size=5
    (4) MY OTL TRACE ==> otl_stream(this=0012FECC), fetched the first batch of rows, 
    SQL Stm=select * from test_tab where f1>=:f      and f1<=:ff     *2, RPC=5
    ...

  • A bug was reported that some OTL trace statements are missing for #define OTL_ORAXXX when reference cursors are used. The bug is fixed in this release

New (in OTL 4.0.177):

  • In order to address an issue, the following new question & answer has been added to the OTL F.A.Q.: How to insert or update MS SQL NVARCHAR / NCHAR values larger than 2000 (UTF-16) characters?

  • The previous release (OTL 4.0.176) was refactored to make undocumented class public data members in OTL private or protected. A compilation problem was reported around the area of those previously public data members. The following two  methods have been added to class otl_conn (under #define OTL_ORAXX, where XX>=8) in order to address the compilation issue:

    OCIServer* get_srvhp(){return srvhp;}
    OCISession* get_authp(){return authp;}

  • A problem was reported that when #define OTL_ORA10G is used, an otl_stream stream has :v<refcur,...>, and the stream's buffer size is > 1, the program crashes somewhere deep in the OCI layer. The stream's buffer size should be set to 1 when the stream has :v<refcur>. OTL is supposed to throw the otl_exception with error code of 32034, but it doesn't  The problem is fixed in this release.

New (in OTL 4.0.176):

  • OTL code has been refactored: public data members that weren't part of the documented public interfaces have been made private, or protected. This may break some OTL based code, if the code uses undocumented public data members in the OTL classes, that have been made private/protected in this release of OTL. Let me know right away if this happens, and I'll add appropriate accessor functions to the corresponding OTL classes. The reason for the refactoring of the OTL header file is that developers in many projects (I've heard from many enough) are adopting stricter standards for third-party libraries as well as their own code.

New (in OTL 4.0.175):

  • A bug was reported that otl_stream::create_stored_proc_call() couldn't find a procedure / function name if the procedure / function is available via Oracle synonym mechanism. The bug is fixed in this release: otl_stream::create_stored_proc_call() searches Oracle's data dictionary's user_synonyms and all_synonyms views in case if the procedure / function name is not found anywhere else.

  • A bug was reported that the otl_connect object can't fully recover from a database failure when OTL/ODBC is used with the Oracle ODBC driver for Oracle. OTL/ODBC doesn't deallocate the connect related underlying ODBC handles on otl_connect::logoff(). The assumption was that the ODBC driver's connection handles can be reused on the next otl_connect::rlogon(). Obviously, there are situations when the assumption is not true. The following new #define forces the otl_connect::logoff() to free ODBC connection related handles: OTL_ODBC_LOGOFF_FREES_HANDLES.

  • A bug was reported that otl_refcur_stream doesn't support the RAW type. The bug is fixed in this release.

  • A bug was reported that sometimes otl_subscriber class doesn't report table-wide events because the corresponding event bitmask contains the event bit + OCI_OPCODE_ALLROWS. The bug has been fixed in this release, and otl_subscriber's OnTableAlter(), OnTableDrop(), OnTableChange()'s signatures have been changed.

  • A problem was reported that Oracle CLOB-to-XMLType and XMLType-to_CLOB conversion didn't work for XMLType values larger than 4000 bytes. Example 678 has been added to show how to work around the problem.

  • MS SQL 2005 introduced Multiple Active Result Sets (MARS), which is not enabled by default. More and more applications require this feature to be enabled. This release of OTL introduces the following #define to enable the feature: OTL_ENABLE_MSSQL_MARS.

  • This release introduces support for MS SQL 2008 (new #define OTL_ODBC_MSSQL_2008, new OTL_MSSQL_2008_ODBC_CONNECT mode under #define OTL_ODBC_MULTI_MODE). For more detail, see also examples 679, 680, 681, 682, 683, 684.

  • This release of OTL compiles clean with the latest g++: 4.3.2 (which has been released recently).

New (in OTL 4.0.174):

  • OTL 4.0.173 fixed the LOB-stream-mode-NULL bug for OTL/DB2-CLI, but it introduced the same bug in OTL/OCI. The bug is fixed in this release.

  • ODBC doesn't support timestamps with time zone components yet. However, there is a need to work with "TIMESTAMP WITH TIME ZONE" columns via ODBC. For example, PostgreSQL supports TIMESTAMP WITH TIME ZONE. This version of OTL intrdoces the following new #define to address the need: OTL_ODBC_TIME_ZONE, OTL_ODBC_STRING_TO_TIMESTAMP, OTL_ODBC_TIMESTAMP_TO_STRING. See example 676 for more detail.

    A problem was reported that some versions of the PostgreSQL ODBC driver don't populate the timestamp's fractional part. The new #defines can be used as a workaround to solve the problem. See example 676 for more detail.

  • A problem was reported that xlC version 6 doesn't support template member functions. The bug is fixed in this release (for xlC, #define OTL_NO_TMPL_MEMBER_FUNC_SUPPORT gets enabled by default).

New (in  OTL 4.0.173):

  • The following compilation errors were reported when OTL is being compiled under Debian on AMD64, #define OTL_ODBC_UNIX, and #define OTL_ODBC_MULTI_MODE:

    In file included from test.cpp:12: 
    ./otlv4.h: In member function 'int odbc::otl_sel::first(odbc::otl_cur&,
    int&, int&, int&, int&, int)': 
    ./otlv4.h:12497: error: cannot convert 'SQLULEN*' to 'SQLROWSETSIZE*'
    for argument '4' to 'SQLRETURN SQLExtendedFetch(void*, SQLUSMALLINT,
    SQLROWOFFSET, SQLROWSETSIZE*, SQLUSMALLINT*)' 
    ./otlv4.h: In member function 'int odbc::otl_sel::next(odbc::otl_cur&,
    int&, int&, int&, int&, int)': 
    ./otlv4.h:12599: error: cannot convert 'SQLULEN*' to 'SQLROWSETSIZE*'
    for argument '4' to 'SQLRETURN SQLExtendedFetch(void*, SQLUSMALLINT,
    SQLROWOFFSET, SQLROWSETSIZE*, SQLUSMALLINT*)'

    The problem was due incompatible imlementations of ODBC in the 64-bit Windows, and in the 64-bit Unix ODBC package. If you read the comments in the SQL/ODBC related header files in unixodbc, you'd see that the implementors struggled with interpreting ambiguities in the 64-bit ODBC specification. Nobody says that life is perfect, and there is nothing a few #ifdefs can't fix. The problem is fixed in this release.

  • A bug was reported that when OTL is used with OTL_DB2_CLI., and an otl_stream is opened in the LOB stream mode (otl_stream::set_lob_stream_mode(true)), NULL values, say, in an INSERT statement, don't get processed correctly. Instead of inserting a NULL, OTL inserts a non-NULL value from a row prior to the one with the NULL. The bug is specific to OTL/DB2-CLI. OTL introduced a tweak a couple of years ago that resets the "NULL indicator" / "length" fields for each bind variable / array to the default "non-NULL" right after SQLExcute() is called. Apparently, DB2 CLI has some semi-documented behavior (maybe it's documented, only I couldn't find the right reference, so if somebody could point me to the right spot in the DB2 CLI manual, that would be helpful) that the "NULL indicator" / "length" field is still used by the DB2 CLI layer after SQLExecute() was already called under certain conditions. The bug is fixed in this release.

  • This release introduces the following #define: OTL_EXCEPTION_IS_DERIVED_FROM_STD_EXCEPTION. The #define is a shortcut for "otl_exception is derived std::excetion".

  • A few redundant calls to otl_null() were removed inside the OTL header file.

New (in OTL 4.0.172):

  • When #define OTL_FREETDS_ODBC_WORKAROUNDS is enabled, and, say, an INSERT statement is being executed against a table, even after otl_connect::commit() is called, the table still has an exlusive lock on the rows that were inserted into the table. The bug is fixed in this release. It looks like the bug in FreeTDS, which #define OTL_FREETDS_ODBC_WORKAROUNDS was meant to fix, is fixed now in FreeTDS. Check the FreeTDS Web site for more detail. Those who still use the version of FreeTDS with the original bug can continue using #define OTL_FREETDS_ODBC_WORKAROUNDS.

  • When otl_lob_stream is #defines OTL_ORAXX (where XX>=8), in a situation when a clob/blob gets returned from a PL/SQL stored procedure call and there is another output parameter that precedes the clob/blob, for example:

          begin
         GetClob(:f<char[30],out>, :c<clob,out>);
       end;

    In case if the preceding output parameter is NULL (:f is NULL), the clob (:c) is empty . The bug is fixed in this release. If the same parameters (:f and :c) get returned by a SELECT statement, such a bug doesn't exist.

New (in OTL 4.0.171):

  • #define OTL_VERSION_NUMBER in the OTL header file had a typo, it was set to 0x0400B0L instead of 0x0400AAL. The typo is fixed in this release.

  • The following constructor was broken:

       otl_value<otl_datetime>(const otl_null&):
        v(0),















    ind(true)















  {















  }

    It should be

       otl_value<otl_datetime>(const otl_null&):
        v(),















    ind(true)















  {















  }

    The bug is fixed in this release.

  • When #define OTL_ORA8I, or OTL_ORA9I, or OTL_ORA10G, or OTL_ORA10G_R2, or OTL_ORA11G is defined along with #define OTL_UNICODE, SELECT trigger_body FROM all_triggers only returns 50% of the trigger body text (trigger_body is a LONG column) when read into an otl_long_unicode_string variable. For an unknown reason (I was unable to find any relevant information in the OCI manual, metalink.oracle.com, or on the Internet), the OCI sometimes returns the length of a Unicode LONG value in double-byte characters, and most of the time the length is returned in bytes. Thus, the reason for OTL returning 50% of the LONG text in SELECT trigger_body FROM all_triggers. The OCI always adds a NULL terminator character to a LONG string (in the case of Unicode, it's a double-byte NULL terminator). In this release, OTL has been changed to rely on the NULL terminator instead of the returned length for LONG values.

New (in OTL 4.0.170):

  • When #define OTL_UNICODE is enabled, otl_refcur_stream returns incorrect Unicode characaters for NVARCHAR2 values. OTL didn't set the OCI "Charset Form" correctly for NLS string columns (NVARCHAR2 / NCHAR). The problem is fixed in this release.

  • When #define OTL_ODBC_MULTI_MODE is enabled, OTL doesn't compile with 64-bit Visual C++ 2008 under 64-bit Windows. OTL had a variable declared as SQLUINTEGER (unsigned 32-bit integer). The variable was used in a call to SQLExtendedFetch() as the RowCountPtr parameter. The manual for 32-bit Visual C++ 7.1 said that the RowCountPtr should be SQLUINTEGER*, and in the actual function signature the parameter is SQLULEN*:

    In the doc:
         SQLRETURN SQLExtendedFetch(
              SQLHSTMT     StatementHandle,
              SQLUSMALLINT     FetchOrientation,
              SQLINTEGER     FetchOffset,
              SQLUINTEGER *     RowCountPtr,
              SQLUSMALLINT *     RowStatusArray);

    In the header file:
        SQLRETURN SQL_API SQLExtendedFetch(
              SQLHSTMT           hstmt,
              SQLUSMALLINT       fFetchType,
              SQLLEN             irow,
              SQLULEN            *pcrow,
              SQLUSMALLINT       *rgfRowStatus);

    The discrepancy between the manual and the actual function signature has been corrected in the latest MSDN article on SQLExtendedFetch.

    SQLUINTEGER and SQLULEN are not the same length in 64-bit Windows, that is why there was a compilation error in the 64-bit mode. The problem is fixed in this release.

  • When #define OTL_DB2_CLI is enabled, OTL doesn't compile with DB2 CLI 7.x client's include files: symbol SQL_XML is not defined. The problem is fixed in this release.

  • When #define OTL_ODBC_MSSQL_2005 is enabled, otl_stream_read_iterator is attached to an otl_stream that is opened in the LOB stream mode (otl_stream::set_lob_stream_mode(true)). The stream was opened with a SELECT statement that has a "TIMESTAMP" column, and an "IMAGE" column. Visual C++ 8's runtime's assert on a call to strcat_s() fails. The problem is fixed in this release.

  • OTL_ORA7_TIMESTAMP_TO_STRING and OTL_ORA7_STRING_TO_TIMESTAMP were introduced to support Oracle 9i's TMESTAMP dadatype under #define OTL_ORA7, This release introduces support for same #defines for OTL/OCIx where x >= 9 for easier migration of OTL legacy apps that use OTL_ORA7 to more recent OCIs (9.x, 10.x, 11.x). In example 473, #define OTL_ORA7 can be replaced with OTL_ORA9I, OTL_ORA10G, OTL_ORA10G_R2, or OTL_ORA11G.

New (in OTL 4.0.169):

  • When #define OTL_ORA_UTF8 is enabled, OTL may truncate a string value, for example:'schwarz+weiß' gets truncated to 'schwarz+wei' on a SELECT statement. OTL allocated the size of described VARCHAR / NVARCHAR columns in bytes, which was not sufficient to hold multibyte UTF8 characters that were stored as single bytes in the database. On the database side, character 'ß' is stored in one byte in the case if the database character set is "8-bit European", and the client / C++ side's is UTF8, it requires 2 bytes. If the database character set is UTF8, then there is no such problem. The problem has been fixed in this release

  • A compilation problem was reported for an unspecified version of Informix for Linux when #define OTL_INFORMIX_CLI is enabled. I asked the guy (presumably someone from P.R.C.) who reported the problem to email me his version of the Informix header files and object libraries.  He emailed me everything, I fixed the problem, emailed him the patch, but I haven't heard from him since.

    The compilation bug has been fixed in this release.

  • A problem was reported that when example 378 (for Oracle 8.x and higher) is rewritten to use #define OTL_UNICODE, otl_long_unicode_string, and std::wcout, the output looks like this:

       f1=1
          chunk #1, f2=*?, len=4001
       f1=2
          chunk #1, f2=##, len=6000
          chunk #2, f2=# , len=12000
          chunk #3, f2=# , len=12000
          chunk #4, f2=# , len=-9996
       f1=3
          chunk #1, f2=*?, len=4001

    It's obviously incorrect. The bug reporter also sent me a fix along with the bug report. The fix has been merged into this release.

New (in OTL 4.0.168):

  • Some projects need to be able to connect to multiple database types at the same time via ODBC. For example, to MySQL and TimesTen, or to MS SQL 2005 and Sybase. OTL has specific #define's for some database types (like #define OTL_ODBC_MSSQL_2005, or #define OTL_ODBC_POSTGRESQL, etc.), which makes it impossible to connect to multiple database types at the same time. In order to address the issue, this release introduces #define OTL_ODBC_MULTI_MODE, and otl_connect::set_connection_mode(). For more detail, see example 675.

New (in OTL 4.0.167):

  • In this release or higher, #define OTL_UNCAUGHT_EXCEPTION_OWN_NAMESPACE is obsolete. The underlying problem  when OTL gets compiled with #define OTL_STLPORT has been fixed. It's recommended to comment out  #define.OTL_UNCAUGHT_EXCEPTION_OWN_NAMESPACE.

  • Some project still use Visual C++ 6.0. OTL 4.0.162 made #define OTL_UNCAUGHT_EXCEPTION_ON the default. VC 6.0's std::uncaught_exception() always returns true, meaning that it doesn't work the way the C++ standard defines. This release stops enabling  #define OTL_UNCAUGHT_EXCEPTION_ON for VC 6.0 for backward compatibility in order to allow the OTL based  projects that are stiil using VC 6.0 to continue to work.

  • This release introduces basic support for DB2 XML, MS SQL XML, and Oracle XMLType datatypes. For more detail, see the following code examples:

  • This release compiles clean with g++ 4.3.0 when the following command line options are enabled:

    • -Wshadow

    • -Wall

    • -Wundef

    • -Wpointer-arith

    • -Wunused

    • -Wreorder

    • -Wcast-qual

    • -Wno-uninitialized

    • -Wcast-align

    • -Wconversion

    • -Wsign-compare

    • -Werror

    • -Wwrite-strings

    • -Wcomments

    • -Wunused-variable

    • -Wparentheses

    • -ansi

    • -Wformat

    • -Wstrict-aliasing=2

    • -Wstrict-null-sentinel

    • -fstrict-aliasing

    • -Wold-style-cast

    • -Woverloaded-virtual

    • -Wctor-dtor-privacy

    • -Wnon-virtual-dtor

    • -Wsign-promo

    • -Wextra

    • -Wfloat-equal

    • -Wmissing-noreturn

    • -Wmissing-format-attribute

    • -Weffc++

  • This release has been reworked to compile clean with g++'s -Weffc++. effc++ warns about violations of the following style guidelines from Scott Meyers™ Effective C++ book:

    • Item 6: Distinguish between prefix and postfix forms of increment and decrement operators.

    • Item 7: Never overload operators "&&", "||", or ",".

    • Item 11: Define a copy constructor and an assignment operator for classes with dynamically allocated memory.

    • Item 12: Prefer initialization to assignment in constructors.

    • Item 14: Make destructors virtual in base classes.

    • Item 15: Have "operator=" return a reference to *this.

    • Item 23: Don't try to return a reference when you must return an object.

New (in OTL 4.0.166):

  • A bug was reported that otl_connect::rollback() has no effect when OTL is used in a combination with FreeTDS/ODBC against MS SQL. It turned out that the feature wasn't implemnted in FreeTDS/ODBC. In order to work around the problem, this release introduces #define OTL_FREETDS_ODBC_WORKAROUNDS. See MS SQL Server / FreeTDS ODBC examples for more detail. The new #define is recommended for use until a fix becomes available.

    FreeTDS/ODBC seems to have a similar problem with otl_connect::rlogon()'s auto-commit with Sybase. However, the new #define is not recommended as a workaround for Sybase, because otl_connect::auto_commit_off() and otl_connect::auto_commit_on() functions seem to work with Sybase. Until a fix becomes available, auto_commit_on() / auto_commit_off() are recommended for use. See for Sybase SQL Server / FreeTDS ODBC examples more detail.

    Also, FreeTDS/ODBC doesn't seem to support "transaction isolation" level, that is, otl_connect::set_transaction_isolation_level() has no effect. Until the feature is implemented in FreeTDS/ODBC, it's recommended that explicit server side settings should be used instead. For example, MS SQL supports an explicit (NOLOCK) option on the FROM clause in a SELECT statement. Sybase has the "set transaction isolation level X" command to set an explicit, session-wide transaction isolation level. For more detail, see examples 516 (MS SQL), and 561 (Sybase).

    Many thanks to James Lowden the maintainer of FreeTDS for clarifying the issues. More issues may be uncovered as more developers begin using OTL with FreeTDS/ODBC. I'd recommend those developers to subsribe to the FreeTDS mailing list to keep track of the latest developments.


New (in OTL 4.0.165):

  • A bug was reported that OTL/OCI crashes (memory access violation) the program when a refcur bind variable is used, and the otl_stream buffer size is greater than 1. The stream buffer size actually has to be set to 1 in this case. In order to diagnose cases like this one, OTL introduces the following new otl_exception: code=32034, otl_stream buffer size should be 1 when refcur or plsql table is used. OTL should throw the new exception instead of memory access violation.

  • A new default for #define OTL_UNCAUGHT_EXCEPTION_ON was introduced in OTL 4.0.162. The #define was supposed to wortk when #define OTL_STL is defined. This release extends #define OTL_UNCAUGHT_EXCEPTION_ON to work without requiring OTL_STL to be defined first, and OTL_UNCAUGHT_EXCEPTION_ON is on by default. If anybody has compilation issues with this new arrangement, let me know, and we'd work something out.

New (in OTL 4.0.164):

  • A bug was reported that when #define OTL_ORA10G_R2 is used, and a PL/SQL table of NUMBER(14,4) from  a PL/SQL package gets bound with a :var<double,out[XX]> variable, an otl_exception gets thrown that has the following Oracle error message:

    PLS-00418: array bind type must match PL/SQL table row type

    The bug is fixed in this release. OCI10/11 has flaky support for PL/SQL tables of BINARY_FLOAT / BINARY_DOUBLE, which makes it impossible to implement any reliable scheme for supporting PL/SQL tables of NUMBER and PL/SQL table of BINARY_FLOAT /BINARY_DOUBLE without introducing special data types (for example, "binary_float" in addition to "float", which is already binary) for PL/SQL tables BINARY_FLOAT / BINARY_DOUBLE. Until Oracle straightens out the support for PL/SQL tables of BINARY_FLOAT / BINARY_DOUBLE, and the appropriate changes are made to OTL, it's recommended to use PL/SQL tables of NUMBERs instead.

  • A bug was reported that when #define UNICODE / _UNICODE, OTL_UNICODE, and OTL_ODBC are defined, and when a table has an accented column name in it (for example,: assigné),  function SQLDescribeCol() returns bad information about the column, which results in the program's crash. The second bug related to accented column names was reported when otl_connect::direct_exec() function is used with accented table columns. The bugs were due to the fact that a type cast to a signed char* was used instead of unsigned char*. The bugs are fixed in this release.

    OTL doesn't have full support for UTF16 based SQL statement text. However, SQL statements based on one-byte character sets  should be fully supported.

New (in OTL 4.0.163):

  • This release compiles clean with Visual C++ 9 (Visual Studio 2008, which came out recently).

  • An OTL defined exception has been changed in this release to the following in order to carry more useful information:

    Writing CLOB/BLOB in stream mode: actual size is greater than specified, trying to store X1 bytes / Unicode characters at offset X2. New length: X3 would be bigger than length of lob: X4.

    The text of the exception (of the otl_exception class) carries more information than before to simplify troubleshooting of incorrect custom C++ code. This change was originally submitted as a patch and merged into this release with some modifications.

  • The following minor error was reported in OTL code example 383: 

    The "drop table test_tab" statement silently fails when the table does
    not exist (as expected) but since db.commit() isn't called immediately
    afterward the transaction is still open and left in an error status.  
    Any statement issued after that will fail with the following error:
    "ERROR:  current transaction is aborted, commands ignored until end of
    transaction block"

    Similar errors were present in some of the PostgreSQL examples. All the errors have been fixed in this release.

New (in OTL 4.0.162):

  • This release introduces the following code examples for Informix CLI: examples 625-658. OTL has supported Informix via Informix CLI for a few years. Informix CLI in Windows is indistinguishable from ODBC, so in Windows #define OTL_ODBC can used with Informix CLI. In Unix, #define OTL_INFORMIX_CLI can be used.

  • A bug was reported that when OTL is used with TimesTen 7.0.2 or higher, it is impossible to set the TT Prefetch size to 0, which enables the default TT Prefetch sizes (see TT manuals for more detail). The bug is fixed is this release. See also the stream buffer size description.

  • A compilation bug was reported that when OTL is being compiled with g++ with -ansi commannd line option, and  #define OTL_ACE. A patch was posted in the OTL discussion forum. The patch has been merged with this release.

  • The following formatting problem was reported when OTL tracing is enabled:

    MY OTL TRACE ==> otl_connect(this=0042A1D8)::rlogon(connect_str="/******@mssql", auto_commit=0);

    The user id is missing from the trace. The problem is fixed in this release.

  • In order to address user complaints about aborting / terminating programs in the case of a cascade of OTL exceptions, the following #define has been made the default in this release: #define OTL_UNCAUGHT_EXCEPTION_ON. From the beginning, OTL, according to some C++ gurus who would hit me in the head, should not have had "throwing destructors". See more detail on the history of the question here.

    By completely eliminating throwing desctructors, OTL would have broken a lot of existing custom code (the code would have to be rewritten), so the decision had been made to introduce #define OTL_UNCAUGHT_EXCEPTION_ON.

    Only really old C++ compilers like Visual C++ 6.0 don't support the required C++ function (uncaught_exception()). If anybody experience any problems with this new default setting, let me know, we would work something out.

    Those who do not want OTL destructors to "throw" can use     #define OTL_DESTRUCTORS_DO_NOT_THROW, but they would have to call the close() function all otl_streams explicitly, before each stream goes out scope.

New (in OTL 4.0.161):

  • A bug was reported that when #define OTL_ORA10G (or OTL_ORA10G_R2, or OTL_ORA11G) is used against an Oracle 9i database backend, the OCI10 native SQLT_BDOUBLE / SQLT_BFLOAT bindings don't work. The bug is fixed in this release, and the fix can be enabled with #define OTL_ORA_LEGACY_NUMERIC_TYPES.

  • A bug was reported that when #defines OTL_ORA8 / 8I/ 9I / 10G / 10G_R2 / 11G are used with otl_lob_stream, and when the value of a CLOB/BLOB in a table goes from, say a size > 0 to the size of 0, the actual value doesn't get set to the size of 0. The bug fixed in this release.

  • A bug was reported that when #define OTL_ORA8 / 8I / 9I / 10G / 10G_R2 / 11G is defined along with #define OTL_ODBC_TIMESTEN_UNIX / OTL_ODBC_TIMESTEN_WINDOWS, and the resulting executable is linked with both the OCI and the TimesTen object libraries, the program's performance (the Oracle side in particular) degrades tenfold. The bug is fixed in this release.

  • A bug was reported that when an otl_exception gets thrown and an error is caused by an nchar or an nclob bind variable, the var_info member of the otl_exception isn't populated correctly. In particular, the data type is blank isntead of NCHAR, or NLOB. The bug is fixed in this release.

  • This release introduces the following new #define OTL_ODBC_ENTERPRISEDB. The #define can be used with Enterprise DB, a commecial, Oracle compatible offshoot of PostgreSQL. Also, see examples 586-624 for more detail.

New (in OTL 4.0.160):

  • Oracle 11g Release 1 came out recently. OTL introduces the following new #define to start the OTL/OCI11g series: #define OTL_ORA11G.

  • When OTL_ODBC, OTL_BIGINT, OTL_STR_TO_BIGINT, and OTL_BIGINT_TO_STR are defined, OTL does not compile with VC++ 2005, and xlC (C++ in AIX). The bug is fixed in this release.

  • When OTL_DEFAULT_STRING_NULL_TO_VAL, OTL_UNICODE are defined together, and otl_refcur_stream is used, the default string value that the OTL_DEFAULT_STRING_NULL_VAL defines doesn't get returned correctly in the case if the actual value to be returned is NULL. The bug is fixed in this release.

  • otl_stream_read_iterator::get(const int pos, unsigned char* s) was reported to have a compilation error on an unspecified C++ compiler, on an unspecified platform. The proposed code change was merged into this release. .

New (in OTL 4.0.159):

  • In OTL 4.0.158, a bug was introduced which causes the following error message when an <int> bind variable is used:

    [Microsoft][SQL Native Client][SQL Server]Invalid 2-Parameter (''): The
    0x23 data typ is a LOB marked as obsolete and used as output parameter.
    Obsolete types are not supported as output parameters.

    The bug is fixed in this release.

  • C++Builder 2007 generates the following error when compiling OTL:

        Error error 2285: E2285 Could not find a match for 'operator otl_ora8_inout_stream::operator>>(float)

    There are similar errors in the rest of the numeric operators >>() of the same class. The error goes away when #define OTL_NO_TMPL_MEMBER_FUNC_SUPPORT is enabled. The bug is fixed in this release by enabling the #define for Borland C++ by default.

  • Michael Shishkin from Russia contributed the otl_subscriber class that uses the Oracle Database Change Notification Interface to implement a more convenient publish / subscribe mechanism compared to the straight OCI. The otl_subscriber class is optional and can be enabled via #define OTL_ORA_SUBSCRIBE. See also example 585.

New in (OTL 4.0.158):

  • When #define OTL_UNICODE_EXCEPTION_AND_RLOGON and #define _UNICODE / UNICODE (standard C/C++ #defines for Unicode applications) are enabled, and otl_connect::rlogon() is used with ODBC-like style connect strings ("UID=scott;PWD=tiger;DSN=mssql", etc.), the underlying SQLDriverConnect() call may crash the program, because the size of the output string buffer was specified in bytes instead of wide characters. The bug is fixed in this release:

           Before (line 9678):

           status=SQLDriverConnect
            (hdbc,
             0,
             temp_connect_str2,
             OTL_SCAST(short,len),
             out_str,
             sizeof(out_str),
             &out_len,
             SQL_DRIVER_NOPROMPT);

           Now (line 9678):

       status=SQLDriverConnect
        (hdbc,
         0,
         temp_connect_str2,
         OTL_SCAST(short,len),
         out_str,
         sizeof(out_str)    /sizeof(SQLWCHAR),
         &out_len,
         SQL_DRIVER_NOPROMPT);

  • In OTL/OCI8/9/10  a break statetement was missing in

    27195  void open
    27196  (const otl_stream_buffer_size_type arr_size,
            const char* sqlstm,
            otl_connect& db,
            const char* ref_cur_placeholder=0,
            const char* sqlstm_label=0)
            OTL_THROWS_OTL_EXCEPTION
              ...
    27213     case otl_select_stream_type:
                 ...
                     break;

    The bug is fixed is this release.

  • Following new #define is introduced: OTL_MAP_LONG_TO_SQL_C_SBIGINT. It maps 64-bit longs into SQL_C_BIGINT instead of SQL_C_SLONG in OTL/ODBC/DB2-CLI.

  • The question on MySQL in the F.A.Q was corrected to explain that InnoDB type tables can be used with OTL.

New in (OTL 4.0.157):

  • A problem was reported that OTL doesn't compile with aCC (HP ANSI C++ B3910B A.03.63), and it requires #define OTL_NO_TMPL_MEMBER_FUNC_SUPPORT to be enabled. The problem is fixed in this release, and the aCC compiler has been added to the list of C++ compilers for which the "no template member function support" feature is enabled by default.

  • A problem was reported that when OTL is used with STL Port, and when STL Port is not configured to expose some standard C++ functions like uncaught_exception() in STL Port's own namespace _STL, and when #define OTL_UNCAUGHT_EXCEPTION_ON is enabled, the C++ compiler complains that the uncaught_exception() function is not defined in the _STL namespace. In order to fix the problem, the following new #define may be used: OTL_UNCAUGHT_EXCEPTION_OWN_NAMESPACE.

    Of course, the STL Port can be reconfigured and rebuilt in order to expose the uncaught_exception() in the _STL namespace, but sometimes it's not an option.

  • OTL 4.0.156 introduced a bug in its new support for BINARY_DOUBLE: when an actual BINARY_DOUBLE column gets SELECTed from a table, it causes a program's crash. The bug is fixed in this release.

New (in OTL 4.0.156):

  • A problem was reported that when OTL is used with the OCI 10g, and BINARY_DOUBLE, there is a roundup error in the 17th and 16th decimal singificant digits, for example when 1.6666666666666667E+000 gets inserted into a BINARY_DOUBLE column in a table via OTL, the resulting value that is stored in the table is 1.6666666666666701E+000. A similar thing happens with BINARY_FLOAT values. In order to bind <float> and <double> with Oracle NUMBERs, OTL used SQLT_FLT (with sizeof(float), and sizeof(double), respectively) as an external OCI datatype. The same SQLT_FLT was used to bind <float> and <double> with BINARY_FLOAT, and BINARY_DOUBLE. The OCI manual didn't specifiy any ramifications about doing that.

    It appears that better alternatives would be SQLT_BFLOAT and SQLT_BDOUBLE (OCI manual only mentioned that performance would be better, and nothing else). It also turned out that SQl_BFLOAT and SQLT_BDOUBLE work better / have better precision, even when bound with NUMBERs.

    As I understood the mechanism, when you bind a <double> as SQLT_BDOUBLE with, say, NUMBER or BINARY_DOUBLE, or with any other numeric type, a <double> value gets sent across the wire / SQL*Net as is, as opposed to a <double> value would be converted into some wire format by the OCI, if the <double> variable is bound as SQLT_FLT (sizof(double)),. In the latter case the conversion loses the 16th and the 17th decimal significant digits (aka roundup).

    The bug has been fixed in this release. When #define OTL_ORA10G or #define OTL_ORA10G_R2 is defined, <float> and <double> get bound as SQLT_BFLOAT and SQLT_BDOUBLE respectively, which provides better precision.

New (int OTL 4.0.155):

  • Under #define OTL_ORA_TIMESTAMP, OTL tracing didn't trace Oracle TIMESTAMP / DATE values. The bug is fixed in this release.

New (in OTL 4.0.154):

  • Oracle 10G R2 (10.2) introduced the following bug:

    When a 'alter session set NLS%' statement is first executed in parse only mode and then in normal mode, the setting changed does not get reflected. Bug # in metalink.oracle.com is 4904743. Oracle promised to fix the bug in Oracle 11g.

    OTL used PARSE ONLY to  implement otl_connect::syntax_check(), and PARSE ONLY + normal mode for direc_exec() functions. So, the bug broke the OTL logic for 'alter session set NLS%' commands. This release works around the bug.

  • This release introduces native support for TimesTen via the following new #defines: OTL_ODBC_TIMESTEN_WIN, OTL_ODBC_TIMESTEN_UNIX. Code examples for TimesTen have been updated to reflect the new feature.

New (in OTL 4.0.153):

  • OTL compiles clean with the latest G++ (GCC 4.2)

  • OTL compiles clean with Visual C++ 2005 (version 8.0) without disabling warning C4996: #pragma warning (disable:4996). Old C string functions have been replaced  with more secure VC++ 8.0 string functions (for example, strcpy_s(), strcat_s(), sprintf_s()) whenever possible, without breaking the existing design too much. Of course, the new string functions get enabled only when OTL is being compiled with VC++ 8.0.

  • Actual code examples have been reworked to compile clean with Visual C++ 8.0.

New  (in OTL 4.0.152):

  • A bug was reported that OTL 4.0.147 - OTl 4.0.151 broke inout bind variables' behavior. The actual problem was that when NULL gets written into an inout variable, the OTL stream's internal NULL indicator doesn't get set to non-NULL on the output in case if the variable receives a non-NULL value from the database. The bug was introduced  by an optimization tweak in OTL 4.0.147, and fixed in this release.

  • (Updated): There is an open source ODBC driver for Linux/Unix/Windows for accessing MS SQL 7.0 / 2000 / 2005 and Sybase 10.x / 11.x / 12.x / 15.x:. It's called FreeTDS. At this point time, the FreeTDS ODBC driver (version 0.63) is high enough quality to work with OTL. The following FreeTDS based sets of code examples have been added: MS SQL Server / FreeTDS ODBC, Sybase SQL Server / FreeTDS ODBC.

    FreeTDS ODBC supports the bulk interface, calls to stored procedures, etc. It doesn't support some features that are supported by the native MS SQL and Sybase ODBC drivers, but for a free ODBC driver, it's good enough performance-wise, and feature-wise. And it provides access to MS SQL from Linux / Unix. Sybase native ODBC driver is available for Windows and Linux. So, FreeTDS ODBC can be used for accessing Sybase from Solaris and AIX (or any other supported platform that FreeTDS supports). In non-Windows platforms, FreeTDS ODBC can be used with unixODBC, or iODBC.

  • (Updated):TimesTen code examples have been tested against TimesTen 7.0.

New (in OTL 4.0.151):

New (in OTL 4.0.150):

  • A problem was reported that OTL throws an "Invalid Handle" (OCI) exception when a PL/SQL block / stored procedure returns an uninitialized CLOB / BLOB locator, and when the CLOB / BLOB is being written to / read from via an otl_lob_stream. To address the problem, a new function has been added to the lob stream class: is_initialized().

  • This release introduces support for Oracle UTF8 via the following new #define: #define OTL_ORA_UTF8. See also examples for Oracle 9i, UTF8, and Oracle 10g, UTF8.

New (in OTL 4.0.149):

  • A memory leak was reported in otl_stream, which turned out to be a call to otl_stream::open() in a loop without a matching call to otl_stream::close().  In order to simplify debugging of problems like that, this release introduces the following two new OTL defined exceptions:

    • code 32030, otl_stream is already open

    • code 32031, otl_connect is already connected

  • DB2 zOS does not normally release row locks on a SELECT statement, even after all the rows were already fetched, and even the underlying cursor was closed. In order to release the row locks, the SELECT statement has to be "committed" with an explicit otl_connect::commit() call. The thing gets worse when on the DB2 zOS side, a timeout on "inactive DB2 threads that lock resources" is set, which results in a forced disconnect. DB2 CLI manual recommends to explicitly set the SQL statement's SQL_ATTR_CLOSE_BEHAVIOR attribute to SQL_CC_RELEASE (read locks are released), in which case the DB2 server attempts to release read locks. No guarantees, of course.

    This release sets the SQL statement's attribute to the recommended value in case if the SELECT statement's isolation level was either uncommitted read (UR), or cursor stability (CS, aka "read committed").

  • In this release, for DB2 CLI, all calls to SQLFreeStmt(hstmt,SQL_CLOSE) were replaced with SQLCloseCursor(hstmt). The difference between the two types of calls is that the latter will return a DB2 CLI error if the call is made on a closed cursor. SQLFreeStmt(hstmt,SQL_CLOSE) will return a "success". This was done in order to simplify debugging of potential problems with cursor management.

New (in OTL 4.0.148):

  • #define OTL_TRACE_ENABLE_STREAM_LABELS. When this #define is enabled, OTL trace records SQL statement labels instead of the bodies of the SQL statements. It is useful for reducing the size of the OTL trace.

  • #define OTL_NO_TMPL_MEMBER_FUNC_SUPPORT was introduced in OTL 4.0.127. The problem was reported that Visual C++ 7.0 (2002) does not support / has a bug in template member functions. The OTL header file will automatically enable the #define for Visual C++ 7.0 from this release and on. Visual C++ 7.1, and 8.0 do not have the same problem / bug.


New (in OTL 4.0.147):

  • Internal code cleanup. Also, otl_stream::flush() function has been optimized by 2-2.5%. Mileage may vary from one C++ compiler to another.

  • Following new #defines have been introduced: OTL_ORA7_TIMESTAMP_TO_STRING,OTL_ORA7_STRING_TO_TIMESTAMP.
    The #defines should be used when there is a need to use OCI7 and Oracle 9i/10g TIMESTAMPs in order to enhance legacy applications. See also example 473.

  • Examples for SQLite have been updated to match what's available in SQLite 3.3.x, and SQLite ODBC driver 0.71.

New (in OTL 4.0.146):

  • OTL/ODBC didn't compile with the Polyhedra ODBC header files. The bug has been fixed in this release.

  • Description of #define OTL_ODBC_POSTGRESQL as well as the PostgreSQL examples have been changed.

  • The F.A.Q. has more answers the following questions:

    • Why nested queries with bind variables do not work in MS SQL Server?

    • How do I connect to my database without creating an ODBC DSN?

New (in OTL 4.0.145):

  • Basic support for MS SQL 2005 VARCHAR(MAX) and VARBINARY(MAX) is introduced in this release. VARCHAR(MAX) and VARBINARY(MAX) data types are "replacements" for "old" TEXT and IMAGE. The new types are not quite backward compatible as far as MS SQL ODBC is concerned. Basically it works, only the OTL LOB stream mode doesn't work. I'd appreciate very much if somebody could  point me to an ODBC based code example that demonstrates how to use VARCHAR(MAX) / VARBINARY(MAX)  in piece-wise read/write modes.

  • The following code examples have been introduced to demonstrate more [new] features and code techniques:

  • This release enforces the minimum size of 2 characters in :var<char[xxx]> declarations. The reason is that char[1] is invalid because OTL char[xxx] variables are null terminated strings. #define OTL_ADD_NULL_TERMINATOR_TO_STRING_SIZE adds one character to the string length, which makes :var<char[1]> a valid declaration.

  • OTL 4.0.138 relaxed the requirement of presetting the LOB length before the first chunk of the LOB gets written to the LOB stream (otl_lob_stream), which changed the ODBC / DB2 CLI function call sequence. A bug was reported that when a LOB stream is used for writing the LOB value, and the stream gets destroyed before the end of the row, which LOB was written to, it causes the "invaid function call sequence" error. The actual error message is different in different database types,. The bug is fixed in this release. This problem affects only ODBC and DB2 CLI applications, and only if the LOB stream is destroyed before the end of the row. The following [long] piece of code demonstrates the problem:

    void insert()
    // insert rows into table
    {
     otl_long_string f2(6000); // define long string variable
     otl_stream o; // defined an otl_stream variable
     o.set_lob_stream_mode(true);
      // set the "lob stream mode" flag
     o.open(1,
      // buffer size has to be set to 1 for operations with LOBs
            "insert into test_tab "
            "values(:f1<int>,:f2<varchar_long>, "
            ":f3<varchar_long>) ",
                // SQL statement
            db // connect object
           );
     o.set_commit(0);
      // setting stream "auto-commit" to "off". It is required
      // when LOB stream mode is used.

     int i,j;
     otl_lob_stream *lob;
      // LOB stream for reading/writing unlimited number
      // of bytes regardless of the buffer size.
     otl_lob_stream *lob2;
      // LOB stream for reading/writing unlimited number
      // of bytes regardless of the buffer size.

     for(i=1;i<=20;++i){
      lob = new otl_lob_stream;
      lob2 = new otl_lob_stream;

      o<<i;
      o<<*lob; // Initialize otl_lob_stream by writing it
              // into otl_stream.
      o<<*lob2; // Initialize otl_lob_stream by writing it
              // into otl_stream.

      for(j=0;j<5000;++j)
       f2[j]='*';
      f2[5000]='?';
      f2.set_len(5001);

      // OTL < 4.0.138
      lob->set_len(5001+2123); // setting the total  size of
                              // the TEXT to be written.
        *lob<<f2; // writing first chunk of the TEXT into lob


      f2[2122]='?';
      f2.set_len(2123); // setting the size of the second chunk

      *lob<<f2; // writing the second chunk of the TEXT into lob
      lob->close(); // closing the otl_lob_stream

      delete lob;
       // here is a problem (in OTL 4.0.138 - 4.0.144),
       // OK in 4.0.145 (this release)
      // not the end of the row yet
      for(j=0;j<5000;++j)
       f2[j]='*';
      f2[5000]='?';
      f2.set_len(5001);

       // OTL < 4.0.138

      lob2->set_len(5001+2123); // setting the total  size of
                              // the TEXT to be written.
      *lob2<<f2; // writing first chunk of the TEXT into lob

      f2[2122]='?';
      f2.set_len(2123); // setting the size of the second chunk

      *lob2<<f2; // writing the second chunk of the TEXT into lob
      lob2->close(); // closing the otl_lob_stream
      // end of the row
          //delete lob; // deleting here is OK
      delete lob2;
     }


New (in OTL 4.0.144):

  • OTL (4.0.129 - 4.0.143) did not compile with the real OCI 8.0 header files. There was the following compilation error:

         C2065: 'OCI_PARSE_ONLY' : undeclared identifier

    The error is fixed in this release..

  • PostgreSQL 8.2 is out. This release has been successfully tested with PostgreSQL 8.2.

Continued on next page