📄 otl3_whatn.htm
字号:
columns via ODBC. For example, PostgreSQL supports TIMESTAMP WITH TIME
ZONE. This version of OTL intrdoces the following new #define to
address the need: <a href="otl3_compile.htm#OTL_ODBC_TIME_ZONE">OTL_ODBC_TIME_ZONE</a>,<span
style="text-decoration: underline;"> </span><a
href="otl3_compile.htm#OTL_ODBC_STRING_TO_TIMESTAMP">OTL_ODBC_STRING_TO_TIMESTAMP</a>,
<a href="otl3_compile.htm#OTL_ODBC_TIMESTAMP_TO_STRING">OTL_ODBC_TIMESTAMP_TO_STRING</a>.
See example <a href="otl4_ex676.htm">676</a> for more detail. <br>
<br>
A problem was reported that some versions of the PostgreSQL ODBC driver
don't populate the timestamp's fractional part. The new #defines can
be used as a workaround to solve the problem. See example <a
href="otl4_ex676.htm">676</a> for more detail.<br>
<br>
</li>
<li>A problem was reported that xlC version 6 doesn't support
template member functions. The bug is fixed in this release (for xlC,
#define <a href="otl3_compile.htm#OTL_NO_TMPL_MEMBER_FUNC_SUPPORT">OTL_NO_TMPL_MEMBER_FUNC_SUPPORT</a>
gets enabled by default).<br>
<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">New (in OTL 4.0.173):<br>
<br>
<ul>
<li>The following compilation errors were reported when OTL
is being compiled under Debian on AMD64, #define <a
href="otl3_compile.htm#OTL_ODBC_UNIX">OTL_ODBC_UNIX</a>, <span
style="font-family: monospace;"></span>and #define <a
href="otl3_compile.htm#OTL_ODBC_MULTI_MODE">OTL_ODBC_MULTI_MODE</a>:<br>
<br>
<pre wrap="">In file included from test.cpp:12: <br>./otlv4.h: In member function 'int odbc::otl_sel::first(odbc::otl_cur&,<br>int&, int&, int&, int&, int)': <br>./otlv4.h:12497: error: cannot convert 'SQLULEN*' to 'SQLROWSETSIZE*'<br>for argument '4' to 'SQLRETURN SQLExtendedFetch(void*, SQLUSMALLINT,<br>SQLROWOFFSET, SQLROWSETSIZE*, SQLUSMALLINT*)' <br>./otlv4.h: In member function 'int odbc::otl_sel::next(odbc::otl_cur&,<br>int&, int&, int&, int&, int)': <br>./otlv4.h:12599: error: cannot convert 'SQLULEN*' to 'SQLROWSETSIZE*'<br>for argument '4' to 'SQLRETURN SQLExtendedFetch(void*, SQLUSMALLINT,<br>SQLROWOFFSET, SQLROWSETSIZE*, SQLUSMALLINT*)'</pre>
The problem was due incompatible imlementations of ODBC in the 64-bit
Windows, and in the 64-bit Unix ODBC package. If you read the comments
in the SQL/ODBC related header files in unixodbc, you'd see that the
implementors struggled with interpreting ambiguities in the 64-bit ODBC
specification. Nobody says that life is perfect, and there is nothing
a few #ifdefs can't fix. The problem is fixed in this release.<br>
<br>
</li>
<li><a name="LOB_NULL_BUG"></a>A bug was reported that when
OTL is used with <a href="otl3_compile.htm#OTL_DB2_CLI,">OTL_DB2_CLI</a>.,
and an <a href="otl3_stream_class.htm">otl_stream</a> is opened in the
LOB
stream mode (otl_stream::<a
href="otl3_stream_class.htm#set_lob_stream_mode">set_lob_stream_mode</a>(true)),
NULL values, say, in an INSERT statement, don't get processed
correctly. Instead of inserting a NULL, OTL inserts a non-NULL value
from a row prior to the one with the NULL. The bug is specific to
OTL/DB2-CLI. OTL introduced a tweak a couple of years ago that resets
the "NULL indicator" / "length" fields for each bind variable / array
to the default "non-NULL" right after SQLExcute() is called.
Apparently, DB2 CLI has some semi-documented behavior (maybe it's
documented, only I couldn't find the right reference, so if somebody
could point me to the right spot in the DB2 CLI manual, that would be
helpful) that the "NULL indicator" / "length" field is still used by
the DB2 CLI layer after SQLExecute() was already called under certain
conditions. The bug is fixed in this release.<br>
<br>
</li>
<li>This release introduces the following #define: <a
href="otl3_compile.htm#OTL_EXCEPTION_IS_DERIVED_FROM_STD_EXCEPTION">OTL_EXCEPTION_IS_DERIVED_FROM_STD_EXCEPTION</a>.
The #define is a shortcut for "<a href="otl3_exception_class.htm">otl_exception</a>
is derived std::excetion".<br>
<br>
</li>
<li>A few redundant calls to otl_null() were removed inside
the OTL header file.<br>
<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">New (in OTL 4.0.172):<br>
<br>
<ul>
<li>When #define <a
href="otl3_compile.htm#OTL_FREETDS_ODBC_WORKAROUNDS">OTL_FREETDS_ODBC_WORKAROUNDS</a>
is enabled, and, say, an INSERT statement is being executed against a
table, even after otl_connect::commit() is called, the table still has
an exlusive lock on the rows that were inserted into the table. The bug
is fixed in this release. It looks like the bug in FreeTDS, which
#define OTL_FREETDS_ODBC_WORKAROUNDS was meant to fix, is fixed now in
FreeTDS. Check the FreeTDS Web site for more detail. Those who still
use the version of FreeTDS with the original bug can continue using
#define OTL_FREETDS_ODBC_WORKAROUNDS.<br>
<br>
</li>
<li>When <a href="otl3_lob_stream.htm">otl_lob_stream</a> is
#defines OTL_ORAXX (where XX>=8), in a situation when a clob/blob
gets returned from a PL/SQL stored procedure call and there is another
output parameter that precedes the clob/blob, for example:<br>
<br>
<span style="font-family: monospace;">begin
<br>
GetClob(:f<char[30],out>,
:c<clob,out>);<br>
end;</span><br>
<br>
In case if the preceding output parameter is NULL (<span
style="font-family: monospace;">:f</span> is NULL), the clob (<span
style="font-family: monospace;">:c</span>) is empty . The bug is fixed
in this release. If the same parameters (<span
style="font-family: monospace;">:f</span> and <span
style="font-family: monospace;">:c</span>) get returned by a SELECT
statement, such a bug doesn't exist.<br>
<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">New (in OTL 4.0.171):<br>
<br>
<ul>
<li>#define OTL_VERSION_NUMBER in the OTL header file had a
typo, it was set to 0x0400B0L instead of 0x0400AAL. The typo is fixed
in this release.<br>
<br>
</li>
<li>The following constructor was broken:<br>
<br>
<pre wrap=""> otl_value<otl_datetime>(const otl_null&):<br><span
style="color: rgb(255, 0, 0);"> v(0),</span><br
style="color: rgb(255, 0, 0);"> ind(true)<br> {<br> }<br><br></pre>
<p>It should be<br>
</p>
<pre wrap=""> otl_value<otl_datetime>(const otl_null&):<br><span
style="color: rgb(255, 0, 0);"> v(),</span><br
style="color: rgb(255, 0, 0);"> ind(true)<br> {<br> }<br><br></pre>
<p>The bug is fixed in this release.<br>
<br>
</p>
</li>
<li>
<p>When #define OTL_ORA8I, or OTL_ORA9I, or OTL_ORA10G, or
OTL_ORA10G_R2, or OTL_ORA11G is defined along with #define OTL_UNICODE,
SELECT trigger_body FROM all_triggers only returns 50% of the trigger
body text (trigger_body is a LONG column) when read into an
otl_long_unicode_string variable. For an unknown reason (I was unable
to find any relevant information in the OCI manual,
metalink.oracle.com, or on the Internet), the OCI sometimes returns the
length of a Unicode LONG value in double-byte characters, and most of
the time the length is returned in bytes. Thus, the reason for OTL
returning 50% of the LONG text in SELECT trigger_body FROM
all_triggers. The OCI always adds a NULL terminator character to a LONG
string (in the case of Unicode, it's a double-byte NULL terminator). In
this release, OTL has been changed to rely on the NULL terminator
instead of the returned length for LONG values.<br>
</p>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">New (in OTL 4.0.170):<br>
<br>
<ul>
<li>When #define <a href="otl3_compile.htm#OTL_UNICODE">OTL_UNICODE</a>
is enabled, <a href="otl4_refcur_stream.htm">otl_refcur_stream</a>
returns incorrect Unicode characaters for NVARCHAR2 values. OTL didn't
set the OCI "Charset Form" correctly for NLS string columns (NVARCHAR2
/ NCHAR). The problem is fixed in this release.<br>
<br>
</li>
<li>When #define <a
href="otl3_compile.htm#OTL_ODBC_MULTI_MODE">OTL_ODBC_MULTI_MODE</a> is
enabled, OTL doesn't compile with 64-bit Visual C++ 2008 under 64-bit
Windows. OTL had a variable declared as SQLUINTEGER (unsigned 32-bit
integer).
The
variable was used in a call to SQLExtendedFetch() as the <i><span
class="synParam">RowCountPtr </span></i><span class="synParam">parameter</span><i><span
class="synParam">. </span></i><span class="synParam"></span><span
class="synParam">The manual for 32-bit Visual C++ 7.1 said that the </span><i><span
class="synParam">RowCountPtr </span></i><span class="synParam">should
be SQLUINTEGER*, and in the actual function signature the parameter is
SQLULEN*:<br>
<br>
</span>In the doc:<br>
<span style="font-family: monospace;">
SQLRETURN </span><b
style="color: black; background-color: rgb(160, 255, 255); font-family: monospace;">SQLExtendedFetch</b><span
style="font-family: monospace;">(</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
SQLHSTMT StatementHandle,</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
SQLUSMALLINT FetchOrientation,</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
SQLINTEGER FetchOffset,</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
</span><b
style="color: black; background-color: rgb(153, 255, 153); font-family: monospace;">SQLUINTEGER</b><span
style="font-family: monospace;">
* RowCountPtr,</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
SQLUSMALLINT * RowStatusArray);</span><br
style="font-family: monospace;">
<br>
In the header file:<br>
<span style="font-family: monospace;">
SQLRETURN SQL_API SQLExtendedFetch(</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
SQLHSTMT
hstmt,</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
SQLUSMALLINT fFetchType,</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
SQLLEN
irow,</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
SQLULEN
*pcrow,</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
SQLUSMALLINT
*rgfRowStatus);</span><br style="font-family: monospace;">
<br>
<span class="synParam">The discrepancy between the manual
and the actual function signature has been corrected in the latest MSDN
<a
href="http://msdn.microsoft.com/en-us/library/ms713591%28VS.85%29.aspx">article</a>
on SQLExtendedFetch.<br>
<br>
SQLUINTEGER and SQLULEN are not the same length in </span>64-bit
Windows, that is why there was a compilation error in the 64-bit mode.
The
problem is fixed in this release. <br>
<br>
</li>
<li>When #define <a href="otl3_compile.htm#OTL_DB2_CLI">OTL_DB2_CLI</a>
is enabled, OTL doesn't compile with DB2 CLI 7.x client's include
files: symbol SQL_XML is not defined. The problem is fixed in this
release.<br>
<br>
</li>
<li>When #define <a
href="otl3_compile.htm#OTL_ODBC_MSSQL_2005">OTL_ODBC_MSSQL_2005</a> is
enabled, <a href="otl4_stream_read_iterator.htm">otl_stream_read_iterator</a>
is attached to an <a href="otl3_stream_class.htm">otl_stream</a> that
is opened in the LOB stream mode (otl_stream::<a
href="otl3_stream_class.htm#set_lob_stream_mode">set_lob_stream_mode</a>(true)).
The stream was opened with a SELECT statement that has a "TIMESTAMP"
column, and an "IMAGE" column. Visual C++ 8's runtime's assert on a
call to strcat_s() fails. The problem is fixed in this release.<br>
<br>
</li>
<li><span style="font-weight: normal;"><small><small><span
style="font-family: monospace;"><a
href="otl3_compile.htm#OTL_ORA7_TIMESTAMP_TO_STRING">OTL_ORA7_TIMESTAMP_TO_STRING</a>
</span>and<span style="font-family: monospace;"> </span></small></small></span><a
href="otl3_compile.htm#OTL_ORA7_STRING_TO_TIMESTAMP"><span
style="font-weight: normal;"><small><small><span
style="font-family: monospace;"></span></small></small></span><span
style="font-family: monospace;">OTL_ORA7_STRING_TO_TIMESTAMP</span></a>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -