otl3_whatn.htm

otl是c++数据库封装好的一个数据库接口

      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.136), updated:<br>
        <br>
        <ul>
          <li>I got the same question from a few developers about
whether OTL officially supported MS SQL 2005 or not. Now the answer is
Yes. I downloaded MS SQL 2005 XE, which can be freely used, installed
it,
and extended the OTL internal test suite to run against MS SQL 2005.<br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.136):<br>
        <br>
        <ul>
          <li>This release fixes a bug similar to <a
 href="OTL_UNICODE_ERROR">this old bug</a>. The difference between the
new bug and the old bug is that the new bug happens when an output
parameter in a stored procedure is used.<br>
            <br>
          </li>
          <li>New code example has been added for OTL/OCI8i/9i/10g to
show how to use CLOB/BLOBs with PL/SQL stored procedures and the LOB
stream mode. See example <a href="otl4_ex378.htm">378.</a><br>
            <br>
          </li>
          <li>Several type cast related compilation warnings have been
fixed in OCIBindByName() calls.<br>
            <br>
          </li>
          <li>When an OTL stream is being opened with a SELECT
statement that contains a column of an unsupported data type, the
program may crash. For example, the following SELECT crashes the
program (OTL/OCI8i/OCI9i/OCI10g):<br>
            <br>
&nbsp;&nbsp;&nbsp;<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;
select * from sys.ku$_library_view</span><br>
            <br>
This SELECT actually contains an Oracle Object column, which OTL does
not support. The problem has been fixed in this release. Instead of
crashing the program, OTL will throw the following <a
 href="otl3_exc_list.htm">OTL defined</a> exception:<br>
            <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            <span style="font-family: monospace;">Unsupported column
data type, code <a href="otl3_exc_list.htm#32028">32028</a><br>
            </span><span style="font-family: monospace;"><br>
            </span></li>
          <li>The following new functions have been added to the <a
 href="otl3_compile.htm#OTL_ORA_DECLARE_COMMON_READ_STREAM_INTERFACE">otl_read_stream_interface</a>,
and to the <a href="otl4_refcur_stream.htm">otl_refcur_stream</a> (the
functions do the same thing as the corresponding functions in the <a
 href="otl3_stream_class.htm">otl_stream</a> class):<br>
            <br>
          </li>
          <ul>
            <li><small><small><small><small><small><span
 style="font-family: monospace;">otl_var_desc*
describe_out_vars(int&amp; desc_len);</span></small></small></small></small></small></li>
            <li><span style="font-family: monospace;">otl_var_desc*
describe_next_out_var(void);</span><br>
              <span style="font-family: monospace;"><br>
              </span></li>
          </ul>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.135):<br>
        <br>
OTL had limits on how many bind variables / SELECT output columns it
could handle. The limits were as
follows:<br>
        <br>
        <ul>
          <li>512 for OTL/ODBC, OTL/DB2 CLI, OTL/OCI7</li>
          <li>1024 for OTL / OCI8/8i/9i/10g<br>
            <br>
          </li>
        </ul>
The OTL limits were supposed to match the actual limits of the
underlying database APIs. As more versions of databases come out, the
limits change.&nbsp; This release eliminates any&nbsp; practical limits
on the maximum number of bind variables / SELECT output columns. The
limits on the underlying database APIs still exist.When the limit on,
say, database type A, is reached, OTL would throw an otl_exception. The
actual error code and error message is database specific, and it's not
defined by OTL.<br>
        <br>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.134):<br>
        <br>
        <ul>
          <li>When <a href="otl3_compile.htm#OTL_ODBC">OTL_ODBC </a>/
            <a href="otl3_compile.htm#OTL_DB2_CLI">OTL_DB2_CLI</a>
and&nbsp; <a href="otl3_compile.htm#OTL_BIGINT">OTL_BIGINT</a> are
defined, OTL doesn't compile with older C++ compilers that don't have
support for template member functions. The error is fixed in this
release.</li>
          <br>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.133):<br>
        <br>
        <ul>
          <li>When a DB2 BLOB table column has a smaller maximum size
in its definition than the actual BLOB value being written to the BLOB
column in the <a href="otl3_stream_class.htm#set_lob_stream_mode">LOB
stream mode</a>, OTL throws an exception with no error message, and a
random error code. The error is fixed in this release.<br>
            <br>
          </li>
          <li>When compiled with GNU C++ 4.1.0, OTL generates the
following compilation warning: <br>
            <br>
&nbsp;&nbsp;&nbsp; <span style="font-family: monospace;"><small><small><small><small><small><small><small><small><small><small><small><small><small><small><small>dereferencing
type-punned pointer will <br>
&nbsp; break strict-aliasing rules</small></small></small></small></small></small></small></small></small></small></small></small></small></small></small></span>
            <p><span style="font-family: monospace;"></span></p>
            <br>
The warning was actually fixed in OTL 4.0.132.<br>
            <br>
          </li>
          <li>When OTL is used with <a href="http://boost.org">boost</a>'s
date_time, VC++ generates
the following error message:&nbsp; error
C2668: 'isspace' : ambiguous call to overloaded function. The error is
fixed in this release.<em><br>
            </em><br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.132):<br>
        <br>
        <ul>
          <li>OTL doesn't compile with Visual C++ 7.1 when the
following #define's are enabled:<br>
            <br>
            <span style="font-family: monospace;">#define OTL_ORA8I or
ORA9I ORA10G or ORA10G_R2</span><br>
            <span style="font-family: monospace;">#define OTL_UNICODE<br>
#define OTL_UNICODE_CHAR_TYPE wchar_t<br>
#define OTL_UNICODE_STRING_TYPE std::wstring</span><br>
            <span style="font-family: monospace;">#define
OTL_TRACE_LEVEL my_trace_level </span><br
 style="font-family: monospace;">
            <span style="font-family: monospace;">#define
OTL_TRACE_STREAM wcerr </span><br style="font-family: monospace;">
            <span style="font-family: monospace;">#define
OTL_TRACE_LINE_PREFIX "MY OTL TRACE ==&gt; " <br>
            <br>
            </span>Error is fixed in this release<br>
            <br>
          </li>
          <li>When Unicode is enabled for Oracle 8i/9i/10g, and the <a
 href="otl3_stream_class.htm#set_lob_stream_mode">LOB stream mode</a>
is used, <a href="otl3_lob_stream.htm">otl_lob_stream</a> doesn't
return a CLOB/NCLOB correctly. More specifically, if the length of a
CLOB/NCLOB is at least 2-3 times larger than the buffer size which the
CLOB/NCLOB is being fetched through. The error is due to the fact that
the OCI returns the size of the second chunk of the CLOB/NCLOB to be
fetched that is equal in size to the buffer in bytes instead of Unicode
characters. The error is fixed in
this release.<br>
            <br>
          </li>
          <li><a name="OTL_UNICODE_ERROR"></a>When the following
#define's are enabled:<br>
            <br>
            <span style="font-family: monospace;">#define OTL_ORA8I or
ORA9I ORA10G or ORA10G_R2</span><br>
            <span style="font-family: monospace;">#define OTL_UNICODE<br>
#define OTL_UNICODE_CHAR_TYPE wchar_t<br>
#define OTL_UNICODE_STRING_TYPE std::wstring</span><br>
            <span style="font-family: monospace;"><br>
            </span>otl_stream::operator&gt;&gt;(OTL_UNICODE_STRING_TYPE&amp;)
returns incorrect values of Unicode strings in the following scenario:<br>
            <br>
            <span style="font-family: monospace;">ABCD</span><br
 style="font-family: monospace;">
            <span style="font-family: monospace;">ABC</span><br
 style="font-family: monospace;">
            <span style="font-family: monospace;">AB</span><br
 style="font-family: monospace;">
            <span style="font-family: monospace;">A</span><br
 style="font-family: monospace;">
            <br>
The actual output is:<br>
            <br>
            <span style="font-family: monospace;">ABCD</span><br
 style="font-family: monospace;">
            <span style="font-family: monospace;">ABCD</span><br
 style="font-family: monospace;">
            <span style="font-family: monospace;">ABCD</span><br
 style="font-family: monospace;">
            <span style="font-family: monospace;">ABCD</span><br
 style="font-family: monospace;">
            <br>
This happens because the OCI doesn't guarantee in some very special
cases Unicode strings to be null terminated. The error is fixed in this
release.<br>
            <br>
          </li>
          <li>When these #defines are enabled:<br>
            <br>
            <span style="font-family: monospace;">#define OTL_UNICODE<br>
#define OTL_UNICODE_CHAR_TYPE wchar_t<br>
#define OTL_UNICODE_STRING_TYPE my_wide_char_string<br>
            <br>
            </span>In case if <span style="font-family: monospace;">my_wide_char_string
            </span>is not<span style="font-family: monospace;"> 1</span>00%
compatible with std::wstring, OTL doesn't compile because it uses
strng::assing(charT* c,size_t len) function to make a string value out
of a raw chararcter buffer + the string length. In order to wortk
around the problem, this release introduces the following new #define:<br>
            <br>
            <span style="font-family: monospace;">#define <a
 href="otl3_compile.htm#OTL_UNICODE_STRING_TYPE_CAST_FROM_CHAR">OTL_UNICODE_STRING_TYPE_CAST_FROM_CHAR</a></span><br>
            <span style="font-family: monospace;"></span><br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.131):<br>
        <br>
        <ul>
          <li>In this release, Oracle 9i / 10g's INTERVAL data types
get mapped to char[XXX] on SELECT statements by default when #define <a
 href="otl3_compile.htm#OTL_ORA_TIMESTAMP">OTL_ORA_TIMESTAMP</a> is
enabled<br>
            <br>
          </li>
          <li>OCI 8i / 9i may generate ORA-01461 error when <a
 href="otl3_compile.htm#OTL_UNICODE">Unicode</a>
is enabled, and when the SQL statement is a SELECT with two (or more)
VARCHAR2(4000), or NVARCHAR2(2000) columns. The error was fixed in OTL <a
 href="#40111">4.0.111</a>. However, the fix prevented big
VARCHAR2(4000&lt;X&lt;32000) / NVARCHAR2(2000&lt;X,&lt;16000) bindings
in the case of PL/SQL blocks. As a workaround, this release introduces
the following new <span style="font-family: monospace;">#define <a
 href="otl3_compile.htm#OTL_ORA_MAX_UNICODE_VARCHAR_SIZE">OTL_ORA_MAX_UNICODE_VARCHAR_SIZE</a></span>.<br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.130):<br>
        <br>
        <ul>
          <li>When #define OTL_ORA9I, #define
OTL_ORA_DECLARE_COMMON_READ_STREAM_INTERFACE, and #define OTL_DEFINE
are enabled at the same time, the OTL header doesn't compile / has
compilation error about "otl_stream being an abstract class". The error
is fixed in this release.<br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.129):<br>
        <br>
        <ul>
          <li>Two new functions for <a href="otl3_connect_class.htm">otl_connect</a>:<br>
            <br>
          </li>
          <ul>
            <li><a href="otl3_connect_class.htm#direct_exec">direct_exec</a>(),
by common sense<br>
            </li>
            <li><a href="otl3_connect_class.htm#syntax_check">syntax_check</a>(),
by the request from the <a href="http://tora.sf.net">TORA</a> project
people<br>
              <br>
            </li>
          </ul>