-
63. 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<date>,:f2<int>)",
date
is not a legimitate type definition (it should be timestamp).
Ideally, OTL should just spit out an otl_exception. This
problem has been fixed in OTL 3.2.20.
-
62. 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. This problem
has been fixed in OTL 3.2.20.
-
61. 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.
This
problem has been fixed in OTL 3.2.19.
-
60. OTL does not compile with STLPort
4.0 when #define OTL_STL is on. This
problem has been fixed in OTL 3.2.17.
-
59. Under #define OTL_ORA7, otl_stream in the
referenced
cursor 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.
This
problem has been fixed in OTL 3.2.16.
-
58. 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. This problem
has been fixed in OTL 3.2.16.
-
57. otl_long_int_vec, when used in otl_stream
operations, generates ""Incompatible data types in stream operation." This
problem has been fixed in OTL 3.2.16.
-
56. 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. This problem has not been fixed
yet.
-
55. 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. This problem has been fixed in OTL
3.2.15.
-
54. A few compilation warnings in Sun C++ Workshop
5.0, saying something about hiding variables / parameters / objects. A
small inconvenience I'd say. This problem has
been fixed in OTL 3.2.15
-
53. A general problem with the otl_stream's
destructor which tries to auto-flush 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 stack unwinding, 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 46, 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. This
problem has been fixed in OTL 3.2.15
-
52. 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 dirty flag inside the stream, and the re-initialization
of the internal rpc variable was located after the checking of if(dirty)
return. The fix was obvious. This problem
has been fixed in OTL 3.2.15
-
51. A problem in otl_long_string:
the constructors or an otl_long_string with internal
buffer and for an otl_long_string with external
buffer 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::set_len()
function.I consider this rather inconveniece than a bug. Anyway, this
problem has been fixed in OTL 3.2.14
-
50. 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. This
problem has been fixed in OTL 3.2.14
-
49. 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..This
problem has been fixed in OTL 3.2.13.
-
48. A problem in OTL/ODBC: MS SQL Server's
data type uniqueidentifier (GUID) was not supported.This
problem has been fixed in OTL 3.2.13
-
47. 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.This problem has been fixed in OTL 3.2.13
-
46. 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 (~otl_stream::otl_stream()) checks to see if the its
output buffer is dirty. 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 stack unwinding. 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.
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 in-exception 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.
ANSI C++ offers a generic solution in the form of the bool uncaught_exception()
function.The function returns true 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 false,
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.This problem
has been fixed in OTL 3.2.13.
-
45. A compilation problem when a const
otl_value
varaiable is defined and otl_value::is_null() is being referenced The const
keyword was typed in the function declaration not after the function prototype
but after the function body:
is_null(...) {...} const.This
problem has been fixed in OTL 3.2.13.
-
44. A fix of problem 37
introduced another bug (or feature if you will). The fix contains a new
mechanism of counting (throw_count 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 throw_count 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. This problem has been fixed in OTL
3.2.12.
-
43. 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. This problem has
been fixed in OTL 3.2.11.
-
42. 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 namespace std
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.This
problem has been fixed in OTL 3.2.10.
-
41. A compilation problem with static inline
functions in the OTL header file and Visual Age C++ 5 in AIX.This
problem has been fixed in OTL 3.2.9.
-
40. 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.This
problem has been fixed in OTL 3.2.9.
-
39. A compilation problem with OTL/DB2-CLI
and xlC in AIX: OTL for DB2-CLI does not compile with xlC (C++ compiler
in AIX).This problem has NOT been fixed YET.
-
38. 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.This
problem has been fixed in OTL 3.2.8.
-
37. 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. This problem has been fixed in OTL
3.2.8.
-
36. 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. This problem
has been fixed in OTL 3.2.8.
-
35. 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. This
problem has been fixed in OTL 3.2.6.
-
34. 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. This problem has
been fixed in OTL 3.2.6.
-
33. A problem was reported in OTL/ODBC that
in some cases an otl_exception gets thrown when SQLExecute() is executed
inside the OTL. This problem has been fixed in
OTL 3.1.19.
-
32. 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. This problem
has been fixed in OTL 3.1.17. Also, it is worth mentioning that
OTL 3.1.17 now compiles with xlC (AIX).
-
31. 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. This
problem has been fixed in OTL 3.1.15.
-
30. 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.
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.
These problems have been fixed in OTL 3.1.14.
-
29. 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. This problem has
been fixed in OTL 3.1.13.
.
-
28. In OTL/OCI8, there was a compilation warning about an unused
variable in a function. This problem has been
fixed in OTL 3.1.12.
-
27. 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. This problem has been fixed
in OTL 3.1.10.
-
26. A copy constructor was added to the otl_datetime
class to make it work with the STL data container template classes. This
problem has been fixed in OTL 3.1.8.
-
25. In OTL/OCI8, if it is compiled with OCI8.1.5
in Sun Solaris, otl_stream::describe_select()
causes the program to crash. This problem has
been fixed in OTL 3.1.7.
-
24. This time around, it's an enhancement: a capability to override
the default mapping in SELECT statements. This
problem has been fixed in OTL 3.1.3.
-
23. In OTL/OCI8, otl_stream::describe_select()
returns a random value in the scale field of the otl_column_desc structure.
This
problem has been fixed in OTL 3.1.2.
-
22. 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" This problem has been fixed
in OTL 3.1.1.
-
21. This time, it's not a problem, just a small functionality fix:
otl_connect::rlogon()
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. This
problem has been fixed in OTL 3.0.32.
-
20. 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.
This
problem has been fixed in OTL 3.0.31.
-
19. Sorry folks, I forgot to add a default constructor to the
otl_datetime
class in problem 17. From now on, when an otl_datetime
variable is declared, it is initialized as "01/01/1900 0:0:0". This
problem has been fixed in OTL 3.0.28.
-
18. 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 long is 64-bit and int is
32-bit.. This problem has been fixed in OTL 3.0.27
-
17. This time, it is not really a problem,
just a new piece of functionality: class otl_datetime.
This
problem has been fixed in OTL 3.0.26.
-
16. A "return *this;" statement was missing from one
of the overloaded assignment operators (operator=()).
This
problem has been fixed in OTL 3.0.25.
-
15. One of the functions that is used in formatting otl_exception
messages was not thread safe. This problem has
been fixed in OTL 3.0.24
-
14. 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. This
problem has been fixed in OTL 3.0.23.
-
13. 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 access viloation
/ segmentation violation runtime error and, as a result, the program
will crash. Two new otl_exception's
(codes: 32007, 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. This problem has been fixed
in OTL 3.0.22. You are welcome to give
this new functionality a try and any feedback would be appreciated very
much.
-
12. 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. This
problem has been partly fixed in OTL 3.0.20. and completely fixed in OTL
3.0.21.
-
11. 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 the problem 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, OTL 3.0.19 uses
ODBC 3.x function calls and requires the underlying ODBC drivers to be
ODBC 3.x compatible. 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.
-
10. OTL 3.1/ODBC in some cases throws
an otl_exception when it's actually an ODBC warning. This
problem has been fixed in OTL 3.0.18. 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
-
9. 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. This problem has been
fixed in OTL 3.0.17.
-
8. 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. This problem has
been fixed in OTL 3.0.16.
-
7. 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()]. This problem has been
fixed in OTL 3.0.1
-
6. OTL 3.1/ODBC in some cases throws an otl_exception when it's
actually an ODBC warning. This problem has been
fixed in OTL 3.0.14.
-
5. OTL 3.1 does not compile with Sun Workshop C++ 5.0. This
problem has been fixed in OTL 3.0.13
-
4. 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 const char* 's
were converted to #define's to prevent the compilers from generating
named objects. This problem has been fixed in
OTL 3.0.12.
-
3. 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. This
problem has been fixed in OTL 3.0.11. Check out the release
number in your OTL header file, if you need the fix, send an email to the
author.
-
2. If otl_long_string's size
is set to a smaller size than the size set by otl_connect::set_max_long_size(),
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(). This
problem has been fixed in OTL 3.0.10. Check out the release
number in your OTL header file, if you need the fix, send an email to the
author.
-
1.. Examples 13
and 17 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.