otl3_whatn_1.htm

ISO_C++:C++_OTL开发文档

            <br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.123):<br>
        <br>
        <ul>
          <li>OTL 4.0.122 introduced support for the MS SQL <a
 href="#TIMESTAMP_40122">TIMESTAMP</a> / RowVersion data type. This
release introduces support for the same data type when #define <a
 href="otl3_compile.htm#OTL_UNICODE">OTL_UNICODE</a> is enabled.
TIMESTAMP / RowVersion values get converted into char[17]. Only in this
case the characters are 2-byte Unicode characters. <br>
            <br>
          </li>
          <li>When the same otl_stream variable gets reused multiple
times, and <a href="otl3_stream_class.htm#describe_select">describe_select</a>()
is used, <a href="otl3_stream_class.htm#otl_column_desc">otl_column_desc</a>
may return an incorrect <span style="font-style: italic;">name</span>
(column name). It happens when names for, say, column 1, from two
consecutive calls to describe_select() had the same length. The bug is
fixed in this release.<br>
            <br>
          </li>
          <li>OTL had only basic support for Unicode string data, and
it didn't support Unicode userid/password@DSN,&nbsp; Unicode error
messages, Unicode ODBC drivers, and Unicode SQL. This release
takes a few steps further and implements the following features:<br>
            <br>
          </li>
          <ul>
            <li><span style="font-style: italic;">Support for Unicode
ODBC drivers</span>. Unicode may be enabled for ODBC / DB2 CLI by
defining <span style="font-family: monospace;">#define UNICODE</span>
and/or <span style="font-family: monospace;">#define _UNICODE</span>.
The <span style="font-family: monospace;">#define</span>s enable the
Unicode ODBC function prototypes. Starting with this release and
on,&nbsp; OTL uses Unicode ODBC functions when&nbsp; the <span
 style="font-family: monospace;">#define UNICODE </span>/<span
 style="font-family: monospace;"> _UNICODE</span> is enabled / defined
(for example, when a project in Visual C++ Studio enables Unicode).<br>
              <br>
            </li>
            <li><span style="font-style: italic;">Support for Unicode
userid/password@DSN. </span>A new otl_connect::<a
 href="otl3_connect_class.htm#logon_odbc_unicode">rlogon</a>()
implements the feature when #define<br>
              <a
 href="otl3_compile.htm#OTL_UNICODE_EXCEPTION_AND_RLOGON">OTL_UNICODE_EXCEPTION_AND_RLOGON
              </a>is enabled. <br>
              <br>
For more detail, see example <a href="otl4_ex365.htm">365</a>.<br>
              <br>
            </li>
            <li><span style="font-style: italic;"> Unicode error
messages, </span>when #define <a
 href="otl3_compile.htm#OTL_UNICODE_EXCEPTION_AND_RLOGON">OTL_UNICODE_EXCEPTION_AND_RLOGON
              </a>is enabled.<br>
              <br>
For more detail, see example <a href="otl4_ex365.htm">365</a>.<br>
              <br>
            </li>
          </ul>
          <li>This release introduces two new #defines:<br>
            <br>
          </li>
          <ul>
            <li><a href="otl3_compile.htm#OTL_UNICODE_CHAR_TYPE">OTL_UNICODE_CHAR_TYPE
(support for operators &gt;&gt;/&lt;&lt; for&nbsp; Unicode characters)<br>
              </a></li>
            <li><a href="otl3_compile.htm#OTL_UNICODE_STRING_TYPE">OTL_UNICODE_STRING_TYPE
(support for operators &gt;&gt;/&lt;&lt; for Unicode std::wstrings)</a><br>
              <br>
            </li>
          </ul>
        </ul>
        <div style="margin-left: 40px;">For more detail, see the
following examples:<br>
        <br>
        <ul>
          <li>For Oracle: <a href="otl4_ex351.htm">351</a>, <a
 href="otl4_ex352.htm">352</a>, <a href="otl4_ex353.htm">353</a>, <a
 href="otl4_ex354.htm">354</a>.</li>
          <li>For DB2: <a href="otl4_ex355.htm">355</a>, <a
 href="otl4_ex356.htm">356</a>, <a href="otl4_ex357.htm">357</a>, <a
 href="otl4_ex358.htm">358</a>.</li>
          <li>For MS SQL: <a href="otl4_ex359.htm">359</a>, <a
 href="otl4_ex360.htm">360</a>.</li>
          <li>PostgreSQL: <a href="otl4_ex361.htm">361</a>, <a
 href="otl4_ex362.htm">362</a>.</li>
          <li>SAP/MAX DB: <a href="otl4_ex363.htm">363</a>, <a
 href="otl4_ex364.htm">364</a>.<br>
          </li>
        </ul>
        <br>
        </div>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (int OTL 4.0.122):<br>
        <br>
        <ul>
          <li>There was a typo in "<span style="font-family: monospace;">otl_output_iterator&lt;T&gt;<big>&amp;</big>
operator++(int)</span>". It should be: "<span
 style="font-family: monospace;">otl_output_iterator&lt;T&gt;
operator++(int)". </span>The typo / bug is fixed in this release. The
scope of this bug is not quite clear. It depends on the actual
implementation of the STL library for different C++ compilers. So far,
I have not seen any of my tests to crash, or deliver incorrect data
sets.<br>
            <br>
          </li>
          <li><a name="TIMESTAMP_40122"></a>MS SQL has a rarely used
data type: TIMESTAMP. It has
nothing to do with calendar date/time.&nbsp; The TIMESTAMP type could
be used to implement the optimistic locking scheme. Say, a table has a
TIMESTAMP column, and a row in the table is being changed. The
TIMESTAMP gets changed by the database server itself as any column in
the row changes its value. The rest in the implementation of the
optimistic locking scheme is clear: the row gets read once at the very
beginning, then the TIMESTAMP of the row needs to be read one more time
right before the change gets made in order to make sure that nobody
else (no other user) has already changed the row. OTL didn't have any
default support for such a data type. In this release and on, all
TIMESTAMP table columns will be mapped to char[17], which will make the
MS SQL ODBC driver convert the TIMESTAMP value to a 16 character, null
terminated hexadecimal string. For pre-4.0.122 releases of OTL, the OTL
data type&nbsp; for TIMESTAMP table columns could be explicitly
overriden either via <a href="otl3_bind_variables.htm#SELECT_OVERRIDE">:#N&lt;char[17]&gt;</a>
notation, where N is 1,2,3..., or via otl_stream::<a
 href="otl3_stream_class.htm#set_column_type">set_column_type</a>().<br>
            <br>
          </li>
          <li>This release introduces new "<a
 href="otl4_stream_read_iterator.htm#get_by_name">get by name</a>" <span
 style="font-style: italic;">getter</span> functions in the <a
 href="otl4_stream_read_iterator.htm">OTL stream read iterator template
class</a>.&nbsp; For more detail, see examples <a href="otl4_ex339.htm">339</a>,
            <a href="otl4_ex340.htm">340</a>, <a href="otl4_ex341.htm">341</a>,
            <a href="otl4_ex342.htm">342</a>.<br>
            <br>
          </li>
          <li>In OTL 4.0.119 the third OTLLobStream class type
parameter was <a href="#OTL40119">added</a> to the<a
 href="otl4_stream_read_iterator.htm"> OTL stream read iterator
template
class</a>. <a href="otl3_lob_stream.htm">otl_lob_stream</a> is not
supported under #define <a href="otl3_compilr.htm#OTL_ORA7">OTL_ORA7</a>,
so the stream read template class&nbsp; was corrected and now has only
two class type parameters as before OTL 4.0.119.<br>
            <br>
          </li>
          <li><span style="text-decoration: underline;"></span>PostgreSQL
8.1 was recently released. PostgreSQL 8.1 ODBC driver seems to support
the bulk interface (otl_stream buffer sizes can be &gt; 1). ODBC
Unicode driver seems to work. A few new code examples have been added
in this release:&nbsp; <a href="otl4_postgresql_examples.htm">342,
345-350</a>.<br>
            <br>
          </li>
          <li><a href="otl4_stream_read_iterator.htm">OTL stream read
iterator
template
class</a>, when compiled with GNU C++ 2.95-96, or GNU C++ 4.0 on
Solaris, may cause a runtime "bus error". A similar bug was fixed in <a
 href="#OTL40114">OTL 4.0.114</a>. It looks like the recent "bus error"
bug is specific to GNU C++, because the exact same code runs
successfully when compiled with Forte C++. The problem is in memory
address alignment,. Definitely. GNU C++ does something different from
Forte C++. Internal memory allocation was rewritten in the stream read
iterator class in order to avoid further memory address alignment
problems.<br>
            <br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New ( in OTL 4.0.121):<br>
        <br>
        <ul>
          <li>OTl 4.0.120 stopped compiling with VC++ 6.0. By popular
demand, the feature is back. I didn't actually realize that until
several people pointed that out.<br>
            <br>
          </li>
          <li>Under certain circumstanes, OTL/OCI8i/9i/10g in the LOB
stream mode, when a CLOB/BLOB value is being updated from a bigger to a
smaller size, may trim the old CLOB/BLOB value incorrectly, or not trim
the value at all. The bug is fixed in this release. <br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.120):<br>
        <br>
        <ul>
          <li>OTL now compiles clean under 64-bit VC++ (_WIN64).<br>
            <br>
          </li>
          <li>OTL introduces the following new function: otl_connect::<a
 href="otl3_connect_class.htm#commit_nowait">commit_nowait</a>(). The
function calls the corresponding OCI 10g Release 2 (Oracle 10.2)
function to perform an asynchronous commit, which is a new feature of
Oracle 10.2. Also, see example <a href="otl4_ex321.htm">321</a>. <br>
            <br>
          </li>
          <li>OTL introduces general support for <a
 href="http://www.mysql.com/products/maxdb/">MAX-DB / SAP-DB</a>. See
examples <a href="otl4_sap_db_examples.htm">322-338</a> for more
detail.<br>
            <br>
          </li>
          <li>SQL statement parser in OTL stream didn't parse the
following correctly:&nbsp; <br>
            <br>
            <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
...'foo/*'...:A&lt;int,in&gt; := ...</span><br>
            <br>
What happens is that when a comment beginning character sequence "<span
 style="font-family: monospace;">/*</span>" is present inside a string
literal, the parser misinterprepts it and skips the bind variable,
which is part of the SQL statement. <br>
            <br>
The bug is fixed in this release.<br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.119):<br>
        <br>
        <ul>
          <li><a href="otl4_stream_read_iterator.htm">otl_stream_read_iterator</a>
now supports <a href="otl3_lob_stream.htm">otl_lob_stream</a>'s via
the following get function: void <a
 href="otl4_stream_read_iterator.htm#get_lob_stream_ptr">get</a>(otl_lob_stream*&amp;).
For more detail, see examples <a href="otl4_ex315.htm">315</a>, <a
 href="otl4_ex316.htm">316</a>, <a href="otl4_ex317.htm">317</a>, <a
 href="otl4_ex318.htm">318</a>, <a href="otl4_ex319.htm">319</a>, <a
 href="otl4_ex320.htm">320</a>. <br>
            <br>
            <span style="font-style: italic;"><a name="OTL40119"></a>NOTE:</span>
otl_stream_read_iterator has one more class parameter: OTLLobStream. It
needs to be added to the actual parameter list.<br>
            <br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.118):<br>
        <br>
        <ul>
          <li>When a char/string bind variable is declared as
:var&lt;char(XXX)&gt; instead of :var&lt;char[XXX]&gt;, the program
crashes with "Memory Access Violation" / "Segmentation Violation". What
happens is that OTL tries to access memory beyond an allocated memory
block. The bug is fixed in this release.<br>
            <br>
          </li>
          <li>This release of OTL and higher support <a
 href="otl3_bind_variables.htm#char">char</a>(XXX) as equivalent to
char[XXX] in bind variable declarations.<br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.117):<br>
        <br>
        <ul>
          <li>When #define <a href="otl3_compile.htm#OTL_BIGINT">OTL_BIGINT</a>
is enabled along with #define <a href="otl3_compile.htm#OTL_UNICODE">OTL_UNICODE</a>
and #define <a href="otl3_compile.htm#OTL_ORA8I">OTL_ORA8I</a>/<a
 href="otl3_compile.htm#OTL_ORA9I">9I</a>/<a
 href="otl3_compile.htm#OTL_ORA10G">10G</a>, OTL throws the folowing
exception / error:<br>
            <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span
 style="font-family: monospace;">ORA-01458: invalid length inside
variable character string <br>
            <br>
            </span>The bug is fixed in this release.<br>
            <span style="font-family: monospace;"><br>
            </span></li>
          <li>Explicit bind variables in output column definitions can
be <a href="otl3_bind_variables.htm#SP_COL_OVERRIDE">defined</a> for
implicit result sets (ODBC/DB2-CLI), or reference cursors (Oracle) the
same way as in <a href="otl3_bind_variables.htm#SELECT_OVERRIDE">SELECT</a>
statements.<br>