📄 otl3_prob.htm
字号:
<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
problem has been fixed in OTL 3.0.31.</font></i></li>
<br>
<li>
<b>19. </b>Sorry folks, I forgot to add a default constructor to the
<a href="otl3_stream_class.htm#otl_datetime">otl_datetime</a>
class in problem <a href="#prob17">17</a>. From now on, when an otl_datetime
variable is declared, it is initialized as "01/01/1900 0:0:0". <i><font color="#800000">This
problem has been fixed in OTL 3.0.28.</font></i></li>
<li>
<b>18.</b> In Alfa Unix and Oracle 7.3.4, operator<<(const long int)
raises the otl_exception that the long int input parameter is not compatible
with the long int placeholder in the otl_stream. In the data type compatibility
verification, sizeof(int) was used instead of sizeof(long), which is a
typo. It does not cause any problem in the 32-bit platforms since int=long.
However, in the 64-bit Alfa Unix <i>long</i> is 64-bit and <i>int </i>is
32-bit.. <i><font color="#800000">This problem has been fixed in OTL 3.0.27</font></i></li>
<br>
<li>
<a NAME="prob17"></a><b>17.</b> This time, it is not really a problem,
just a new piece of functionality: class <a href="otl3_stream_class.htm#otl_datetime">otl_datetime.
</a><i><font color="#800000">This
problem has been fixed in OTL 3.0.26.</font></i></li>
<br>
<li>
<b>16.</b> A "<i>return</i> <i>*this;"</i> statement was missing from one
of the overloaded assignment operators (operator=()).
<i><font color="#800000">This
problem has been fixed in OTL 3.0.25.</font></i></li>
<br>
<li>
<b>15.</b> One of the functions that is used in formatting otl_exception
messages was not thread safe. <i><font color="#800000">This problem has
been fixed in OTL 3.0.24</font></i></li>
<br>
<li>
<b>14.</b> A small memory leak was reported recently: if, say, a SQL statement
has a syntactical error, otl_stream generates an otl_exception but it doesn't
release some of the allocated memory blocks. <i><font color="#800000">This
problem has been fixed in OTL 3.0.23.</font></i></li>
<br>
<li>
<b>13.</b> General problem with too large strings as well as otl_long_string's
on the input: if the string is too large it may cause <i>access viloation
/ segmentation violation </i>runtime error and, as a result, the program
will crash. Two new <a href="otl3_exc_list.htm#32008">otl_exception's</a>
(codes: 32008, 32006) were defined to cover the gap in the OTL functionality.
From now on, OTL will throw two new exceptions. The exception can be caught
and handled properly. <i><font color="#800000">This problem has been fixed
in OTL 3.0.22. </font></i><font color="#000000">You are welcome to give
this new functionality a try and any feedback would be appreciated very
much.</font></li>
<br>
<li>
<b>12.</b> General problem: sometimes, the requirement is that the C++
compiler is used with the option when warnings are treated as errors and
also the level of warnings is set to the maximum. For example, unused arguments
in functions, warnings about typecasting (possible loss of data, etc.)
are preventing OTL from getting compiled successfully. <i><font color="#800000">This
problem has been partly fixed in OTL 3.0.20. and completely fixed in OTL
3.0.21.</font></i></li>
<br>
<li>
<b>11</b>. OTL 3.0/ODBC used ODBC 2.x function calls and because of that
the ODBC 3.x drivers for Microsoft SQL 7.0 were throwing SQL warning left
and right. OTL 3.1 was catching them and presenting them as errors to the
user. I thought I fixed <a href="#ODBC_WARN">the problem</a> in OTL 3.0.18.
However, a more drastic measure was needed -- to make OTL 3.0/ODBC compliant
with ODBC 3.x specification. So, <i><font color="#800000">OTL 3.0.19 uses
ODBC 3.x function calls and requires the underlying ODBC drivers to be
ODBC 3.x compatible. </font></i><font color="#000000">At least, I've tested
OTL 3.1/ODBC with MS SQL 7.0 ODBC drivers and Oracle 8.x ODBC drivers and
it passed all of my tests.</font></li>
<li>
<b>10</b>. <a NAME="ODBC_WARN"></a>OTL 3.1/ODBC in some cases throws
an otl_exception when it's actually an ODBC warning. <i><font color="#800000">This
problem has been fixed in OTL 3.0.18. </font></i><font color="#000000">This
problem is basically the same as the bug, fixed in OTL 3.0.14: more potential
spots in the code were found and fixed</font></li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<li>
<b>9</b>. In OTL 3.1/OCI7 and OCI8, if an <unsigned> variable is declared
in an OTL INSERT stream and then it's used to write an unsigned int value
beyond the signed int range, then it gets written as a negative into the
database. That was due to the fact that the <unsigned> variable got
actually bound to the placeholder as signed int: <int>. The wrong external
OCI datatype code was used. <i><font color="#800000">This problem has been
fixed in OTL 3.0.17.</font></i></li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<li>
<b>8.</b> Some folks don't feel comfortable with the default setting of
the otl_stream auto-commit flag. I derived the otl_nocommit_stream class
from the otl_stream. This class behaves exactly as the otl_stream except
it doesn't commit transactions. <i><font color="#800000">This problem has
been fixed in OTL 3.0.16.</font></i></li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<li>
<b>7</b>. otl_stream::set_commit() has effect only if it is called after
otl_stream::open() was called. In case if set_commit() is called before
open(), it has no effect. The symptom was that it was not possible to rollback
the current transaction since it was already committed even if set_commit(0)
was called [before open()]. <i><font color="#800000">This problem has been
fixed in OTL 3.0.1</font></i></li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<li>
<b>6</b>. OTL 3.1/ODBC in some cases throws an otl_exception when it's
actually an ODBC warning. <i><font color="#800000">This problem has been
fixed in OTL 3.0.14.</font></i></li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<li>
<b>5.</b> OTL 3.1 does not compile with Sun Workshop C++ 5.0. <i><font color="#800000">This
problem has been fixed in OTL 3.0.13</font></i></li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<li>
<b>4.</b> Some C++ compilers generate compilation errors like "Symbol otl_error_code_1
is already defined." The problem is that the symbol was defined as const
char* in the OTL header file and the compliers generated a global name.
In order to fix this kind of error, the corresponding <i>const char* </i>'s
were converted to <i>#define</i>'s to prevent the compilers from generating
named objects. <i><font color="#800000">This problem has been fixed in
OTL 3.0.12.</font></i></li>
<br>
<li>
<b>3.</b> In some cases, when an error message is returned via otl_exception,
the very last character of the message is missing. It is not a critical
bug so it was not visible. The bug was reported on Nov-29, 1999. <i><font color="#800000">This
problem has been fixed in OTL 3.0.11. </font></i>Check out the release
number in your OTL header file, if you need the fix, send an email to the
author.</li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<li>
<b>2.</b> If <a href="otl3_long_string.htm">otl_long_string</a>'s size
is set to a smaller size than the size set by <a href="otl3_connect_class.htm#set_max_long_size">otl_connect::set_max_long_size</a>(),
then the program crashes.The fix is to set the size of the otl_long_string
to a value higher than in the set_max_long_size(). <i><font color="#804040">This
problem has been fixed in OTL 3.0.10</font></i>. Check out the release
number in your OTL header file, if you need the fix, send an email to the
author.</li>
<br>
<li>
<a NAME="prob1"></a><b>1.</b>. Examples <a href="otl3_ex13.htm">13</a>
and <a href="otl3_ex17.htm">17</a> do not work with the Oracle 8.1.5 OCI.
Here are the symptoms: otl_connect::logoff() crashes the program. It appears
that there is a bug in OCI 8.1.5 or something has changed in OCI 8.1.5
compared to OCI 8.0.x and it is not documented. If anybody has a reference
to a decent example of OCI 8.1.5 and REF CURSORs, please, send the example
to me.</li>
<br>
<p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br> </ul>
<center>
<hr WIDTH="100%">
<p><a href="home.htm">Go Home</a></center>
<p>Copyright © 1996, 2008, Sergei Kuchin, email: <a href="mailto:skuchin@aceweb.com">skuchin@aceweb.com</a>,
<a href="mailto:skuchin@gmail.com">skuchin@gmail.com<script Language="JavaScript"><!-- hide from oldgmailsers
var modDate = new Date(document.lastModified)
document.write("<i> Last Updated:</i> " + (modDate.getMonth()+1) + "/" +
modDate.getDate() + "/" + "0"+(modDate.getYear())%100+".");
//-->
</script>
</a>.
<p><i>Permission to use, copy, modify and redistribute this document for
any purpose is hereby granted without fee, provided that the above copyright
notice appear in all copies.</i></ul>
</body>
</html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -