• 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.

 

 
 
 
 
 
 
 
 
 
 
 

If anybody experienced the same problem, please, let me know via email.
 

• 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: 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. 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.

 

 
 
 
 
 
 
 
 
 
 
 
 
 

Copyright © 1996-2024, Sergei Kuchin, email: skuchin@gmail.com, skuchin@gmail.com .

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. THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.