📄 otl3_whatn.htm
字号:
<br>
</li>
<li>The <a href="otl3_faq.htm">F.A.Q.</a> has more answers
the following questions:<br>
<br>
</li>
<ul>
<li><small><font size="+1"><small>Why <a
href="otl3_faq.htm#Nested_Query">nested queries</a> with
bind variables do
not work in MS SQL Server?</small></font></small></li>
<li><small><font size="+1"><small>How do I connect to my
database <a href="otl3_faq.htm#NO_DSN">without</a>
creating an ODBC DSN?</small></font></small><br>
<small><font size="+1"><small><br>
</small></font></small></li>
</ul>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">New (in OTL 4.0.145):<br>
<br>
<ul>
<li>Basic support for MS SQL 2005
VARCHAR(MAX) and VARBINARY(MAX) is introduced in this release.
VARCHAR(MAX) and VARBINARY(MAX) data types are "replacements" for "old"
TEXT and IMAGE. The new types are not quite backward compatible as far
as MS SQL ODBC is concerned. Basically it works, only the OTL <a
href="otl3_stream_class.htm#set_lob_stream_mode">LOB stream mode</a>
doesn't work. I'd appreciate very much if somebody could point me
to an ODBC
based code example that demonstrates how to use VARCHAR(MAX) /
VARBINARY(MAX) in piece-wise read/write modes.<br>
<br>
</li>
<li>The following code examples have been introduced to
demonstrate more [new] features and code techniques:<br>
<br>
</li>
<ul>
<li><b><a href="otl4_ex468.htm">Example 468 (MS SQL Server
2005 and
VARCHAR(MAX))</a></b></li>
<li><b><a href="otl4_ex469.htm">Example 469 (MS SQL Server
2005 and
VARBINARY(MAX))</a></b></li>
<li><b><a href="otl4_ex470.htm">Example 470 (MS SQL Server
2005,
INSERT with OUTPUT clause)</a></b></li>
<li><b><a href="otl4_ex471.htm">Example 471 (DB2, stored
procedure
with output parameters and a return code)</a></b></li>
<li><b><a href="otl4_ex472.htm">Example 472 (DB2,
Insert/Implicit Result Set (Stored
Proc) /Update)<br>
<br>
</a></b></li>
</ul>
<li>This release enforces the minimum size of 2 characters in
<span style="font-family: monospace;">:var<char[xxx]></span>
declarations. The reason is that char[1] is invalid because OTL
char[xxx] variables are <a href="otl3_bind_variables.htm#char">null
terminated</a> strings. <span style="font-family: monospace;">#define <a
href="otl3_compile.htm#OTL_ADD_NULL_TERMINATOR_TO_STRING_SIZE">OTL_ADD_NULL_TERMINATOR_TO_STRING_SIZE</a></span>
adds one character to the string length, which makes <span
style="font-family: monospace;">:var<char[1]></span> a valid
declaration. <br>
<br>
</li>
<li>OTL <a href="#40138">4.0.138</a> relaxed the requirement
of presetting the LOB length before the first chunk of the LOB gets
written to the LOB stream (<a href="otl3_lob_stream.htm">otl_lob_stream)</a>,
which changed the ODBC / DB2 CLI function call sequence. A bug was
reported that when
a LOB stream is used for writing the LOB value, and the stream gets
destroyed before the end of the row, which LOB was written to, it
causes the "invaid function call sequence" error. The actual error
message is different in different database types,. The bug is fixed in
this release. This problem affects only ODBC and DB2 CLI applications,
and only if the LOB stream is destroyed before the end of the row. The
following [long] piece of code demonstrates the problem:</li>
<br>
<span style="font-family: monospace;"><small><small><small>void
insert()<br>
// insert rows into table<br>
{<br>
otl_long_string f2(6000); // define long string variable<br>
otl_stream o; // defined an otl_stream variable<br>
o.set_lob_stream_mode(true); <br>
// set the "lob stream mode" flag<br>
o.open(1, <br>
// buffer size has to be set to 1 for operations with LOBs<br>
"insert into test_tab "<br>
"values(:f1<int>,:f2<varchar_long>, "<br>
":f3<varchar_long>) ",<br>
//
SQL statement<br>
db // connect object<br>
);<br>
o.set_commit(0); <br>
// setting stream "auto-commit" to "off". It is required<br>
// when LOB stream mode is used.<br>
<br>
int i,j;<br>
otl_lob_stream *lob; <br>
// LOB stream for reading/writing unlimited number<br>
// of bytes regardless of the buffer size.<br>
otl_lob_stream *lob2; <br>
// LOB stream for reading/writing unlimited number<br>
// of bytes regardless of the buffer size.<br>
<br>
for(i=1;i<=20;++i){<br>
lob = new otl_lob_stream;<br>
lob2 = new otl_lob_stream;<br>
<br>
o<<i;<br>
o<<*lob; // Initialize otl_lob_stream by writing it<br>
// into
otl_stream.<br>
o<<*lob2; // Initialize otl_lob_stream by writing it<br>
// into
otl_stream.<br>
<br>
for(j=0;j<5000;++j)<br>
f2[j]='*';<br>
f2[5000]='?';<br>
f2.set_len(5001);<br>
<br>
<span style="color: rgb(153, 102, 51);"> // OTL <
4.0.138</span><br style="color: rgb(153, 102, 51);">
<span style="color: rgb(153, 102, 51);">
lob->set_len(5001+2123); // setting the total size of</span><br
style="color: rgb(153, 102, 51);">
<span style="color: rgb(153, 102, 51);">
// the TEXT to be written.</span><br style="color: rgb(153, 102, 51);">
*lob<<f2; // writing first chunk of the TEXT
into lob<br>
<br>
<br>
f2[2122]='?';<br>
f2.set_len(2123); // setting the size of the second chunk<br>
<br>
*lob<<f2; // writing the second chunk of the TEXT into lob<br>
lob->close(); // closing the otl_lob_stream<br>
<br>
<span style="color: rgb(255, 102, 102);"> <span
style="color: rgb(255, 0, 0);"> delete lob; <br>
// here is a problem (in OTL 4.0.138 - 4.0.144), <br>
// OK in 4.0.145 (this release)<br>
</span></span> // not the<span
style="font-style: italic;"> end of the row</span>
yet<br>
for(j=0;j<5000;++j)<br>
f2[j]='*';<br>
f2[5000]='?';<br>
f2.set_len(5001);<br>
</small></small></small></span>
</ul>
<span style="font-family: monospace; color: rgb(153, 102, 51);"><small><small><small>
// OTL < 4.0.138<br>
</small></small></small></span>
<ul>
<span style="font-family: monospace;"><small><small><small><span
style="color: rgb(153, 102, 51);"> lob2->set_len(5001+2123);
// setting the total size of</span><br
style="color: rgb(153, 102, 51);">
<span style="color: rgb(153, 102, 51);">
// the TEXT to be written.</span><br style="color: rgb(153, 102, 51);">
*lob2<<f2; // writing first chunk of the TEXT into lob<br>
<br>
f2[2122]='?';<br>
f2.set_len(2123); // setting the size of the second chunk<br>
<br>
*lob2<<f2; // writing the second chunk of the TEXT into lob<br>
lob2->close(); // closing the otl_lob_stream<br>
// end of the row<br>
<span style="color: rgb(51, 204, 0);">//delete lob; // deleting
here is OK</span><br>
delete lob2;<br>
} </small></small></small></span><span
style="font-family: monospace;"></span><br>
</ul>
</td>
</tr>
<tr>
<td style="vertical-align: top;">New (in OTL 4.0.144):<br>
<br>
<ul>
<li>OTL (4.0.129 - 4.0.143) did not compile with the real
OCI 8.0 header files. There was the following compilation error:<br>
<br>
<span style="font-family: monospace;">C2065:
'OCI_PARSE_ONLY' : undeclared identifier<br>
<br>
</span>The error is fixed in this release..<span
style="font-family: monospace;"></span><br>
<br>
</li>
<li>PostgreSQL 8.2 is out. This release has been successfully
tested with PostgreSQL 8.2.<br>
</li>
</ul>
</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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -