📄 otl3_prob.htm
字号:
<br>
<li>
<a NAME="prob43"></a><b>43. </b>A problem with OTL/OCI8 and CLOBs/BLOBs:
when a LOB value is being written to the database, if a database error
occurs, in some cases no otl_exception gets raised. This may happen if
the database error occurs in the OCILobWrite() OCI8 call. I guess I overlooked
this specific extreme case because LOB operations are done separately from
SQL statements associated with the LOBs, and it's hard to set up a proper
test case for stuff like this. Luckily enough :-), someone ran into this,
and the problem was reported. <i><font color="#800000">This problem has
been fixed in OTL 3.2.11.</font></i></li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<li>
<a NAME="prob42"></a><b>42. </b>A problem with ANSI C++ compiler in HP
UX: aCC. The problem is that when OTL's #define OTL_STL is defined, it
triggers the inclusion of STL files like <vector>, <iterator>, <string>,
<iostream>. Also, OTL assumes that <i>namespace std
</i>is defined.
aCC is just an ANSI C++ compliant compiler, no more, no less. HP Corp.
purchased a license for using and distributing the Rogue Wave version of
STL. For a reason, known only to HP and RW, namespace std is not configured
in the STL that goes with aCC. Here goes the dilemma: you have a C++ compiler,
that compiles ANSI C++, but the libraries are pre-standard.<i><font color="#800000">This
problem has been fixed in OTL 3.2.10.</font></i></li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<li>
<a NAME="prob41"></a><b>41. </b>A compilation problem with static inline
functions in the OTL header file and Visual Age C++ 5 in AIX.<i><font color="#800000">This
problem has been fixed in OTL 3.2.9.</font></i></li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<li>
<a NAME="prob40"></a><b>40. </b>A compilation problem with OTL/OCI8 3.2.8.,
Sun C++ Workshop 5.0 and Oracle 8.0.5 in Solaris. This compilation error
was intoruced in OTL 3.2.8 in the otl_connect_logoff() function.<i><font color="#800000">This
problem has been fixed in OTL 3.2.9.</font></i></li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<li>
<a NAME="prob39"></a><b>39. </b>A compilation problem with OTL/DB2-CLI
and xlC in AIX: OTL for DB2-CLI does not compile with xlC (C++ compiler
in AIX).<i><font color="#800000">This problem has NOT been fixed YET.</font></i></li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<li>
<a NAME="prob38"></a><b>38. </b>A problem with a few annoying compilation
warnings. No further details. You may notice, when compiling OTL with your
C++ compiler, that there are fewer compilation warnings on the output.<i><font color="#800000">This
problem has been fixed in OTL 3.2.8.</font></i></li>
<br>
<li>
<a NAME="prob37"></a><b>37. </b>A problem with otl_connect::logoff(). When
the database back end goes down / becomes unavailable exactly at the moment
after the very last transaction was already closed (committed or rolled
back), and when logoff() is being / about to be called, the logoff() does
not throw any otl_exception, it just "ignores the fact." The problem was
uncovered by someone, who was curious enough to try to run "kill -9 all_oracle_processes"
just before calling logoff(). This problem might be potentially more of
a problem in multi-threaded applications. I, myself, tried it with Oracle
8i, MS SQL Server 7.0, DB2 7.1 and MySQL 3.x. The behavior of logoff()
was consistent: logoff() did not raise any otl_exception. Another part
of the problem was that with Oracle 7.3, more than one otl_exception was
raised, and, it resulted [in some cases] in the program's crash, depending
upon the C++ compiler to be used. I had to make up an otl_exception throw
counting scheme, in order to prevent more than one otl_exception's from
being thrown. <i><font color="#800000">This problem has been fixed in OTL
3.2.8.</font></i></li>
<br>
<li>
<a NAME="prob36"></a><b>36. </b>A problem with operators << in otl_stream's.
Namely, the problem was showing up in the operators <<, when the
stream was opened with either a straight SELECT statement (all versions
of OTL), or a SELECT statement via reference cursor (OTL/OCIx), or a SELECT
statement via implicit result set (OTL/ODBC, OTL/DB2-CLI). The problem
is that when you enter a NULL value into such a stream via operator<<(const
otl_null), all subsequent values that are being entered into the same bind
variables, no matter what values, are showing as NULLs. Typically, SELECT
statements [of all kinds] have bind variables/placeholders in their WHERE
clauses. NULLs in the WHERE clause are not used very often. As a matter
of fact, they are very rare. That's why the problem just started showing
up, and has not been detected before. <i><font color="#800000">This problem
has been fixed in OTL 3.2.8.</font></i></li>
<br>
<li>
<a NAME="prob35"></a><b>35. </b>A problem was reported in OTL/ODBC: <long>
as a bind variable specifier did not work properly because of the "out
of range" error raised by the ODBC driver. <i><font color="#800000">This
problem has been fixed in OTL 3.2.6.</font></i></li>
<br>
<li>
<a NAME="prob34"></a><b>34. </b>A problem was reported in OTL/OCIx that
the new otl_XXX_vec containers for PL/SQL tables were causing the compilation
warning that the constructors of the classes were not virtual but the classes
contained virtual functions. <i><font color="#800000">This problem has
been fixed in OTL 3.2.6.</font></i></li>
<br>
<li>
<a NAME="prob33"></a><b>33. </b>A problem was reported in OTL/ODBC that
in some cases an otl_exception gets thrown when SQLExecute() is executed
inside the OTL. <i><font color="#800000">This problem has been fixed in
OTL 3.1.19.</font></i></li>
<br>
<li>
<a NAME="prob32"></a><b>32. </b>A compilation problem was reported for
OTL 3.1.16 and Sun C++ 4.2. The thing is that OTL 3.1.14-16 were made more
compliant with the ANSI C++ standard, that is, compilable with C++ compilers
like HP ANSI C++ (aCC). The changes that were made to OTL 3.1.14-16, affected
compilation of OTL with Sun C++ 4.2. <i><font color="#800000">This problem
has been fixed in OTL 3.1.17. </font></i>Also, it is worth mentioning that
OTL 3.1.17 now compiles with xlC (AIX).</li>
<br>
<li>
<b>31. </b>A minor problem in otl_connect::server_attach (OTL/OCI8 only).
The problem was that the return code of OCIServerAttach() was not properly
checked and the OCISessionBegin() function call was reporting an error
different from the original error [that would have been reported by the
OCIServerAttach]. Typically, if there is a problem with SQL*Net, you would
see an error about user authentication or user id/password. <i><font color="#800000">This
problem has been fixed in OTL 3.1.15.</font></i></li>
<br>
<li>
<a NAME="aCC_comp"></a><b>30. </b>A number of folks reported compilation
problems with the HP ANSI C++ (aCC). The problems were due to aCC's special
template instantiation mechanism and more strict error checking. After
some modifications, the OTL header file now compiles with aCC.</li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<p>Also, it was reported that in OTL/OCI8, if otl_connect::rlogon() fails,
some of the OCI8 handles associated with the connect object don't get released
even after otl_connect::logoff() is called.
<p><i><font color="#800000">These problems have been fixed in OTL 3.1.14.</font></i>
<br>
<li>
<b>29. </b>In OTL 3.1.12, a compilation error was reported for Sun C++
WorkShop 5.0. The problem was that otl_numeric_convert() (a template function)
generated a compilation error. <i><font color="#800000">This problem has
been fixed in OTL 3.1.13.</font></i></li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<p><b><i><blink>If anybody experienced the same problem, please, let me
know via email</blink></i></b>.
<br>
<li>
<b>28. </b>In OTL/OCI8, there was a compilation warning about an unused
variable in a function. <i><font color="#800000">This problem has been
fixed in OTL 3.1.12.</font></i></li>
<br>
<li>
<b>27. </b>In OTL/OCI8, if the NO_DATA_FOUND predefined exception is raised
in PL/SQL explicitly, or via the SELECT ... INTO construct, OTL does not
handle it properly. <i><font color="#800000">This problem has been fixed
in OTL 3.1.10.</font></i></li>
<br>
<li>
<b>26. </b>A copy constructor was added to the <a href="otl3_stream_class.htm#otl_datetime">otl_datetime</a>
class to make it work with the STL data container template classes. <i><font color="#800000">This
problem has been fixed in OTL 3.1.8.</font></i></li>
<br>
<li>
<a NAME="prob25"></a><b>25. </b>In OTL/OCI8, if it is compiled with OCI8.1.5
in Sun Solaris, otl_stream::<a href="otl3_stream_class.htm#describe_select">describe_select</a>()
causes the program to crash. <i><font color="#800000">This problem has
been fixed in OTL 3.1.7.</font></i></li>
<br>
<li>
<b>24. </b>This time around, it's an enhancement: a capability to override
the default mapping in SELECT statements. <i><font color="#800000">This
problem has been fixed in OTL 3.1.3.</font></i></li>
<br>
<li>
<a NAME="prob23"></a><b>23. </b>In OTL/OCI8, otl_stream::describe_select()
returns a random value in the scale field of the otl_column_desc structure.
<i><font color="#800000">This
problem has been fixed in OTL 3.1.2.</font></i></li>
<br>
<li>
<b>22. </b>When a PL/SQL table size is set higher than 32767, the program
crashes. Now, the program raises the following otl_exception: "PL/SQL table
size is too large" <i><font color="#800000">This problem has been fixed
in OTL 3.1.1.</font></i></li>
<br>
<li>
<b>21. </b>This time, it's not a problem, just a small functionality fix:
<a href="otl3_connect_class.htm#rlogon">otl_connect::rlogon</a>()
was enhanced with a second parameter: int auto_commit. This parameter allows
the user to set the "auto-commit" / "commit-on-success" mode at the connection
level, so every single SQL statement commits the current transaction. <i><font color="#800000">This
problem has been fixed in OTL 3.0.32.</font></i></li>
<br>
<li>
<b>20. </b>This time, it's not a problem, it's just a new piece of functionality:
direct_exec() now returns a rows processed count for INSERT, UPDATE and
DLETE statements; otl_stream::get_rpc() was added to the class.
<i><font color="#800000">This
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -