Oracle, Odbc and DB2-CLI Template Library, Version 4.0

What's New

Current release number of the OTL header file

4.0.168.

OTL 4.0.168 is now released.

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

From OTL 3.0.0 to OTL 4.0.168: summary of new features and bug fixes


Feature	Comment
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: Oracle: 659, 660, 661, 662 Oracle UTF-8: 663, 664 DB2: 671, 672 DB2 Unicode: 673, 674 MS SQL: 665, 666 MS SQL Unicode: 669, 670 MS SQL with FreeTDS: 667, 668 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): This release introduces better support for MS SQL Server 2005 via the following new define: #define OTL_ODBC_MSSQL_2005. The main difference between OTL_ODBC and OTL_ODBC_MSQL_2005 is that the latter has otl_lob_stream support for VARCHAR(MAX), VARBINARY(MAX), and NVARCHAR(MAX). Examples for MS SQL Server / ODBC and MS SQL Server Unicode / ODBC have been updated. For more detail, see examples 497, 498, 499, 500, 501.
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: Example 468 (MS SQL Server 2005 and VARCHAR(MAX)) Example 469 (MS SQL Server 2005 and VARBINARY(MAX)) Example 470 (MS SQL Server 2005, INSERT with OUTPUT clause) Example 471 (DB2, stored procedure with output parameters and a return code) Example 472 (DB2, Insert/Implicit Result Set (Stored Proc) /Update) 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

Go Home

Permission to use, copy, modify and redistribute this document for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies.