📄 otl3_prob.htm
字号:
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Author" content="Sergei Kuchin">
<meta name="GENERATOR" content="Mozilla/4.75 [en] (Win98; U) [Netscape]">
<meta name="KeyWords" content="OTL, Oracle, ODBC, DB2, CLI, database API, C++, Template Library">
<title>Oracle, Odbc and DB2-CLI Template Library, Version 3.2, Known Problems</title>
</head>
<body>
<ul>
<center>
<h1>
Oracle, Odbc and DB2-CLI Template Library, Version 3.2</h1></center>
<center>
<h1>
Known Problems</h1></center>
If you have found a problem or a bug in OTL 3.2, feel free to send an email
to <a href="mailto:skuchin@aceweb.com">skuchin@aceweb.com</a>,
<a href="mailto:skuchin@gmail.com">skuchin@gmail.com/a>.
The following is the list of known problems in OTL 3.2:
<ul>
<li>
<a NAME="prob63"></a><b>63. </b>The program crashes when there is a typo
in a bind variable declaration inside a SQL statement to be passed as a
second parameter into an otl_stream.E.g.: "INSERT INTO my_tab VALUES(:f1<<i>date</i>>,:f2<int>)",
<i>date</i>
is not a legimitate type definition (it should be <i>timestamp</i>).
Ideally, OTL should just spit out an otl_exception. <i><font color="#800000">This
problem has been fixed in OTL 3.2.20.</font></i></li>
<br>
<li>
<a NAME="prob62"></a><b>62. </b>In an otl_stream with a SELECT statement,
when eof()!=1 yet (that is, not all rows were fetched from the SELECT statement,
or it's not the end of the fetch sequence yet), if otl_streaqm::rewind()
gets called in OTL/ODBC, the following ODBC error gets returned: "Cursor
is in invalid state." This error is due to the fact that the ODBC statement
handle needs to be closed with the SQL_CLOSE
option, before the SELECT
statement may be executed again. <i><font color="#800000">This problem
has been fixed in OTL 3.2.20.</font></i></li>
<br>
<li>
<a NAME="prob61"></a><b>61. </b>For OTL/OCI8, the maximum number of bind
variables/SELECT output columns was increased from 512 to 1024 to
match the Oracle 8(i) limit.Some cases were reported when more than 512
SELECT output columns were used and and it caused the program core dump.
<i><font color="#800000">This
problem has been fixed in OTL 3.2.19.</font></i></li>
<br>
<li>
<a NAME="prob60"></a><b>60. </b>OTL does not compile with <a href="http://www.stlport.org">STLPort
4.0</a> when #define OTL_STL is on. <i><font color="#800000">This
problem has been fixed in OTL 3.2.17.</font></i></li>
<br>
<li>
<a NAME="prob59"></a><b>59. </b>Under #define OTL_ORA7, otl_stream in the
<i>referenced
cursor</i> mode generates: "Maximum open cursors exceeded." It happens
because the second cursor, that gets allocated behind the scenes
for the referenced cursor itself (not for the master PL/SQL block), does
not get released in the process of closing the otl_stream.
<i><font color="#800000">This
problem has been fixed in OTL 3.2.16.</font></i></li>
<br>
<li>
<a NAME="prob58"></a><b>58. </b>A problem in reading unitialized (NULL)
CLOBs/BLOBs. The problem occurs in the regular mode as well as the stream
mode. The problem is that when a NULL LOB gets read from the stream, the
LOB's length should be showing up as 0 if the LOB gets fetched into
an otl_long_strnig buffer, or a otl_lob_stream. Instead, the otl_stream
spit out an otl_exception. <i><font color="#800000">This problem
has been fixed in OTL 3.2.16.</font></i></li>
<br>
<li>
<a NAME="prob57"></a><b>57. </b>otl_long_int_vec, when used in otl_stream
operations, generates ""Incompatible data types in stream operation." <i><font color="#800000">This
problem has been fixed in OTL 3.2.16.</font></i></li>
<br>
<li>
<a NAME="prob56"></a><b>56. </b>A general compilation problem with Sun
C++ Workshop 5.0, when #define OTL_STL is defined. Most probably, it is
a bug in the compiler, because I was unable to find any rational explanation
for this error. <i><font color="#800000">This problem has not been fixed
yet.</font></i></li>
<br>
<li>
<a NAME="prob55"></a><b>55. </b>In some cases, when OTL is compiled with
tools like Bounds Checker, Heap Agent, Purify, Code Guard, etc., the tools,
which catch memory leaks or other types of resource leaks / mismacthes,
get confused by mismacthing pairs of new[] / delete. It works okay, but
for the sake of making the OTL a better product, some cleanup work needs
to be done. <i><font color="#800000">This problem has been fixed in OTL
3.2.15.</font></i></li>
<br>
<li>
<a NAME="prob54"></a><b>54. </b>A few compilation warnings in Sun C++ Workshop
5.0, saying something about hiding variables / parameters / objects. A
small inconvenience I'd say. <i><font color="#800000">This problem has
been fixed in OTL 3.2.15</font></i></li>
<br>
<li>
<a NAME="prob53"></a><b>53. </b>A general problem with the otl_stream's
destructor which tries to <i>auto-flush</i> its buffer in case, say, INSERT,
UPDATE or DELETE SQL statements, or a call to a stored procedure / PL/SQL
block. In case if an unrelated [to OTL] exception is being thrown, and
the destructor is being called as part of the <i>stack unwinding</i>, and
at the same time the database connection gets cut off, because of, say,
the database backend's shutdown was completed at the exact same moment.
Under all of these conditions, if they happen simultaneously, the auto-flushing
of the buffer will result in the second exception, thrown by the destructor.
Despite the fix for problem <a href="#prob46">46</a>, released with OTL
3.2.13, the problem has not completely gone away because some C++ compilers
do not really support the ANSI C++ standard. <i><font color="#800000">This
problem has been fixed in OTL 3.2.15</font></i></li>
<br>
<li>
<a NAME="prob52"></a><b>52. </b>A problem with the otl_stream::get_rpc()
as well as the otl_cursor::direct_exec() functions. The problem is that
the first time around the functions return a value greater than 0, meaning
that the row process count was > 0, that is a non-zero number of records
were processed, say, deleted. Then, the second time around, if the actual
number of records to be processed equals zero, the functions will return
the non-zero value recorded in the previous operation.This problem had
something to do with the <i>dirty</i> flag inside the stream, and the re-initialization
of the internal <i>rpc</i> variable was located after the checking of <i>if(dirty)
return</i>. The fix was obvious. <i><font color="#800000">This problem
has been fixed in OTL 3.2.15</font></i></li>
<br>
<li>
<a NAME="prob51"></a><b>51. </b>A problem in <a href="otl3_long_string.htm">otl_long_string</a>:
the constructors or an otl_long_string with <a href="otl3_long_string.htm#gen_constr0">internal
buffer</a> and for an otl_long_string with <a href="otl3_long_string.htm#gen_constr">external
buffer</a> did not set the dynamic length of the string on the input. And,
because of that, the developer had to explicitly call the otl_long_string::<a href="otl3_long_string.htm#set_len">set_len</a>()
function.I consider this rather inconveniece than a bug. Anyway, <i><font color="#800000">this
problem has been fixed in OTL 3.2.14</font></i></li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<li>
<a NAME="prob50"></a><b>50. </b>A general problem in OTL: a memory leak,
when otl_exception's get raised, under certain conditions, especially in
case of repeated otl_exception's, say, when otl_exception's are used as
a means to communicate messages from the database back end. It's really
hard to positively identify under conditions of what sort the memory leak
happens. I did some internal restructuring of the code to implement the
new features for OTL 3.2.14, and the memory leak disappeared. <i><font color="#800000">This
problem has been fixed in OTL 3.2.14</font></i></li>
<br>
<li>
<a NAME="prob49"></a><b>49. </b>A problem in OTL/ODBC and OTL/DB2-CLI:
bulk operations with SQL_LONGVARCHAR and SQL_LONGVARBINARY are supported
by ODBC and DB2-CLI but the operations were notsupported by OTL/ODBC and
OTL/DB2-CLI. This feature is useful for optimizing performance of operations
on a large number of relatively small LOBs. For more detail on how the
LOB data types get mapped to the ODBC SQL_LONGVARCHAR and SQL_LONGVARBINARY,
see the manuals on the actual ODBC drivers and DB2-CLI..<i><font color="#800000">This
problem has been fixed in OTL 3.2.13.</font></i></li>
<br>
<li>
<a NAME="prob48"></a><b>48. </b>A problem in OTL/ODBC: MS SQL Server's
data type uniqueidentifier (GUID) was not supported.<i><font color="#800000">This
problem has been fixed in OTL 3.2.13</font></i></li>
<br>
<li>
<a NAME="prob47"></a><b>47. </b>A problem with extracting ODBC's diagnostic
records. In general, there may be more than one record. otl_exception (in
OTL/ODBC) retrieves only the very first record by calling SQLGetDiagRec(...,1,...).
It is 99.5% sufficient in database applications. However, there are rare
cases when the ODBC drivers may return multiple Diag Records.Mostly, cases
like that are limited to MS SQL Server. I have not seen any other [except
for MS SQL Server ODBC driver] ODBC driver returning more than one Diag
Rec.<i><font color="#800000">This problem has been fixed in OTL 3.2.13</font></i></li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<li>
<a NAME="prob46"></a><b>46. </b>A general problem with otl_stream when
it was opened with INSERT, DELETE, UPDATE statement, or PL/SQL block /
stored procedure call which has output bind variable(s) in it. The otl_stream
descructor (<i>~otl_stream::otl_stream()</i>) checks to see if the its
output buffer is <i>dirty. </i>If it is, the destructor tries to execute
the SQL statement. If the SQL statement fails, the destructor, in its turn,
tries to raise an otl_exception. There may be a situation when the destructor
gets called as part of the so-called <i>stack unwinding</i>. This may happen
if any C++ expection gets thrown, even an exception, unrelated to the OTL
environment. In that case, a stack unwinding takes place, and as a result
[of more than one exception being thrown], the program crashes / aborts
/ terminates.</li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<p>A partial solution was implemented in OTL earlier.The solution covered
only the case when an otl_exception is being raised in an otl_stream, or
otl_cursor::dierct_exec(), opened under the same otl_connect object. In
this case, the <i>in-exception</i> flag gets propagated correctly to all
the OTL objects for the same otl_connect, and otl_stream destructors know
about the pending otl_exception and behave correctly.
<p>ANSI C++ offers a generic solution in the form of the <i>bool uncaught_exception()</i>
function.The function returns <i>true</i> if an exception is pending, or,
in other words, if the program is in the state of stack unwinding. Uncaught_exception()
is specific to implementation of each C++ compiler. Not every C++ compiler
supports it correctly, even if the compiler is claimed to be ANSI C++.
For example, VC++ 6.0 implements the function but it always returns <i>false,
</i>very
much typical for mothertruckers from Miscrosoft. Fortunately, many other
C++ compilers like GNU C++, Borland C++, Sun C++ Workshop, etc., do support
the function and OTL can rely on it.<i><font color="#800000">This problem
has been fixed in OTL 3.2.13.</font></i>
<br>
<li>
<a NAME="prob45"></a><b>45. </b>A compilation problem when a const
<a href="otl3_value.htm">otl_value</a>
varaiable is defined and otl_value::is_null() is being referenced The <i>const</i>
keyword was typed in the function declaration not after the function prototype
but after the function body:
<i>is_null(...) {...} const</i>.<i><font color="#800000">This
problem has been fixed in OTL 3.2.13.</font></i></li>
<br>
<li>
<a NAME="prob44"></a><b>44. </b>A fix of problem <a href="#prob37">37</a>
introduced another bug (or feature if you will). The fix contains a new
mechanism of counting (<i>throw_count</i> field in the otl_connect structure)
otl_exception's, to prevent multiple otl_exception's from bein raised,
and to eventually prevent the program's crash that happens under certain
conditions. When the exception is successfully caught and handled, theoretically,
the <i>throw_count</i> needs to be reset to 0 in the otl_exception catch
block. It does not happen. The fix for this new problem is as follows:
any subsequent OTL function call which may implicitly open or close transaction,
open an otl_stream or directly execute a SQL statement, sets the throw_count
back to 0. <i><font color="#800000">This problem has been fixed in OTL
3.2.12.</font></i></li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -