otl3_whatn_1.htm

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

            </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>
          <li>Updated the <a href="links.htm">Links</a> page with
"Instructions
on how to use OTL with PostgreSQL in <a
 href="http://www.geocities.com/ccrosetti/otlw/">Windows</a> and <a
 href="http://www.geocities.com/ccrosetti/otl/index.html"><span
 style="text-decoration: underline;">Solaris</span></a>
from <a href="http://www.geocities.com/ccrosetti/">Carlos Crosetti</a>.<br>
            <br>
          </li>
          <li>Updated my <a href="skuchin_resume.htm">resume</a> to
better reflect reality.<br>
            <br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.128):<br>
        <br>
        <ul>
          <li><span style="font-family: monospace;">otl_connect&amp;
operator&gt;&gt;(otl_connect&amp; connect, otl_stream&amp; s)</span>
should have been declared as <span style="font-style: italic;">inline</span>,
but it wasn't, which caused a "duplicate symbol" linker error. The bug
is fixed in this release.<br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;"><a name="OTL40127"></a>New (in
OTL 4.0.127):<br>
        <br>
        <ul>
          <li>Code cleanup: From now on, OTL uses template member
functions by default for C++ compilers that support the feature.
However, some C++ compilers have no support for the feature, or have
bugs in supporting the feature. The following new #define can be used
to make OTL fall back on
the old proven nontemplate member functions in case if OTL compiles
with errors: #define <a
 href="otl3_compile.htm#OTL_NO_TMPL_MEMBER_FUNC_SUPPORT">OTL_NO_TMPL_MEMBER_FUNC_SUPPORT.<br>
            <br>
            </a></li>
          <li>OTL for OCI8/8i/9i/10g didn't map Oracle ROWID / UROWID
type to a char[XXX] correctly. The bug is fixed in this release. The
problem was that the OCI internal data type code for ROWID was
different
from what was described in the OCI reference guide.<br>
            <br>
          </li>
          <li>OTL tries to follow the latest / modern trends in C++ in
cases when it makes sense. Some C++ libraries try to overload operator
&gt;&gt; / &lt;&lt;, operator comma, operator parens, etc.,&nbsp; and
provide more syntax rich
context for developers. <a href="http://boost.org">Boost</a>.org is
one good example of that. Another, though a much smaller example, is <a
 href="http://soci.sf.net">soci</a>. I've been asked a few times to
introduce something similar in OTL. This release introduces several new
operators in <a href="otl3_connect_class.htm">otl_connect:</a>
operator <a href="otl3_connect_class.htm#operator_gg">&gt;&gt;</a>(<a
 href="otl3_stream_class.htm">otl_stream</a>&amp;), <a
 href="otl3_connect_class.htm#operator_ll">&lt;&lt;</a>(const char*), <a
 href="otl3_connect_class.htm#operator_lle">&lt;&lt;=</a>(const char*).
For more detail, see example <a href="otl4_ex371.htm">371</a>, <a
 href="otl4_ex372.htm">372</a>, <a href="otl4_ex373.htm">373</a>, <a
 href="otl4_ex374.htm">374</a>, <a href="otl4_ex375.htm">375</a>, <a
 href="otl4_ex376.htm">376</a>, <a href="otl4_ex377.htm">377</a>. <br>
            <br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.126):<br>
        <br>
        <ul>
          <li>#define <a href="otl3_compile.htm#OTL_ORA_OCI_ENV_CREATE">OTL</a><a
 href="otl3_compile.htm#OTL_ORA_OCI_ENV_CREATE">_ORA_OCI_ENV_CREATE</a>,
            <a href="otl3_compile.htm#OTL_ORA_OCI_ENV_CREATE_MODE">OTL_ORA_OCI_ENV_CREATE_MODE</a>.
A discussion has been going on for years about whether the old scheme
of OCIInialize()+OCIEnvInit() for initializing OCI environment handles
doesn't work any more, and should be replaced with the new scheme of
OCIEnvCreate(). Oracle documentaion says that the old scheme should be
eliminated. The old scheme seems to work fine, and the discussion has
gone nowhere. In the future, when more extensive support for Unicode in
OTL/OCIx gets implemented (Unicode user id, password, etc.), only then
OCIEnvCreate() will become indispensible. For more detail, see
otl_connect::<a href="otl3_connect_class.htm#rlogon_xa">rlogon</a>(), <a
 href="otl3_connect_class.htm#server_attach">server_attach</a>().<br>
            <br>
          </li>
          <li>Following new #defines: <a
 href="otl3_compile.htm#OTL_EXCEPTION_ENABLE_ERROR_OFFSET"><span
 style="font-family: monospace;">OTL_EXCEPTION_ENABLE_ERROR_OFFSET</span></a>,
            <span style="font-family: monospace;"><a
 href="otl3_compile.htm#OTL_EXCEPTION_STM_TEXT_SIZE">OTL_EXCEPTION_STM_TEXT_SIZE</a>.</span><br>
            <br>
          </li>
          <li>Support for Large Unicode Objects (NTEXT, NCLOB, etc.)
was overlooked for otl_stream::operators &gt;&gt;/&lt;&lt;(<a
 href="otl3_compile.htm#OTL_UNICODE_STRING_TYPE">OTL_UNICODE_STRING_TYPE</a>&amp;).
This release fixes the problem. For more detail, see example <a
 href="otl4_ex366.htm">366</a>,&nbsp; <a href="otl4_ex367.htm">367</a>,
            <a href="otl4_ex368.htm">368,</a> <a href="otl4_ex369.htm">369</a>,
            <a href="otl4_ex370.htm">370</a>.<br>
            <br>
          </li>
          <li>A memory leak was reported when OTL stream <a
 href="otl3_stream_pooling.htm">pooling</a> is on (#define <a
 href="otl3_compile.htm#OTL_STREAM_POOLING_ON">OTL_STREAM_POOLING_ON</a>),
and there are SELECT output column <a
 href="otl3_bind_variables.htm#SELECT_OVERRIDE">overrides</a>.<br>
The bug is fixed in this release.<br>
            <br>
          </li>
          <li>otl_sconnect::<a
 href="otl3_connect_class.htm#set_stream_pool_size">set_stream_pool_size</a>()
needs to check for the stream pool size. When the stream size is 1 then
the program crashes. The bug is fixed in this release.<br>
            <br>
          </li>
          <li>When <a href="otl3_compile.htm#OTL_ACE">OTL_ACE</a> is
enabled, OTL defines otl_stream::operator &gt;&gt;/&lt;&lt; for
ACE_TString. In order to assign a NULL terminated string value from the
otl_stream internal buffer to the output string in
operator&gt;&gt;(ACE_TString&amp; s), OTL used the following assignment:<br>
            <br>
&nbsp; &nbsp;&nbsp; <span style="font-family: monospace;">s=&lt;pointer
to internal char* buffer&gt;;</span><br>
            <br>
It turns out that ACE_TString doesn't have <span
 style="font-family: monospace;">operator=(const char*)</span>. So, the
assignment generates a temporary variable plus 2 extra calls to the
heap
manager. This release fixes the inefficiency by using
ACE_TString::set() instead:<br>
            <br>
&nbsp; &nbsp;&nbsp; <span style="font-family: monospace;">s.set(&lt;pointer&gt;,1);</span><br>
            <br>
          </li>
          <li>VC++ 8.0 (Visual Studio 2005) compiles clean now.<span
 style="font-family: monospace;"></span><br>
            <br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.125):<br>
        <br>
        <ul>
          <li>Support for Unicode ODBC drivers was inadvertently tied
up to #define <a href="otl3_compile.htm#OTL_UNICODE">OTL_UNICODE</a>.
From this release
and on, when Unicode ODBC driver support is enabled in general in the
ODBC header files (via #define UNICODE / _UNICODE), OTL also generates
SQLxxxW calls, regardless of whether OTL_UNICODE is defined or not.<br>
            <br>
          </li>
          <li>#define <a
 href="otl3_compile.htm#OTL_DEFAULT_STRING_NULL_TO_VAL">OTL_DEFAULT_STRING_NULL_TO_VAL</a>
serves its purpose reasonably well. It covers operations with both
char* (one-byte, Unicode) and C++ string classes (the use of which can
be enabled via&nbsp; <a href="otl3_compile.htm#OTL_STL">OTL_STL</a>, <a
 href="otl3_compile.htm#OTL_ACE">OTL_ACE,</a> <a
 href="otl3_compile.htm#OTL_STLPORT">OTL_STLPORT</a>, <a
 href="otl3_compile.htm#OTL_USER_DEFINED_STRING_CLASS_ON">OTL_USER_DEFINED_STRING_CLASS</a><a
 href="otl3_compile.htm#OTL_USER_DEFINED_STRING_CLASS_ON">_ON</a>, <a
 href="otl3_compile.htm#OTL_UNICODE_STRING_TYPE">OTL_UNICODE_STRING_TYPE</a>).
Normally, string NULLs get defaulted to an empty string. In the case of
C++ string classes, an actual string variable can be reinitialized more
efficiently than assigning an empty string to it. This release
introduces the following #define to do just that: <a
 href="otl3_compile.htm#OTL_USER_DEFINED_STRING_CLASS_DEFAULT_NULL_TO_VAL">OTL_USER_DEFINED_STRING_CLASS_DEFAULT_NULL_TO_VAL</a><br>
            <br>
          </li>
          <li><a
 href="otl3_compile.htm#OTL_UNICODE_USE_ANSI_ODBC_FUNCS_FOR_DATA_DICT">#define
OTL_UNICODE_USE_ANSI_ODBC_FUNCS_FOR_DATA_DICT</a>. A workaround for an
MS SQL Server bug when Unicode is enabled.<br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.124):<br>
        <br>
        <ul>
          <li><a href="otl4_stream_read_iterator.htm">otl_stream_read_iterator</a>::is_null()
returns results that are the opposite to what they are supposed to be.
The bug
is fixed in this release.<br>