otl3_whatn.htm

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

used in Oracle in a combination with OTL/OCIx, a string that doesn't
have space characters at the end, can't be found by a WHERE clause in a
SELECT statement. For example:<br>
            <br>
&nbsp;&nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">SELECT
f2 FROM test_tab WHERE f2=:f2&lt;char[31]&gt;</span><br>
            <br>
where f2 is CHAR(30). When OTL/OCIx is being used, either the string
has to be padded with space characters to the full length of the
column, or the following #define needs to be enabled (accidentally, it
wasn't documented, a.k.a. a bug in the manual): #define <a
 href="otl3_compile.htm#OTL_ORA_MAP_STRINGS_TO_CHARZ">OTL_ORA_MAP_STRINGS_TO_CHARZ</a>.<br>
            <br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.141):<br>
        <br>
        <ul>
          <li>When an empty PL/SQL table gets returned via STL vector
based, OTL PL/SQL table <a href="otl3_pl_tab.htm">containers</a>,
Visual C++ 2005 throws an "out-of-range" exception. Error is fixed in
this release.<br>
            <br>
          </li>
          <li>New #define is introduced: #define <a
 href="otl3_compile.htm#OTL_DESTRUCTORS_DO_NOT_THROW">OTL_DESTRUCTORS_DO_NOT_THROW</a>.
            <br>
            <br>
Here's some prehistory: "<span style="font-style: italic;">Personally
I'd vote for beating every person who will write throwing destructor,
one hit in the head for every such destructor. I wonder why this
question always raised along with database-related code? Maybe because
people who write such libraries "came" from DB world and are not
competent enough to understand? I remember OTL (C++ DB access library)
has issues with throwing destructors...Michael...</span>".<br>
            <br>
&nbsp;People who want OTL destructors not "to
throw", from now on can enable the new #define, and happily code away
all manual database resource management.<br>
            <br>
My opinion is that for C++ compilers that support uncaught_exception()
correctly, throwing destructors are acceptable, if it results in
writing less code. Let the C++ gurus rest on the laurels of their
superior C++ knowledege.<br>
            <br>
Question for everybody: can anybody point me to a common C++ technique
/ idiom / pattern that combines RAII idiom, non-throwing destructors,
and error communication / handling via exceptions? I'd appreciate any
useful info on the topic very much.<br>
          </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.140):<br>
        <br>
        <ul>
          <li>A few more of&nbsp; "<a href="#type_punned">type-punned</a>"
g++ warnings have been fixed in this release. Besides the type-punned
warnings, other warning have been fixed. OTL compiles clean
with the following g++ warnings on (g++ 4.1.1):<br>
            <br>
            <span style="font-family: monospace;">&nbsp; -W<br>
&nbsp; -Wall<br>
&nbsp; -Wcast-align<br>
&nbsp; -Wcast-qual<br>
&nbsp; -Wcomments<br>
&nbsp; -Wconversion<br>
&nbsp; -Wctor-dtor-privacy<br>
&nbsp; -Werror<br>
&nbsp; -Wextra<br>
&nbsp; -Wformat<br>
&nbsp; -Wno-uninitialized<br>
&nbsp; -Wnon-virtual-dtor<br>
&nbsp; -Wold-style-cast<br>
&nbsp; -Woverloaded-virtual<br>
&nbsp; -Wparentheses<br>
&nbsp; -Wpointer-arith<br>
&nbsp; -Wreorder<br>
&nbsp; -Wshadow<br>
&nbsp; -Wsign-compare<br>
&nbsp; -Wsign-promo <br>
&nbsp; -Wstrict-aliasing=2<br>
&nbsp; -Wstrict-null-sentinel<br>
&nbsp; -Wundef<br>
&nbsp; -Wunused<br>
&nbsp; -Wunused-variable<br>
&nbsp; -Wwrite-strings<br>
            <br>
            </span></li>
          <li>OTL stream was allocating more memory than necessary for
internal buffers in the PL/SQL block:<br>
            <span style="font-family: monospace;"><br>
&nbsp;&nbsp;&nbsp; "begin "<br>
&nbsp;&nbsp;&nbsp; "&nbsp; PKG_TEST.my_prc(:p_arr&lt;char[2000],<span
 style="font-weight: bold; font-style: italic;">in[2000]</span>&gt;); "<br>
&nbsp;&nbsp;&nbsp; "&nbsp; PKG_TEST.proc_1(<span
 style="font-style: italic;">:PAR1</span>&lt;CHAR[32000],IN&gt;); "<br>
&nbsp;&nbsp;&nbsp; "&nbsp; PKG_TEST.proc_2(<span
 style="font-style: italic;">:PAR2</span>&lt;CHAR[32000],IN&gt;); "<br>
&nbsp;&nbsp;&nbsp; "end; "<br>
            <br>
            </span>The problem was that the <span
 style="font-style: italic;">in[2000]</span> clause was setting the
internal buffer size of the corresponding PL/SQL table to 2000, and <span
 style="font-style: italic;">:PAR1</span>, <span
 style="font-style: italic;">:PAR2</span> bind variables were treated
as PL/SQL tables of 2000 elements each. The program didn't crash, and
it even wroked correctly,&nbsp; but it allocated way too much memory.
The bug has been fixed in this release.<br>
            <span style="font-family: monospace;"><br>
            </span></li>
          <li><span style="font-family: monospace;"></span>A new bind
variable / placeholder data type has been introduced: <a
 href="otl3_bind_variables.htm#raw">raw</a>[XXX]. The new data type is
for supporting database "binary" types (Oracle RAW, MS SQL / Sybase /
MySQLVARBINARY/BINARY, PostgreSQL BYTEA, etc) natively. "Raw" values
can be read from / written to the database via <a
 href="otl3_long_string.htm">otl_long_string</a>'s. Also,&nbsp; a new
OTL type code contstant has been added in identify bind variable of the
raw[XXX] type:<br>
            <br>
&nbsp;&nbsp; &nbsp;&nbsp; <span style="font-family: monospace;">const
int <a href="otl3_stream_class.htm#otl_var_raw">otl_var_raw</a>=23;<br>
            <br>
            </span></li>
          <li>A new OTL defined exception:<br>
            <br>
            <font size="+1"><b>Code=<a href="otl3_exc_list.htm#raw1">32029</a>:</b>
RAW value cannot be read with otl_lob_stream, use otl_long_string
instead<br>
            <br>
            </font><span style="font-family: monospace;"></span></li>
          <li>Three new #defines in order to provide proper backward
compatibility in the context of the new data type raw[XXX]:<br>
            <br>
#define <a href="otl3_compile.htm#OTL_MAP_SQL_VARBINARY_TO_RAW_LONG">OTL_MAP_SQL_VARBINARY_TO_RAW_LONG</a>,
            <br>
#define <a href="otl3_compile.htm#OTL_MAP_SQL_GUID_TO_CHAR">OTL_MAP_SQL_GUID_TO_CHAR</a>,
            <br>
#define <a href="otl3_compile.htm#OTL_MAP_SQL_BINARY_TO_CHAR">OTL_MAP_SQL_BINARY_TO_CHAR
(MS SQL TIMESTAMPs)</a><br>
            <span style="font-family: monospace;"></span><span
 style="font-family: monospace;"> </span><br>
For more detail on how to use raw[XXX], see the following code examples:<br>
&nbsp;<span style="font-family: monospace;"></span></li>
          <ul>
            <li>Oracle (<a href="otl4_ex446.htm">446</a>, <a
 href="otl4_ex447.htm">447</a>, <a href="otl4_ex457.htm">457</a>, <a
 href="otl4_ex458.htm">458</a>)<br>
            </li>
            <li>MS SQL (<a href="otl4_ex448.htm">448</a>, <a
 href="otl4_ex449.htm">449</a>, <a href="otl4_ex459.htm">459</a>, <a
 href="otl4_ex460.htm">460</a>)<br>
            </li>
            <li>Sybase (<a href="otl4_ex450.htm">450</a>, <a
 href="otl4_ex451.htm">451</a>, <a href="otl4_ex461.htm">461</a>, <a
 href="otl4_ex462.htm">462</a>)<br>
            </li>
            <li>MySQL (<a href="otl4_ex452.htm">452</a>, <a
 href="otl4_ex453.htm">453</a>, <a href="otl4_ex463.htm">463</a>, <a
 href="otl4_ex464.htm">464</a>)<br>
            </li>
            <li>PostgreSQL (<a href="otl4_ex454.htm">454</a>, <a
 href="otl4_ex465.htm">465</a>) <br>
            </li>
            <li>MAX-DB / SAP-DB (<a href="otl4_ex455.htm">455</a>, <a
 href="otl4_ex456.htm">456</a>, <a href="otl4_ex466.htm">466</a>, <a
 href="otl4_ex467.htm">467</a>)<br>
            </li>
          </ul>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.139):<br>
        <br>
        <ul>
          <li><a name="type_punned"></a>The following g++ 4.1.0
compilation warnings have been
fixed in this release:<br>
            <br>
            <span style="font-family: monospace;">../include/otlv4.h:
In member function 'void otl_conn::error(otl_exc&amp;)':</span><br
 style="font-family: monospace;">
            <span style="font-family: monospace;">../include/otlv4.h:9126:
warning: dereferencing type-punned pointer will break</span><br
 style="font-family: monospace;">
            <span style="font-family: monospace;">strict-aliasing rules</span><br
 style="font-family: monospace;">
            <span style="font-family: monospace;">../include/otlv4.h:
In member function 'void otl_cur::error(otl_exc&amp;)':</span><br
 style="font-family: monospace;">
            <span style="font-family: monospace;">../include/otlv4.h:10835:
warning: dereferencing type-punned pointer will break</span><br
 style="font-family: monospace;">
            <span style="font-family: monospace;">strict-aliasing rules</span><br
 style="font-family: monospace;">
            <br>
          </li>
          <li>A set of new <a href="otl4_sybsql_examples.htm">code
examples</a> for Sybase.</li>
        </ul>
        <br>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;"><a name="40138"></a>New (in
OTL 4.0.138):<br>
        <br>
        <ul>
          <li>A missing dependency of #define <a
 href="otl3_compile.htm#OTL_UNICODE_STRING_TYPE">OTL_UNICODE_STRING_TYPE</a>
on #define <a href="otl3_compile.htm#OTL_UNICODE">OTL_UNICODE</a> has
been added to this release.<br>
            <br>
          </li>
          <li><a href="otl3_lob_stream.htm">otl_lob_stream</a> required
the total length of a LOB to be <a href="otl3_lob_stream.htm#set_len">set</a>
before the first chunk of the LOB
gets written to the LOB stream. This release has relaxed the
requirement:
OTL/ODBC/DB2-CLI eliminates the requirement completely, and
OTL/OCI8i/9i/10g can be used with otl_long_string::<a
 href="otl3_long_string.htm#set_last_piece">set_last_piece</a>()
instead. For more detail, see examples <a href="otl4_ex385.htm">385 </a>(Oracle),
            <a href="otl4_ex386.htm">386</a> (Oracle) <a
 href="otl4_ex387.htm">387</a> (DB2),&nbsp; <a href="otl4_ex388.htm">388</a>
(DB2), <a href="otl4_ex389.htm">389</a> (MS SQL), <a
 href="otl4_ex390.htm">390</a> (MS SQL), <a href="otl4_ex391.htm">391</a>
(MySQL), <a href="otl4_ex392.htm">392</a> (MySQL), <a
 href="otl4_ex393.htm">393</a> (PostgreSQL), <a href="otl4_ex394.htm">394</a>
(MAX/DB), <a href="otl4_ex395.htm">395</a> (MAX/DB), </li>
        </ul>
        </td>
      </tr>
      <tr>
        <td style="vertical-align: top;">New (in OTL 4.0.137):<br>
        <br>
        <ul>
          <li>The following comment was incorrect (turns out people
read comments :-) )<br>
            <br>
            <span style="font-family: monospace;">// in case if it's
ODBC for Windows, include windows.h file<br>
            <br>
            </span>and was changed to<br>
            <br>
            <small><small><small><small><small><small><small><small><small><small><small><small><small><small><span
 style="font-family: monospace;">// in case if it's ODBC for Windows
(!OTL_ODBC_UNIX), and windows.h is </span><span
 style="font-family: monospace;">not included yet (_WINDOWS_ not
defined yet), then include the file</span><span
 style="font-family: monospace;"> explicitly<br>
            </span><br style="font-family: monospace;">
            </small></small></small></small></small></small></small></small></small></small></small></small></small></small></li>
          <li>The following minor warning for Borland C++ 6.0 was fixed:<br>
            <pre wrap="">"[C++ Warning] otlv4.h(19678): W8071 Conversion may cause loss of significant digits"<br><br></pre>
          </li>
          <li>OTL/ODBC/DB2-CLI, otlv4.h, line 13285, an OTL trace macro
call was incorrect:<br>
            <br>
            <span style="font-family: monospace;">&nbsp;&nbsp;
OTL_TRACE_WRITE(n,"operator &gt;&gt;","BIGINT");<br>
            <br>
            </span>and was replaced with<br>
            <br>
            <span style="font-family: monospace;">&nbsp;&nbsp;
OTL_TRACE_READ(n,"operator &gt;&gt;","BIGINT");<br>
            <br>
            </span>The incorrect OTL trace macro call caused a program
crash on AIX with DB2 CLI.<br>
            <br>
          </li>
          <li>OTL introduces two new operators <a
 href="otl3_lob_stream.htm#read_string">&gt;&gt;</a>(string&amp;) and <a
 href="otl3_lob_stream.htm#write_string">&lt;&lt;</a>(string&amp;) to
the <a href="otl3_lob_stream.htm">OTL LOB Stream</a> for reading and
writing std::strings (STL), or ACE_TStrings (ACE). For more detail. see
also examples <a href="otl4_ex379.htm">379</a>, <a
 href="otl4_ex380.htm">380</a>, <a href="otl4_ex381.htm">381</a>, <a
 href="otl4_ex382.htm">382</a>, <a href="otl4_ex383.htm">383</a>, <a
 href="otl4_ex384.htm">384</a>.<br>
            <br>
          </li>
        </ul>
        </td>