📄 otl3_whatn.htm
字号:
<!DOCTYPE html PUBLIC "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta content="text/html; charset=iso-8859-1"
http-equiv="Content-Type">
<meta content="Sergei Kuchin" name="Author">
<meta content="Mozilla/4.78 [en] (Windows NT 5.0; U) [Netscape]"
name="GENERATOR">
<meta
content="OTL, Oracle, ODBC, DB2, CLI, database API, C++, Template Library"
name="KeyWords">
<title>Oracle, Odbc and DB2-CLITemplate Library, Version 4.0, What's
New</title>
</head>
<body>
<ul>
<center>
<h1>Oracle, Odbc and DB2-CLI Template Library, Version 4.0</h1>
</center>
<center>
<h1>What's New</h1>
</center>
<h1>Current release number of the OTL header file</h1>
Current release number of the OTL header file is <font size="+2">4.0.160.
<script language="JavaScript"><!-- hide from old browsers
var modDate = new Date(document.lastModified)
document.write("<i> (Updated: " + (modDate.getMonth()+1) + "/" +
modDate.getDate() + "/" + "0"+(modDate.getYear())%100+"</i>).");
//-->
</script></font>If
you need the up-to-date version of the OTL header file, see the <a
href="otl3_down.htm">download
instructions</a>.
<h1>OTL 4.0.160 is now released.<br>
</h1>
<h1>For more detail, see the <a href="#summary">summary </a>of new
features. <i>The <a href="otl4_htm.zip">archived version</a> of
the OTL Web
pages </i>is available.</h1>
<b></b>
<h1><a name="summary"></a><i>From OTL 3.0.0 to OTL 4.0.160: summary
of
new features
and bug fixes</i></h1>
<table border="1">
<caption> </caption> <tbody>
<tr>
<td><b><font size="+1">Feature</font></b></td>
<td><b><font size="+1">Comment</font></b></td>
</tr>
<tr>
<td style="vertical-align: top;">New (in OTL 4.0.160):<br>
<br>
<ul>
<li>Oracle 11g Release 1 came out recently. OTL introduces
the following new #define to start the OTL/OCI11g series: #define <a
href="otl3_compile.htm#OTL_ORA11G">OTL_ORA11G</a>.<br>
<br>
</li>
<li>When <a href="otl3_compile.htm#OTL_ODBC">OTL_ODBC</a>, <a
href="otl3_compile.htm#OTL_BIGINT">OTL_BIGINT</a>, <a
href="otl3_compile.htm#OTL_STR_TO_BIGINT">OTL_STR_TO_BIGINT</a>, and<span
style="font-family: monospace;"> </span><a
href="otl3_compile.htm#OTL_BIGINT_TO_STR">OTL_BIGINT_TO_STR</a> are
defined, OTL does not compile with VC++ 2005, and xlC (C++ in AIX). The
bug is fixed in this
release.<br>
<br>
</li>
<li>When <a
href="otl3_compile.htm#OTL_DEFAULT_STRING_NULL_TO_VAL">OTL_DEFAULT_STRING_NULL_TO_VAL</a>,
<a href="otl3_compile.htm#OTL_UNICODE">OTL_UNICODE</a> are
defined together, and <a href="otl4_refcur_stream.htm">otl_refcur_stream</a>
is used, the default string vlaue 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.<br>
<br>
</li>
<li><a href="otl4_stream_read_iterator.htm">otl_stream_read_iterator</a>::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. .<br>
<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">New (in OTL 4.0.159):<br>
<br>
<ul>
<li>In OTL 4.0.158, a bug was introduced which causes the
following error message when an <int> bind variable is used:<br>
<pre wrap="">[Microsoft][SQL Native Client][SQL Server]Invalid 2-Parameter (''): The<br>0x23 data typ is a LOB marked as obsolete and used as output parameter.<br>Obsolete types are not supported as output parameters.<br><br></pre>
<p>The bug is fixed in this release.<br>
</p>
</li>
<li>
<p><span style="font-family: Arial;" lang="EN-US"><font
size="2"><font size="3">C++Builder 2007 generates the following error
when compiling OTL:<br>
<br>
<span style="font-family: monospace;">Error error
2285: E2285</span> <span style="font-family: monospace;">Could not
find a match for 'operator
otl_ora8_inout_stream::operator>>(float)<br>
</span></font></font></span></p>
<span style="font-family: Arial;" lang="EN-US"><font
size="2"><font size="3">There are similar errors in the rest of the
numeric operators >>() of the same class. The error goes away
when #define <a href="otl3_compile.htm#OTL_NO_TMPL_MEMBER_FUNC_SUPPORT">OTL_NO_TMPL_MEMBER_FUNC_SUPPORT</a>
is enabled. The bug is fixed in this release by enabling the #define
for Borland C++ by
default.<br>
<br>
</font></font></span></li>
<li><span style="font-family: Arial;" lang="EN-US"><font
size="2"><font size="3">Michael <a href="mailto:misha@ait.susu.ac.ru">Shishkin</a>
</font></font></span><span style="font-family: Arial;"
lang="EN-US"></span><span style="font-family: Arial;" lang="EN-US"><font
size="2"><font size="3">from Russia contributed the <a
href="otl4_subscriber.htm">otl_subscriber</a> class that uses the <a
href="http://www.oracle.com/technology/oramag/oracle/06-mar/o26odpnet.html">Oracle
Database Change Notification</a> 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 <a
href="otl3_compile.htm#OTL_ORA_SUBSCRIBE">OTL_ORA_SUBSCRIBE</a>. See
also example <a href="otl4_ex585.htm">585</a>.<br>
<br>
</font></font></span></li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">New in (OTL 4.0.158):<br>
<br>
<ul>
<li>When #define <a
href="otl3_compile.htm#OTL_UNICODE_EXCEPTION_AND_RLOGON">OTL_UNICODE_EXCEPTION_AND_RLOGON</a>
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 (<font size="-1">"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:<br>
<br>
<span style="font-family: monospace;"> <span
style="font-weight: bold; font-style: italic;">Before </span><span
style="font-style: italic;"></span>(line 9678):</span><br
style="font-family: monospace;">
<br style="font-family: monospace;">
<span style="font-family: monospace;">
status=SQLDriverConnect</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
(hdbc,</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
0,</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
temp_connect_str2,</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
OTL_SCAST(short,len),</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
out_str,</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
sizeof(out_str),</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
&out_len,</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
SQL_DRIVER_NOPROMPT);<br>
<br>
<span style="font-weight: bold; font-style: italic;">Now </span></span></font><font
size="-1"><span style="font-family: monospace;">(line 9678):</span></font><font
size="-1"><span style="font-family: monospace;"><span
style="font-weight: bold; font-style: italic;"></span><br>
<br>
status=SQLDriverConnect<br>
(hdbc,<br>
0,<br>
temp_connect_str2,<br>
OTL_SCAST(short,len),<br>
out_str,<br>
sizeof(out_str)<span
style="font-weight: bold; color: rgb(255, 0, 0);">/sizeof(SQLWCHAR)</span>,<br>
&out_len,<br>
SQL_DRIVER_NOPROMPT);<br>
<br>
</span></font></li>
<li><font size="-1">In OTL/OCI8/9/10 a break
statetement was missing in<span style="font-family: monospace;"><br>
<br>
27195 void open<br>
27196 (const otl_stream_buffer_size_type arr_size,<br>
const char* sqlstm,<br>
otl_connect& db,<br>
const char*
ref_cur_placeholder=0,<br>
const char* sqlstm_label=0)<br>
OTL_THROWS_OTL_EXCEPTION<br>
...<br>
27213 case otl_select_stream_type:<br>
...<br>
<span style="color: rgb(255, 0, 0);">break;</span><br>
<br>
</span>The bug is fixed is this release.<br>
<br>
</font></li>
<li><font size="-1">Following new #define is introduced: <a
href="otl3_compile.htm#OTL_MAP_LONG_TO_SQL_C_SBIGINT">OTL_MAP_LONG_TO_SQL_C_SBIGINT</a>.
It maps 64-bit longs into SQL_C_BIGINT instead of SQL_C_SLONG in
OTL/ODBC/DB2-CLI.<br>
<br>
</font></li>
<li><font size="-1"><span style="font-family: monospace;"></span>The
<a href="otl3_faq.htm#MYSQL">question</a> on MySQL in the
F.A.Q was corrected to explain that InnoDB type tables can be used with
OTL.<br style="font-family: monospace;">
<br>
</font></li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">New in (OTL 4.0.157):<br>
<br>
<ul>
<li>A problem was reported that OTL doesn't compile with aCC
(HP
ANSI C++ B3910B A.03.63), and it requires #define <a
href="otl3_compile.htm#OTL_NO_TMPL_MEMBER_FUNC_SUPPORT">OTL_NO_TMPL_MEMBER_FUNC_SUPPORT</a>
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.<br>
<br>
</li>
<li>A problem was reported that when OTL is used with <a
href="http://stlport.org">STL Port</a>, 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
<a href="otl3_compile.htm#OTL_UNCAUGHT_EXCEPTION_ON">OTL_UNCAUGHT_EXCEPTION_ON</a>
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: <a
href="otl3_compile.htm#OTL_UNCAUGHT_EXCEPTION_OWN_NAMESPACE">OTL_UNCAUGHT_EXCEPTION_OWN_NAMESPACE</a>.<br>
<br>
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.<br>
<br>
</li>
<li>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.<br>
<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">New (in OTL 4.0.156):<br>
<br>
<ul>
<li>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. <br>
<br>
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -