📄 otl3_whatn_1.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>
<table border="1">
<caption><br>
</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.143):<br>
<br>
<ul>
<li>When OTL steram reads a Binary Large Object value (LONG
RAW, BLOB, IMAGE, etc.) into an <a href="otl3_long_string.htm">otl_long_string,</a>
the long string gets NULL terminated (0-byte terminated), which is not
correct. It didn't matter when the otl_long_string's buffer size is
greater or equal to the BLOB size + 1. In the case if the buffer size
equals the BLOB size, the program crashes. The bug has been fixed in
this release.<br>
<br>
Character Large Objects (LONG, CLOB, TEXT, etc.) do get NULL terminated
for backward compatibility with NULL terminated C strings / character
arrays. <br>
<br>
</li>
<li>The following bind variable declaration caused some
confusion: <span style="font-family: monospace;">:f1<char></span>.
The problem was that such a declaration <a
href="otl3_bind_variables.htm#INVALID_CHAR">invalid,</a> but OTL
didn't enforce it. From this realeas on, OTL is going to throw an
otl_exception.<br>
<br>
</li>
<li>OTL 4.0.140 introduced support for <a
href="otl3_bind_variables.htm#raw">raw</a>[XXX]. A problem was
reported that when raw[XXX] is used to bind a variable to a
stored procedure output parameter, OTL doesn't return values into the
bind variable correctly. The problem was fixed in this release.<br>
<br>
</li>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">New (in OTL 4.0.142):<br>
<br>
<ul>
<li>A potential problem in OTL was found with a code analysis
tool (<a href="http://www.coverity.com">Coverity</a>). The problem has
been
fixed in this release. The problem was in the following code:<br>
<br>
<span style="font-family: monospace;">
otl_column_desc& operator=(const otl_column_desc& desc)</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> {</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> ...</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
}else if(name_len_<desc.name_len_){</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
...<br>
strcpy(name,desc.name);</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">}</span><br
style="font-family: monospace;">
<br>
The code analysis tool found that desc.name can be NULL, so that the
strcpy() would crash the program. In reality, if desc.name_len_ > <span
style="font-family: monospace;">name_len_ >= </span>0<span
style="font-family: monospace;">, </span>desc.name_ will always be
defined. So, it's a false positive. I added a check for NULL for
desc.name_ anyway in order to make the tool happy:<br>
<br>
<span style="font-family: monospace;">
otl_column_desc& operator=(const otl_column_desc& desc)</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> {</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> ...</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
}else if(name_len_<desc.name_len_ <span
style="font-weight: bold; font-style: italic;">&& desc.name_!=0</span>){</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> ...</span><br
style="font-family: monospace;">
<br>
</li>
<li>The problem was reported that when a CHAR() column is
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>
<span style="font-family: monospace;">SELECT
f2 FROM test_tab WHERE f2=:f2<char[31]></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>
<a name="HIT_IN_HEAD"></a>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>
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 "<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;"> -W<br>
-Wall<br>
-Wcast-align<br>
-Wcast-qual<br>
-Wcomments<br>
-Wconversion<br>
-Wctor-dtor-privacy<br>
-Werror<br>
-Wextra<br>
-Wformat<br>
-Wno-uninitialized<br>
-Wnon-virtual-dtor<br>
-Wold-style-cast<br>
-Woverloaded-virtual<br>
-Wparentheses<br>
-Wpointer-arith<br>
-Wreorder<br>
-Wshadow<br>
-Wsign-compare<br>
-Wsign-promo <br>
-Wstrict-aliasing=2<br>
-Wstrict-null-sentinel<br>
-Wundef<br>
-Wunused<br>
-Wunused-variable<br>
-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>
"begin "<br>
" PKG_TEST.my_prc(:p_arr<char[2000],<span
style="font-weight: bold; font-style: italic;">in[2000]</span>>); "<br>
" PKG_TEST.proc_1(<span
style="font-style: italic;">:PAR1</span><CHAR[32000],IN>); "<br>
" PKG_TEST.proc_2(<span
style="font-style: italic;">:PAR2</span><CHAR[32000],IN>); "<br>
"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, 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, a new
OTL type code contstant has been added in identify bind variable of the
raw[XXX] type:<br>
<br>
<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>
<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>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -