|
Feature
|
Comment
|
29-Nov-2009. New (in OTL
4.0.205 updated):
- NEW GNU C++ COMPILER VERSION. G++ 4.4.2 was released
back in mid-October. OTL 4.0.205 was verified to compile clean and
tested with G++ 4.4.2.
26-Nov-2009: New (in OTL
4.0.205):
- A problem was reported that in OTL/OCI10-11, otl_subscriber class doesn't report
simultaneous UPDATE / INSERT / DELETE events that are happening to the
same row. The problem is fixed in this release.
Happy Thanksgiving to everybody in US!
|
|
22-Oct-2009. New (in
OTL.4.204):
- A problem was reported in OTL/OCI8-11 (under #define
OTL_ORA8-11). The problem is that otl_connect
leaks memory when used in a series of unsuccessful rlogon() calls
(database connection requests are unsuccessful because, say, TNS name
couldn't be resolved, or the database account credentials are invalid).
The problem is fixed in this release.
|
|
1-Oct-2009. New (in
OTL4.0.203):
- DB2 UDB 9.7 was released this past summer. This release
has been successfully compiled and tested with DB2 9.7. DB2 9.7
introduced new data type: timestamp(N), where N in [0..12]. OTL only
supports precision up to 9 digits (nanoseconds). So, otl_datetime::frac_pecision
can
be
set
as high as 9. I'll implement DB2 9.7 timestamp's precision
in [10..12] range at some point in the future when somebody requests
the feature.
29-Sep-2009. New (in
OTL4.0.203):
|
|
20-Sep-2009. New (in
OTL4.0.202):
- Oracle 11g Release 2 (11.2) was released recently. This
release of OTL introduces support for Oracle 11.2 via #define OTL_ORA11G_R2. Also, OTL
4.0.202 supports signed 64-bit integers natively for both 32-bit and
64-bit platforms (via OCI 11.2's new feature for signed 64-bit ints)
when OTL_ORA11G_R2 is defined. So, there is no need to use
string-to-64-bit-int / 64-bit-int-to-string emulation (#define OTL_BIGINT_TO_STR, OTL_STR_TO_BIGINT) for
Oracle 11.2. For more detail, see two new code examples for Oracle 11.2:
- native support for signed 64-bit ints for Oracle
11.2
- direct path data loading via optimizer hint
/*+APPEND_VALUES*/ for Oracle 11.2
- TimesTen 11.2 was released recently at the same time as
Oracle 11.2 (Oracle Corporation actually acquired TimesTen back in 2005). OTL 4.0.202
was tested successfully with TimesTen 11.2
|
|
5-Sep-2009. New (in OTL
4.0.201):
- I was asked to provide a few code examples for the new
features introduced in OTL 4.0.200:
- Oracle OCI7 (classic OCI), examples 690, 691
- Oracle OCI8 and higher, examples 692, 693
- MS SQL Server 2008 SNAC, examples 696, 697
- For other supported database types, examples can be
derived from example 690-697.
- OTL Web Site Stats Report was added to the "Users' Comments / OTL Web Stats" page.
- A problem was reported that
operator<<(ostream&,const otl_value<otl_datetime>&)
can't be overloaded because the OTL header file already defines such an
operator. New #define OTL_DISABLE_OPERATOR_GT_GT_FOR_OTL_VALUE_OTL_DATETIME
is introduced in this release to disable
operator<<(ostream&,const otl_value<otl_datetime>&)
in the OTL header file.
- Documentation bug was reported in otl_subscriber::OnException() function. OTL
4.0.200 code cleanup changed the
function signature (OTL_CONST_EXCEPTION was added to the function's
parameter), but the change was not reflected in the manual. The
documentation bug is fixed in this release.
|
|
30-Aug-2009. New (in OTL
4.0.200):
Gerrit Hobbelt from Netherlands contributed a few ideas, bug reports,
bug
fixes, and some code for new functionality. I adapted most of them and
had to rework the rest for
this new release of OTL. I also fixed a couple of unrelated bugs:
- BUG: When a fractional part ("fraction") of
otl_datetime has more decimal significant digits than MS SQL Server
2005/2008 can handle, say, the fractional part is .1234 for a datetime
table column, or .12345678 for a datetime2 table column, MS SQL Server
returns an error. It is actually a known feature of MS SQL Server. MSDN
Web site describes a workaround, but it isn't clear whether it would
work with the rest of the database types, supported by OTL. This
release of OTL uses the otl_datetime.frac_precision to truncate the
decimal significant digits beyond the specified precision. Such
databases as Oracle, or DB2 don't return an error when the second
fractional part is larger than the corresponding timestamps data types
can handle. However, the timestamp values don't get rounded up or
truncated correctly by the databases. So, it's recommended that the
timestamp values should be within the specified precision. OTL will
truncate the redundant decimal significant digits, which is more
correct than it was before.
- BUG: In two OTL
tracing statements, calls to otl_stream::describe_next_out_var(),
otl_stream::describe_next_in_var() may return 0 pointers, which may
results in the program crash. In this release, the checks for 0
pointers were added to the OTL tracing statements in order to prevent
the program crash.
- BUG: When #define OTL_ODBC is used, an otl_connect
object doesn't recover well after an unsuccessful call to
SQLAllocHandle(). The otl_connect object could be destroyed and
recreated again as a workaround, but it's not desirable. The bug is
fixed in this release.
- BUG: A problem was reported that when Oracle RAW
columns are used with :v<raw[XXX]> bind variables, and when a RAW
NULL value is written into the stream, then sometimes all the
subsequent RAW
values get written as NULLs. The bug is fixed in this release.
- BUG: A problem was reported that when
:v<varchar_long> is used in the WHERE clause of a SELECT
statement with PostgreSQL, it doesn't work. The problem was that very
few database types allow <varchar_long> to be used in a WHERE
clause, and OTL didn't implement it properly. The bug is fixed in this
release.
- TYPOS: Two typos were fixed in "operator
>>" in OTL tracing statements. "operator >>"'s were changed
to "operator <<" to show the right operator names. Anybody who
has "OTL tracing based log parser" scripts may want to run tests to
check to see whether the scripts still work correctly.
- CODE CLEANUP: A few
references to otl_exception&
within the OTL header file were changed to OTL_CONST_EXCEPTION
otl_exception&. #define OTL_CONST_EXCEPTION is defined as const under #define OTL_ANSI_CPP,
otherwise it is empty.
- NEW FUNCTIONALITY: OTL used the US date format in OTL tracing statements. This
release introduces the following two new #defines that parameterize the
data format in OTL trace statements: OTL_TRACE_FORMAT_DATETIME,
OTL_TRACE_FORMAT_TZ_DATETIME.
- NEW FUNCTIONALITY: This release introduces two new
functions:
- NEW COMPILER VERSION: This release compiles clean with
GNU C++ 4.4.1, which
was released a month ago.
- OTL LICENSE: The OTL license hasn't changed since 1996.
It was a one clause Free Software license. I heard a fair amount of
criticism about the OTL license being a "non-license", etc. This
release (and subsequent releases) will use the official, two-clause
text of Open BSD license:
// ORACLE, ODBC and
DB2/CLI Template Library, Version 4.0.200,
// Copyright (C)
1996-2009, Sergei Kuchin (skuchin@gmail.com)
//
// This library is
free software. Permission to use, copy, modify,
// and/or
distribute this software for any purpose with or without fee
// is hereby
granted, provided that the above copyright notice and
// this permission
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.
//
// a.k.a. as Open
BSD
license
See the OTL header file (otlv4.h) for more
detail .
The first clause states the same thing as the OTL old license. The
second clause states that "The Software" is provided "AS IS". If
anybody has any concerns about this change in the text of OTL license,
please, let me know.
|
|
15-Aug-2009. New (in OTL
4.0.199):
- Copy constructor and assignment operator were reported
to be missing from otl_long_unicode_string
class. The bug is fixed in this release.
- A link to OTL code example 454 (for PostgreSQL) was
reported to be broken. The link is fixed in this release.
|
|
02-Aug-2009. New (in OTL
4.0.198, updated):
- OTL 4.0.198 has been successfully tested with the
32-bit PostgreSQL 8.3.7 and the 32-bit pgODBC 8.03.04 driver in
Windows. 64-bit pgODBC was reported to have problems when the bulk
interface was used (otl_stream buffer size >1). I encourage
everybody to report problems like that to the development team of the
PostgreSQL ODBC drivers.
08-Jul-2009. New (in OTL
4.0.198, updated):
- OTL 4.0.198 has been successfully compiled and tested
with GNU C++ 4.4.0, which was released a couple of months ago. OTL
compiles clean with GNU C++ 4.4.0.
18-Jun-2009. New (in OTL
4.0.198):
- A problem was reported that MS SQL Server's BACKUP
command fails when executed via otl_connect::direct_exec(). The problem is the BACKUP
command returns from direct_exec() right away, and the output from the
BACKUP commands is supposed to be retrieved by calls to SQLGetDiagRec()
in a loop. MS SQL Server has a separate category of such commands:
BACKUP, DBCC, etc. direct_exec() deallocates the underlying SQL
statement resource right after it gets control back, which is the
problem. In order to work around the problem, the otl_stream class has
been extended to process MS SQL Server commands such as BACKUP, DBCC,
etc. The following new #define and otl_stream function are introduced
in this release:
Also, see examples 688, 689.
|
|
6-Jun-2009. New (in OTL
4.0.197):
- A problem was reported that when OTL defined "Incompatible data types in stream
operation" exception is thrown from an INSERT statement based
otl_stream, no good rows get inserted into the table. This behavior is
inconsistent with, say, when a "primary key violation" exception is
thrown. The difference between the primary key violation and the
incompatible
data types in stream operation exception is that the latter is
contained to the OTL code itself. The following new function is
introduced in this release for efficient otl_stream recovery: reset_to_last_valid_row().
|
|
3-Jun-2009. New (in OTL
4.0.196):
- A bug was reported that under #define OTL_ODBC_MULTI_MODE,
when the following code runs against a MySQL database, otl_null()
doesn't get written into the F2 table column correctly:
...
otl_long_string
f2(6000);
otl_stream o;
o.set_lob_stream_mode(true);
o.open(1,
"insert into test_tab (F1,F2,F3) values"
"(:f1<int>,:f2<double>,:f3<varchar_long>) ",
db
);
o.set_commit(0);
int i,j;
otl_lob_stream lob;
for(i=0;i<=7;++i){
o<<i;
if(i==0||i==2||i==4||i==6)
o<<i+12.56;
else
o<<otl_null(); // doesn't work correctly
o<<lob;
for(j=0;j<50;++j)
f2[j]='*';
f2[50]='?';
f2.set_len(51);
lob.set_len(51+23);
lob<<f2;
f2[22]='?';
f2.set_len(23);
lob<<f2;
lob.close();
}
db.commit();
...
It's not known at this time whether it's a bug or a
feature of MyODBC driver. The
same code works correctly at least with DB2 and MS SQL Server ODBC
drivers. The otl_stream's internal buffers reinitialization algorithm
was changed in this release to work around this "feature" of MyODBC.
The change is not specific to MyODBC.
|
|
25-May-2009. New (in OTL
4.0.195):
- A bug was reported that under some circumstances when
OTL/ODBC is used with PostgreSQL, and when #define OTL_ODBC_ALTERNATE_RPC
is defined, OTL throws the "function sequence error" when a SELECT
statement is instantiated in an otl_stream. The bug seems to be
different from the bug that was fixed in OTL 4.0.194. The new bug is
fixed
in this release.
|
|
20-May-2009. New (in OTL
4.0.194):
- A bug was reported that under some circumstances when
OTL/ODBC is used with PostgreSQL, and when #define OTL_ODBC_ALTERNATE_RPC
is defined, OTL throws the "function sequence error" exception when a
SELECT statement is instantiated in an otl_stream. This bug is fixed in
this release.
- #define OTL_ODBC_ALTERNATE_RPC has been added to the
PostgreSQL code examples to
reflect the latest recommendations for PostgreSQL and OTL.
|
|
New (in OTL 4.0.193):
- A bug was reported that the following function was
missing:
class
otl_stream_read_iterator{
...
void
get(const
char*
var_name, double& n);
...
The bug is fixed in this
release.
|
|
New (in OTL 4.0.192):
|
|
New (in OTL 4.0.191):
- A problem was reported that OTL 4.0.190's new RPC
mechanism broke some OTL/ODBC based C++ code. This release reinstates
the old RPC, SQLRowCount() mechanism, and adds the following new
#define to accommodate the PostgreSQL ODBC driver quirks: OTL_ODBC_ALTERNATE_RPC.
Those
who
need
precise RPC counts for PostgreSQL may want to enable
the new #define.
|
|
New (in OTL 4.0.190):
- A problem was reported that PostgreSQL ODBC
driver on a bulk INSERT statement returns one row count per inserted
row instead of one row count with the total of "rows processed". It
doesn't contradict the ODBC specification, though. However, OTL relies
on just one row count, which is not what the PostgreSQL ODBC driver
returns. OTL 4.0.188 already worked
around this problem, but otl_stream::get_rpc() still returns 1 instead
of the actual number of affected rows. This release changes the "get
rpc" scheme a little bit, at least for ODBCVER >= 3.0 in order to
get the right RPC count from the PostgreSQL ODBC driver. This new
scheme (ODBC attribute SQL_ATTR_PARAMS_PROCESSED_PTR for SQL
statements)
works fine with the rest OTL supported database types.
|
|
New (in OTL 4.0.189):
- The following buffer overrun was reported in OTL/ORA7:
int
describe_column
(otl_column_desc&
col,
const int
column_num,
int&
eof_desc)
{
sb1
name[241];
nlen=sizeof(name);
int
temp_rc=odescr
(&cda,
column_num,
&dbsize,
&dbtype,
&name[0],
&nlen,
&dsize,
&prec,
&scale,
&nullok);
if(temp_rc==0)name[nlen]=0;
...
It happens very rarely, and it's not clear why it happens at all, when
the odescr() function returns success (0), and at the same time it
doesn't modify the output nlen parameter. The bug is fixed in this
release.
|
|
New (in OTL 4.0.188):
- A problem was reported
when OTL is used with the
PostgreSQL ODBC driver and an INSERT statement in the bulk interface
mode (otl_stream buffer size >1), more rows than expected could be
inserted into the table in some cases. OTL relies on the underlying
ODBC driver to return a correct "rows processed count" (RPC) when
SQLRowCount() is called right after the INSERT statement gets executed.
PostgreSQL ODBC driver always returns 1, which makes OTL believe that
the RPC from INSERT was 1, and OTL doesn't have to set the
SQL_ATTR_PARAMSET_SIZE attribute of the INSERT statement. This release
of OTL works around the RPC feature of the PostgreSQL ODBC driver, and
inserts the correct number of rows into the table.
- This release introduces basic support for
SQLGetTypeInfo() (data dictionary
ODBC/DB2 CLI function) . The function returns a list of data
types supported by the database server. How to call ODBC data
dictionary functions, see the corresponding OTL code examples.
- MySQL OTL code examples
have been reworked to show a technique of doing a multi-row INSERT by
using the multi-row VALUES clause in an INSERT statement when the
otl_stream buffer size is set to 1. This technique is a workaround of
the lack of the bulk interface support in MySQL.
|
|
New (in OTL 4.0.187):
- A problem was reported in Oracle 10g, when #define OTL_ORA_TIMESTAMP is
defined, that it takes 10 times longer than usual to retrieve Oracle
TIMESTAMP values. The Oracle 10g JDBC driver seems to have the same
problem. #define OTL_ORA7_STRING_TO_TIMESTAMP/OTL_ORA7_TIMESTAMP_TO_STRING
can
be
used
as a workaround for the problem. See example 473
for more detail. The same technique can
be used under #define OTL_UNICODE.
|
|
New (in OTL 4.0.186):
- A bug was reported that when in OTL/ODBC when the
following flavor of otl_connect::rlogon() is used, the
auto-commit parameter has no effect if it's set to 0. The bug is fixed
in this release.
|
|
New (in OTL 4.0.185):
- This release introduces the following new #define: OTL_ORA_MAP_BIGINT_TO_LONG.
It
enables
mapping
from <bigint>
to
singed
64-bit longs for 64-bit OCIs on LP64 platforms.
- OTL_ODBC_TIME_ZONE,
OTL_ODBC_STRING_TO_TIMESTAMP,
OTL_ODBC_TIMESTAMP_TO_STRING
were introduced a few releases ago as a way to work with TIMESTAMP WITH
TIME ZONE (PostgreSQL, Oracle) / timestampoffset (MS SQL Server 2008)
via ODBC. A bug was reported that when #define OTL_UNICODE is enabled,
and the #define's above are enabled as well, the code doesn't return
the right results. The bug is fixed in this release. See also examples 685, and 686.
- A bug was reported that when an empty, numeric, PL/SQL,
STL-vector based container is being
passed into a stored procedure call, it causes the program to crash.
The bug is fixed in this release.
|
|
New (in OTL 4.0.184):
- The OTL online manual is reformatted in
order to make it more readable (function lists have been put in HTML
tables). Comments and suggestions to improve the manual are welcome.
- otl_stream::get_dirty_buf_len()
is
extended
to
work with SELECT statements, Oracle PL/SQL reference
cursors, and stored procedures that return implicit result sets: it
returns the number of rows in the stream buffer that are yet to be read.
- A bug was reported that otl_refcur_stream::rewind()
causes the Oracle "fetch out of sequence" error. The reporter of the
bug pointed out that to "rewind the reference cursor" means to
re-execute the master PL/SQL block the reference cursor belongs to.
otl_refcur_stream::rewind()
can't be easily eliminated because it is derived from otl_read_stream_interface,
when
#define
OTL_ORA_DECLARE_COMMON_READ_STREAM_INTERFACE
is enabled. Instead, otl_refcur_stream::rewind() was made private in
this release.
- A bug was reported
that the new "CHECK-END-OF-ROW" feature, which was
introduced in OTL 4.0.181, is no longer
available. The bug is fixed in this release.
- A bug was reported
that the explicit
:#N<raw[XXX]> override
for SELECT statements maps to <raw_long>, and that the bulk
interface (stream buffer size >1) for Oracle doesn't work as a
result. The bug is fixed in this release.
|
|
New (in OTL 4.0.183):
- The following Visaul C++ 8 compilation warning was
reported for OTL 4.0.182, line 13840 under #define OTL_FUNC_THROW_SPEC_ON,
and
#define
OTL_ODBC:
C4297: 'function' :
function assumed not to throw an exception but does
The warning is fixed in this release.
|
|
New (in OTL 4.0.182):
- This release extends the functionality of the
otl_stream::create_stored_proc_call()
function:
it
can
handle stored procedures / functions that have more
than one output reference cursor parameters and also input / output
parameters in addition to the reference cursor parameters. The
following new global constant was added to indicate the new type ot
stored procedures: otl_mixed_refcur_stream_type.
See also example 153
for more detail.
|
|
|
New
(in
OTL
4.0.181):
-
A
bug was reported that in a WHERE clause in a SELECT statement,
:v<raw[XXX]> doesn't
work under #defines OTL_ORAXXX, and the
following OTL defined otl_exception gets raised:
Not all
input variables have been initialized
The problem is fixed in this release.
- This
release introduces otl_stream::check_end_of_row()
function (or its operator>>() form) and the "END-OF-ROW check failed"
otl_exception, in order to address the "row tearing"
problem. The problem is that, say, a SELECT statement has
two int columns, and the loop to read rows from the SELECT statement
actually reads three int values at a time, for example:
otl_stream
sql(10,"select a, b from some_table",db); // only TWO columns
while(!sql.eof()){
int a, b, c;
sql>>a>>b>>c; // this causes "row-tearing"
// ...
}
The way OTL uses the C++ stream idiom is said to
be unsafe, and
that it potentially could cause a "row-tearing" problem, which could be
very hard to troubleshoot and maintain. The check_end_of_row() function
addresses the problem, so, in order to make sure the code is safe and
maintainable, here's how the example above can be rewritten:
otl_stream
sql(10,"select a, b from some_table",db); // only TWO columns
while (!sql.eof()){
int a, b;
sql>>a>>b;
sql.check_end_of_row();
// ...
}
or this way
otl_stream
sql(10,"select a, b from some_table",db); // only TWO columns
while (!sql.eof()){
int a, b;
sql>>a>>b>>endr;
//
...
}
In case if the number of columns in the SELECT
statement
changes, and the actual loop is not changed, the check_end_of_row()
function (or its alternative operator>>() form) will throw this
exception.
I personally don't believe that the OTL design is too bad to cause
"row-tearing" that is hard to troubleshoot. Usually, a SELECT
statement has columns of more than one data type, so when the "row is
torn", OTL will throw the usual "incompatible
data
types
in
stream operation" exception, and it will be obvious
that the code is wrong.
Those developers, who think that the "row tearing" is a serious problem
and don't want to use the check_end_of_row() function, can use the OTL stream read iterator,
which provides JDBC-like getter
interface.
otl_stream::check_end_of_row() function is not mandatory, so OTL will
continue to work as before.
|
|
|
New (in OTL 4.0.180):
|
|
|
New (in OTL 4.0.179):
-
A documentation bug was reported that :v<long> (bind variable) is
not always a signed 32-bit integer on 64-bit platforms. The
documentation has been corrected in this release to provide a more
detailed explanation on the topic.
-
OTL 4.0.176 was refactored to make undocumented class
public data members in OTL private or protected. A compilation problem
was reported around the area of those previously public data members.
The following method has been added to the otl_stream class (for all
flavors of OTL) in order to address the compilation issue:
int get_connected() const {return connected;}
-
Several projects asked for the following code to be
included into the OTL header file:
#if defined(OTL_INCLUDE_0)
#include "otl_include_0.h"
#endif
The rationale for it is that these projects need to include their own
credentials to the OTL header file, so that, when the corresponding
binary file gets generated, the credentials will be present in the
binary as a string. Therefore, the exact version/build number of the
binary can be easily identified.
|
|
|
New (in OTL 4.0.178):
-
The following deficiency was reported in the OTL
tracing:
...
(0) MY OTL TRACE ==> otl_stream(this=0012FEFC)::open
(buffer_size=5, sqlstm=select * from test_tab where f1>=:f<int>
and f1<=:ff<int>*2, connect=004332CC);
(1) MY OTL TRACE ==> otl_stream(this=0012FEFC)::operator <<
(char*: ftype=1, placeholder=:f2, value="Name10");
(2) MY OTL TRACE ==> otl_stream, executing SQL Stm=insert into
test_tab values(:f1 ,:f2 ), current batch size=10, row offset=0
...
(3) MY OTL TRACE ==> otl_stream, executing SQL Stm=
select * from test_tab where f1>=:f and f1<=:ff *2, buffer size=5
(4) MY OTL TRACE ==> otl_stream, fetched the first batch
of rows, SQL Stm=select * from test_tab where f1>=:f and f1<=:ff *2, RPC=5
...
(2), (3), and (4) don't have the stream address,
which makes it difficult to keep track of different instances of OTL
streams that have the same SQL statement, and especially when the
streams are used in different threads. The deficiency is fixed in this
release. The OTL trace for the example above is going to look like this:
...
(0) MY OTL TRACE ==> otl_stream(this=0012FEFC)::open
(buffer_size=5, sqlstm=select * from test_tab
where f1>=:f<int> and f1<=:ff<int>*2, connect=004332CC);
(1) MY OTL TRACE ==> otl_stream(this=0012FEFC)::operator <<
(char*: ftype=1, placeholder=:f2, value="Name10");
(2) MY OTL TRACE ==> otl_stream(this=0012FEFC), executing SQL Stm=
insert into test_tab values(:f1 ,:f2 ),
current batch size=10, row offset=0
...
(3) MY OTL TRACE ==> otl_stream(this=0012FECC), executing SQL Stm=
select * from test_tab where f1>=:f and f1<=:ff *2, buffer size=5
(4) MY OTL TRACE ==> otl_stream(this=0012FECC), fetched the first batch of rows,
SQL Stm=select * from test_tab where f1>=:f and f1<=:ff *2, RPC=5
...
-
A bug was reported that some OTL trace statements are
missing for #define OTL_ORAXXX when reference cursors are used. The bug
is fixed in this release
|
|
|
New (in OTL 4.0.177):
-
In order to address an issue, the following new question & answer has
been added to the OTL F.A.Q.: How to insert or
update MS SQL NVARCHAR / NCHAR values larger than 2000
(UTF-16) characters?
-
The previous release (OTL 4.0.176) was refactored to
make undocumented class public data members in OTL private or
protected. A compilation problem was reported around the area of those
previously public data members. The following two methods have
been added to class otl_conn (under #define OTL_ORAXX, where XX>=8)
in order to address the compilation issue:
OCIServer* get_srvhp(){return srvhp;}
OCISession* get_authp(){return authp;}
-
A problem was reported that when #define OTL_ORA10G is
used, an otl_stream stream has :v<refcur,...>, and the stream's
buffer size is > 1, the program crashes somewhere deep in the OCI
layer. The stream's buffer size should be set to 1 when the stream has
:v<refcur>. OTL is supposed to throw the otl_exception with error
code of 32034, but it
doesn't The problem is fixed in this release.
|
|
|
New (in OTL 4.0.176):
-
OTL code has been refactored: public data members that
weren't part of the documented public interfaces have been made
private, or protected. This may break some OTL based code, if the code
uses undocumented public data members in the OTL classes, that have
been made private/protected in this release of OTL. Let me know right
away if this happens, and I'll add appropriate accessor functions to
the corresponding OTL classes. The reason for the refactoring of the
OTL header file is that developers in many projects (I've heard from
many enough) are adopting stricter standards for third-party libraries
as well as their own code.
|
|
|
New (in OTL 4.0.175):
-
A bug was reported that otl_stream::create_stored_proc_call()
couldn't
find
a
procedure / function name if the procedure / function
is available via Oracle synonym mechanism. The bug is fixed in this
release: otl_stream::create_stored_proc_call()
searches Oracle's data dictionary's user_synonyms and all_synonyms
views in case if the procedure / function name is not found anywhere
else.
-
A bug was reported that the otl_connect object can't
fully recover from a database failure when OTL/ODBC is used with the
Oracle ODBC driver for Oracle. OTL/ODBC doesn't deallocate the connect
related underlying ODBC handles on otl_connect::logoff(). The assumption was
that the ODBC driver's connection handles can be reused on the next
otl_connect::rlogon().
Obviously, there are situations when the assumption is not true. The
following new #define forces the otl_connect::logoff() to free ODBC
connection related handles: OTL_ODBC_LOGOFF_FREES_HANDLES.
-
A bug was reported that otl_refcur_stream doesn't support
the RAW type. The bug is fixed in this release.
-
A bug was reported that sometimes otl_subscriber class doesn't report
table-wide events because the corresponding event bitmask contains the
event bit + OCI_OPCODE_ALLROWS. The bug has been fixed in this release,
and otl_subscriber's OnTableAlter(), OnTableDrop(), OnTableChange()'s
signatures have been changed.
-
A problem was reported that Oracle CLOB-to-XMLType and
XMLType-to_CLOB conversion didn't work for XMLType values larger than
4000 bytes. Example 678 has been added to
show how to work around the problem.
-
MS SQL 2005 introduced Multiple Active Result Sets
(MARS), which is not enabled by default. More and more applications
require this feature to be enabled. This release of OTL introduces the
following #define to enable the feature: OTL_ENABLE_MSSQL_MARS.
-
This release introduces support for MS SQL 2008 (new
#define OTL_ODBC_MSSQL_2008,
new
OTL_MSSQL_2008_ODBC_CONNECT
mode under #define OTL_ODBC_MULTI_MODE).
For
more
detail,
see also examples 679, 680, 681, 682, 683, 684.
-
This release of OTL compiles clean with the latest
g++: 4.3.2 (which has been released recently).
|
|
|
New (in OTL 4.0.174):
-
OTL 4.0.173 fixed the LOB-stream-mode-NULL bug for OTL/DB2-CLI, but it introduced the
same bug in OTL/OCI. The bug is fixed in this release.
-
ODBC doesn't support timestamps with time zone
components yet. However, there is a need to work with "TIMESTAMP WITH
TIME ZONE" columns via ODBC. For example, PostgreSQL supports TIMESTAMP
WITH TIME ZONE. This version of OTL intrdoces the following new #define
to address the need: OTL_ODBC_TIME_ZONE,
OTL_ODBC_STRING_TO_TIMESTAMP,
OTL_ODBC_TIMESTAMP_TO_STRING.
See
example
676 for more detail.
A problem was reported that some versions of the PostgreSQL ODBC driver
don't populate the timestamp's fractional part. The new #defines can be
used as a workaround to solve the problem. See example 676 for more detail.
-
A problem was reported that xlC version 6 doesn't
support template member functions. The bug is fixed in this release
(for xlC, #define OTL_NO_TMPL_MEMBER_FUNC_SUPPORT
gets enabled by default).
|
|
|
New (in OTL 4.0.173):
-
The following compilation errors were reported when
OTL is being compiled under Debian on AMD64, #define OTL_ODBC_UNIX, and #define OTL_ODBC_MULTI_MODE:
In file included from test.cpp:12:
./otlv4.h: In member function 'int odbc::otl_sel::first(odbc::otl_cur&,
int&, int&, int&, int&, int)':
./otlv4.h:12497: error: cannot convert 'SQLULEN*' to 'SQLROWSETSIZE*'
for argument '4' to 'SQLRETURN SQLExtendedFetch(void*, SQLUSMALLINT,
SQLROWOFFSET, SQLROWSETSIZE*, SQLUSMALLINT*)'
./otlv4.h: In member function 'int odbc::otl_sel::next(odbc::otl_cur&,
int&, int&, int&, int&, int)':
./otlv4.h:12599: error: cannot convert 'SQLULEN*' to 'SQLROWSETSIZE*'
for argument '4' to 'SQLRETURN SQLExtendedFetch(void*, SQLUSMALLINT,
SQLROWOFFSET, SQLROWSETSIZE*, SQLUSMALLINT*)'
The problem was due incompatible imlementations of
ODBC in the 64-bit Windows, and in the 64-bit Unix ODBC package. If you
read the comments in the SQL/ODBC related header files in unixodbc,
you'd see that the implementors struggled with interpreting ambiguities
in the 64-bit ODBC specification. Nobody says that life is perfect, and
there is nothing a few #ifdefs can't fix. The problem is fixed in this
release.
-
A bug was reported that
when OTL is used with OTL_DB2_CLI.,
and
an
otl_stream is opened
in the
LOB stream mode (otl_stream::set_lob_stream_mode(true)),
NULL
values,
say,
in an INSERT statement, don't get processed
correctly. Instead of inserting a NULL, OTL inserts a non-NULL value
from a row prior to the one with the NULL. The bug is specific to
OTL/DB2-CLI. OTL introduced a tweak a couple of years ago that resets
the "NULL indicator" / "length" fields for each bind variable / array
to the default "non-NULL" right after SQLExcute() is called.
Apparently, DB2 CLI has some semi-documented behavior (maybe it's
documented, only I couldn't find the right reference, so if somebody
could point me to the right spot in the DB2 CLI manual, that would be
helpful) that the "NULL indicator" / "length" field is still used by
the DB2 CLI layer after SQLExecute() was already called under certain
conditions. The bug is fixed in this release.
-
This release introduces the following #define: OTL_EXCEPTION_IS_DERIVED_FROM_STD_EXCEPTION.
The
#define
is
a shortcut for "otl_exception
is derived std::excetion".
-
A few redundant calls to otl_null() were removed
inside the OTL header file.
|
|
|
New (in OTL 4.0.172):
-
When #define OTL_FREETDS_ODBC_WORKAROUNDS
is enabled, and, say, an INSERT statement is being executed against a
table, even after otl_connect::commit() is called, the table still has
an exlusive lock on the rows that were inserted into the table. The bug
is fixed in this release. It looks like the bug in FreeTDS, which
#define OTL_FREETDS_ODBC_WORKAROUNDS was meant to fix, is fixed now in
FreeTDS. Check the FreeTDS Web site for more detail. Those who still
use the version of FreeTDS with the original bug can continue using
#define OTL_FREETDS_ODBC_WORKAROUNDS.
-
When otl_lob_stream
is #defines OTL_ORAXX (where XX>=8), in a situation when a clob/blob
gets returned from a PL/SQL stored procedure call and there is another
output parameter that precedes the clob/blob, for example:
begin
GetClob(:f<char[30],out>,
:c<clob,out>);
end;
In case if the preceding output parameter is NULL (:f is NULL), the clob (:c)
is
empty
.
The bug is fixed in this release. If the same parameters (:f and :c) get
returned by a SELECT statement, such a bug doesn't exist.
|
|
|
New (in OTL 4.0.171):
-
#define OTL_VERSION_NUMBER in the OTL header file had
a typo, it was set to 0x0400B0L instead of 0x0400AAL. The typo is fixed
in this release.
-
The following constructor was broken:
otl_value<otl_datetime>(const otl_null&):
v(0),
ind(true)
{
}
It should be
otl_value<otl_datetime>(const otl_null&):
v(),
ind(true)
{
}
The bug is fixed in this release.
-
When #define OTL_ORA8I, or OTL_ORA9I, or OTL_ORA10G,
or OTL_ORA10G_R2, or OTL_ORA11G is defined along with #define
OTL_UNICODE, SELECT trigger_body FROM all_triggers only returns 50% of
the trigger body text (trigger_body is a LONG column) when read into an
otl_long_unicode_string variable. For an unknown reason (I was unable
to find any relevant information in the OCI manual,
metalink.oracle.com, or on the Internet), the OCI sometimes returns the
length of a Unicode LONG value in double-byte characters, and most of
the time the length is returned in bytes. Thus, the reason for OTL
returning 50% of the LONG text in SELECT trigger_body FROM
all_triggers. The OCI always adds a NULL terminator character to a LONG
string (in the case of Unicode, it's a double-byte NULL terminator). In
this release, OTL has been changed to rely on the NULL terminator
instead of the returned length for LONG values.
|
|
|
New (in OTL 4.0.170):
-
When #define OTL_UNICODE
is enabled, otl_refcur_stream
returns incorrect Unicode characaters for NVARCHAR2 values. OTL didn't
set the OCI "Charset Form" correctly for NLS string columns (NVARCHAR2
/ NCHAR). The problem is fixed in this release.
-
When #define OTL_ODBC_MULTI_MODE is
enabled, OTL doesn't compile with 64-bit Visual C++ 2008 under 64-bit
Windows. OTL had a variable declared as SQLUINTEGER (unsigned 32-bit
integer). The variable was used in a call to SQLExtendedFetch() as the RowCountPtr
parameter. The manual for 32-bit Visual C++
7.1 said that the RowCountPtr should be SQLUINTEGER*, and in
the actual function signature the parameter is SQLULEN*:
In the doc:
SQLRETURN SQLExtendedFetch(
SQLHSTMT StatementHandle,
SQLUSMALLINT FetchOrientation,
SQLINTEGER FetchOffset,
SQLUINTEGER
* RowCountPtr,
SQLUSMALLINT
* RowStatusArray);
In the header file:
SQLRETURN SQL_API
SQLExtendedFetch(
SQLHSTMT
hstmt,
SQLUSMALLINT
fFetchType,
SQLLEN
irow,
SQLULEN
*pcrow,
SQLUSMALLINT
*rgfRowStatus);
The discrepancy between the manual and the actual function signature
has been corrected in the latest MSDN article
on SQLExtendedFetch.
SQLUINTEGER and SQLULEN are not the same length in 64-bit Windows, that
is why there was a compilation error in the 64-bit mode. The problem is
fixed in this release.
-
When #define OTL_DB2_CLI
is enabled, OTL doesn't compile with DB2 CLI 7.x client's include
files: symbol SQL_XML is not defined. The problem is fixed in this
release.
-
When #define OTL_ODBC_MSSQL_2005 is
enabled, otl_stream_read_iterator
is attached to an otl_stream that
is opened in the LOB stream mode (otl_stream::set_lob_stream_mode(true)).
The
stream
was
opened with a SELECT statement that has a "TIMESTAMP"
column, and an "IMAGE" column. Visual C++ 8's runtime's assert on a
call to strcat_s() fails. The problem is fixed in this release.
-
OTL_ORA7_TIMESTAMP_TO_STRING
and OTL_ORA7_STRING_TO_TIMESTAMP were
introduced to support Oracle 9i's TMESTAMP dadatype under #define OTL_ORA7, This release introduces
support for same #defines for OTL/OCIx where x >= 9 for easier
migration of OTL legacy apps that use OTL_ORA7 to more recent OCIs
(9.x, 10.x, 11.x). In example 473,
#define OTL_ORA7 can be
replaced with OTL_ORA9I, OTL_ORA10G, OTL_ORA10G_R2, or OTL_ORA11G.
|
|
|
New (in OTL 4.0.169):
-
When #define OTL_ORA_UTF8
is enabled, OTL may truncate a string value, for example:'schwarz+weiß' gets truncated to
'schwarz+wei' on a SELECT statement. OTL allocated the size of
described VARCHAR / NVARCHAR columns in bytes, which was not sufficient
to hold multibyte UTF8 characters that were stored as single bytes in
the database. On the database side, character 'ß' is stored in one byte
in the case if the database character set is "8-bit European", and the
client / C++ side's is UTF8, it requires 2 bytes. If the database
character set is UTF8, then there is no such problem. The problem has
been fixed in this release
-
A compilation
problem was reported for an unspecified version of Informix for Linux
when #define OTL_INFORMIX_CLI
is enabled. I asked the guy (presumably someone from P.R.C.) who
reported the problem to email me his version of the Informix header
files and object libraries. He emailed me everything, I fixed the
problem, emailed him the patch, but I haven't heard from him since.
The compilation bug has been fixed in this release.
-
A problem was
reported that when example 378 (for
Oracle 8.x and higher) is rewritten to use #define OTL_UNICODE, otl_long_unicode_string, and
std::wcout, the output looks like this:
f1=1
chunk #1, f2=*?, len=4001
f1=2
chunk #1, f2=##, len=6000
chunk #2, f2=# , len=12000
chunk #3, f2=# , len=12000
chunk #4, f2=# , len=-9996
f1=3
chunk #1, f2=*?, len=4001
It's obviously incorrect. The bug reporter also sent
me a fix along with the bug report. The fix has been merged into this
release.
|
|
|
New (in OTL 4.0.168):
-
Some projects need to be able to connect to multiple
database types at the same time via ODBC. For example, to MySQL and
TimesTen, or to MS SQL 2005 and Sybase. OTL has specific #define's for
some database types (like #define OTL_ODBC_MSSQL_2005, or #define
OTL_ODBC_POSTGRESQL, etc.), which makes it impossible to connect to
multiple database types at the same time. In order to address the
issue, this release introduces #define OTL_ODBC_MULTI_MODE,
and otl_connect::set_connection_mode().
For
more
detail,
see example 675.
|
|
|
New (in OTL 4.0.167):
-
In this release or higher, #define OTL_UNCAUGHT_EXCEPTION_OWN_NAMESPACE
is obsolete. The underlying problem when OTL gets compiled with
#define OTL_STLPORT has
been fixed. It's recommended to comment out
#define.OTL_UNCAUGHT_EXCEPTION_OWN_NAMESPACE.
-
Some project still use Visual C++ 6.0. OTL 4.0.162 made #define OTL_UNCAUGHT_EXCEPTION_ON
the default. VC 6.0's std::uncaught_exception() always returns true,
meaning that it doesn't work the way the C++ standard defines. This
release stops enabling #define OTL_UNCAUGHT_EXCEPTION_ON for VC
6.0 for backward compatibility in order to allow the OTL based
projects that are stiil using VC 6.0 to continue to work.
-
This release introduces basic support for DB2 XML, MS
SQL XML, and Oracle XMLType datatypes. For more detail, see the
following code examples:
-
This release compiles clean with g++ 4.3.0 when the
following command line options are enabled:
-
This release has been reworked to compile clean with
g++'s -Weffc++. effc++ warns about violations of the following style
guidelines from Scott Meyers™ Effective C++ book:
-
Item 6: Distinguish
between prefix and postfix forms of increment and decrement operators.
-
Item 7: Never overload
operators "&&", "||", or ",".
-
Item 11: Define a copy
constructor and an assignment operator for classes with dynamically
allocated memory.
-
Item 12: Prefer
initialization to assignment in constructors.
-
Item 14: Make
destructors virtual in base classes.
-
Item 15: Have
"operator=" return a reference to *this.
-
Item 23: Don't try to return a reference when you
must return an object.
|
|
|
New (in OTL 4.0.166):
-
A bug was reported that otl_connect::rollback() has no effect
when OTL is used in a combination with FreeTDS/ODBC against MS SQL. It
turned out that the feature wasn't implemnted in FreeTDS/ODBC. In order
to work around the problem, this release introduces #define OTL_FREETDS_ODBC_WORKAROUNDS.
See
MS SQL Server /
FreeTDS
ODBC examples for more detail. The new #define is recommended for
use until a fix becomes available.
FreeTDS/ODBC seems to have a similar problem with
otl_connect::rlogon()'s auto-commit with Sybase. However, the new
#define is not recommended as a workaround for Sybase, because
otl_connect::auto_commit_off()
and
otl_connect::auto_commit_on()
functions
seem
to
work with Sybase. Until a fix becomes available,
auto_commit_on() / auto_commit_off() are recommended for use. See for Sybase SQL Server / FreeTDS
ODBC examples more detail.
Also, FreeTDS/ODBC doesn't seem to support "transaction isolation"
level, that is, otl_connect::set_transaction_isolation_level()
has
no
effect.
Until the feature is implemented in FreeTDS/ODBC, it's
recommended that explicit server side settings should be used instead.
For example, MS SQL supports an explicit (NOLOCK) option on the FROM
clause in a SELECT statement. Sybase has the "set transaction isolation
level X" command to set an explicit, session-wide transaction isolation
level. For more detail, see examples 516
(MS SQL), and 561 (Sybase).
Many thanks to James Lowden the maintainer of FreeTDS for clarifying
the issues. More issues may be uncovered as more developers begin using
OTL with FreeTDS/ODBC. I'd recommend those developers to subsribe to
the FreeTDS mailing list to keep track of the latest developments.
|
|
|
New (in OTL 4.0.165):
-
A bug was reported that OTL/OCI crashes (memory access
violation) the program when a refcur
bind variable is used, and the otl_stream buffer size is greater than
1. The stream buffer size actually has to be set to 1 in this case. In
order to diagnose cases like this one, OTL introduces the following new
otl_exception:
code=32034, otl_stream buffer
size should be 1 when refcur or plsql table is used. OTL should throw the new
exception instead of memory access violation.
-
A new default for #define OTL_UNCAUGHT_EXCEPTION_ON
was introduced in OTL
4.0.162. The #define was supposed to wortk when #define OTL_STL is
defined. This release extends #define OTL_UNCAUGHT_EXCEPTION_ON to work
without requiring OTL_STL to be defined first, and
OTL_UNCAUGHT_EXCEPTION_ON is on by default. If anybody has compilation
issues with this new arrangement, let me know, and we'd work something
out.
|
|
|
New (in OTL 4.0.164):
-
A bug was reported that when #define OTL_ORA10G_R2 is
used, and a PL/SQL table of NUMBER(14,4) from a PL/SQL package
gets bound with a :var<double,out[XX]> variable, an otl_exception
gets thrown that has the following Oracle error message:
PLS-00418: array bind type must
match PL/SQL table row type
The bug is fixed in this release. OCI10/11 has
flaky support for PL/SQL tables of BINARY_FLOAT / BINARY_DOUBLE, which
makes it impossible to implement any reliable scheme for supporting
PL/SQL tables of NUMBER and PL/SQL table of BINARY_FLOAT /BINARY_DOUBLE
without introducing special data types (for example, "binary_float" in
addition to "float", which is already binary) for PL/SQL tables
BINARY_FLOAT / BINARY_DOUBLE. Until Oracle straightens out the support
for PL/SQL tables of BINARY_FLOAT / BINARY_DOUBLE, and the appropriate
changes are made to OTL, it's recommended to use PL/SQL tables of
NUMBERs instead.
-
A bug was reported that when #define UNICODE /
_UNICODE, OTL_UNICODE, and OTL_ODBC are defined, and when a table has
an accented column name in it (for example,: assigné), function
SQLDescribeCol() returns bad information about the column, which
results in the program's crash. The second bug related to accented
column names was reported when otl_connect::direct_exec() function is
used with accented table columns. The bugs were due to the fact that a
type cast to a signed char* was used instead of unsigned char*. The
bugs are fixed in this release.
OTL doesn't have full support for UTF16 based SQL statement text.
However, SQL statements based on one-byte character sets should
be fully supported.
|
|
|
New (in OTL 4.0.163):
-
This release compiles clean with Visual C++ 9 (Visual
Studio 2008, which came out recently).
-
An OTL defined exception
has been changed in this release to the following in order to carry
more useful information:
Writing
CLOB/BLOB in stream mode: actual size is greater than specified, trying
to store X1 bytes / Unicode characters at offset X2. New length: X3
would be bigger than length of lob: X4.
The text of the exception (of the otl_exception
class) carries more information than before to simplify troubleshooting
of incorrect custom C++ code. This change was originally submitted as a
patch and merged into this release with some modifications.
-
The following minor error was reported
in OTL code example 383:
The "drop table test_tab" statement silently fails when the table does
not exist (as expected) but since db.commit() isn't called immediately
afterward the transaction is still open and left in an error status.
Any statement issued after that will fail with the following error:
"ERROR: current transaction is aborted, commands ignored until end of
transaction block"
Similar errors were present in some of the PostgreSQL examples. All the
errors have been fixed in this release.
|
|
|
New (in OTL 4.0.162):
-
This release introduces the following code examples
for Informix CLI: examples 625-658.
OTL
has
supported
Informix via Informix CLI for a few years. Informix
CLI in Windows is indistinguishable from ODBC, so in Windows #define OTL_ODBC can used with Informix
CLI. In Unix, #define OTL_INFORMIX_CLI
can be used.
-
A bug was reported that when OTL is used with TimesTen
7.0.2 or higher, it is impossible to set the TT Prefetch size to 0,
which enables the default TT Prefetch sizes (see TT manuals for more
detail). The bug is fixed is this release. See also the stream buffer size
description.
-
A compilation bug was reported that when OTL is being
compiled with g++ with -ansi commannd line option, and #define OTL_ACE. A patch
was posted in the OTL discussion forum. The patch has been merged with
this release.
-
The following formatting problem was reported when OTL
tracing is enabled:
MY OTL TRACE ==> otl_connect(this=0042A1D8)::rlogon(connect_str="/******@mssql", auto_commit=0);
The user id is missing from
the trace. The problem is fixed in this release.
-
In
order to address user complaints about aborting / terminating programs
in the case of a cascade of OTL exceptions, the following #define has
been made the default in this release: #define OTL_UNCAUGHT_EXCEPTION_ON.
From
the
beginning,
OTL, according to some C++ gurus who would hit me in the head, should not
have had "throwing destructors". See more detail on the history of the
question here.
By completely eliminating throwing desctructors, OTL would have broken
a lot of existing custom code (the code would have to be rewritten), so
the decision had been made to introduce #define
OTL_UNCAUGHT_EXCEPTION_ON.
Only really old C++ compilers like Visual C++ 6.0 don't support the
required C++ function (uncaught_exception()). If anybody experience any
problems with this new default setting, let me know, we would work
something out.
Those who do not want OTL destructors to "throw" can use #define
OTL_DESTRUCTORS_DO_NOT_THROW,
but
they
would
have to call the close() function all otl_streams
explicitly, before each stream goes out scope.
|
|
|
New (in OTL 4.0.161):
-
A bug was reported that when #define OTL_ORA10G (or OTL_ORA10G_R2, or OTL_ORA11G) is used against an
Oracle 9i database backend, the OCI10 native SQLT_BDOUBLE / SQLT_BFLOAT
bindings don't work. The bug is fixed in this release, and the fix can
be enabled with #define OTL_ORA_LEGACY_NUMERIC_TYPES.
-
A bug was reported that when #defines OTL_ORA8 / 8I/
9I / 10G / 10G_R2 / 11G are used with otl_lob_stream,
and
when
the
value of a CLOB/BLOB in a table goes from, say a size >
0 to the size of 0, the actual value doesn't get set to the size of 0.
The bug fixed in this release.
-
A bug was reported that when #define OTL_ORA8 / 8I /
9I / 10G / 10G_R2 / 11G is defined along with #define OTL_ODBC_TIMESTEN_UNIX
/ OTL_ODBC_TIMESTEN_WINDOWS,
and
the
resulting
executable is linked with both the OCI and the
TimesTen object libraries, the program's performance (the Oracle side
in particular) degrades tenfold. The bug is fixed in this release.
-
A bug was reported that when an otl_exception gets
thrown and an error is caused by an nchar or an nclob bind variable, the var_info member of the
otl_exception isn't populated correctly. In particular, the data type
is blank isntead of NCHAR, or NLOB. The bug is fixed in this release.
-
This release introduces the following new #define OTL_ODBC_ENTERPRISEDB.
The
#define
can
be used with Enterprise
DB, a commecial, Oracle compatible offshoot of PostgreSQL. Also, see examples 586-624 for more detail.
|
|
|
New (in OTL 4.0.160):
-
Oracle 11g Release 1 came out recently. OTL introduces
the following new #define to start the OTL/OCI11g series: #define OTL_ORA11G.
-
When OTL_ODBC,
OTL_BIGINT, OTL_STR_TO_BIGINT, and OTL_BIGINT_TO_STR are
defined, OTL does not compile with VC++ 2005, and xlC (C++ in AIX). The
bug is fixed in this release.
-
When OTL_DEFAULT_STRING_NULL_TO_VAL,
OTL_UNICODE
are defined together, and otl_refcur_stream
is used, the default string value that the OTL_DEFAULT_STRING_NULL_VAL
defines doesn't get returned correctly in the case if the actual value
to be returned is NULL. The bug is fixed in this release.
-
otl_stream_read_iterator::get(const
int
pos,
unsigned
char* s) was reported to have a compilation error on
an unspecified C++ compiler, on an unspecified platform. The proposed
code change was merged into this release. .
|
|
|
New (in OTL 4.0.159):
-
In OTL 4.0.158, a bug was introduced which causes the
following error message when an <int> bind variable is used:
[Microsoft][SQL Native Client][SQL Server]Invalid 2-Parameter (''): The
0x23 data typ is a LOB marked as obsolete and used as output parameter.
Obsolete types are not supported as output parameters.
The bug is fixed in this release.
-
C++Builder 2007
generates the following error when compiling OTL:
Error error 2285: E2285
Could not find a match for
'operator otl_ora8_inout_stream::operator>>(float)
There
are
similar
errors
in the rest of the numeric operators >>() of
the same class. The error goes away when #define OTL_NO_TMPL_MEMBER_FUNC_SUPPORT
is enabled. The bug is fixed in this release by enabling the #define
for Borland C++ by default.
-
Michael
Shishkin from
Russia contributed the otl_subscriber
class that uses the Oracle
Database
Change
Notification Interface to implement a more
convenient publish / subscribe mechanism compared to the straight OCI.
The otl_subscriber class is optional and can be enabled via #define OTL_ORA_SUBSCRIBE. See
also example 585.
|
|
|
New in (OTL 4.0.158):
-
When #define OTL_UNICODE_EXCEPTION_AND_RLOGON
and #define _UNICODE / UNICODE (standard C/C++ #defines for Unicode
applications) are enabled, and otl_connect::rlogon() is used with
ODBC-like style connect strings ("UID=scott;PWD=tiger;DSN=mssql",
etc.),
the
underlying
SQLDriverConnect() call may crash the program,
because the size of the output string buffer was specified in bytes
instead of wide characters. The bug is fixed in this release:
Before
(line 9678):
status=SQLDriverConnect
(hdbc,
0,
temp_connect_str2,
OTL_SCAST(short,len),
out_str,
sizeof(out_str),
&out_len,
SQL_DRIVER_NOPROMPT);
Now
(line 9678):
status=SQLDriverConnect
(hdbc,
0,
temp_connect_str2,
OTL_SCAST(short,len),
out_str,
sizeof(out_str)/sizeof(SQLWCHAR),
&out_len,
SQL_DRIVER_NOPROMPT);
-
In OTL/OCI8/9/10 a break
statetement was missing in
27195 void open
27196 (const otl_stream_buffer_size_type arr_size,
const char* sqlstm,
otl_connect& db,
const char*
ref_cur_placeholder=0,
const char* sqlstm_label=0)
OTL_THROWS_OTL_EXCEPTION
...
27213 case otl_select_stream_type:
...
break;
The bug is fixed is this release.
-
Following new #define is introduced: OTL_MAP_LONG_TO_SQL_C_SBIGINT.
It
maps
64-bit
longs into SQL_C_BIGINT instead of SQL_C_SLONG in
OTL/ODBC/DB2-CLI.
-
The question
on MySQL in the F.A.Q was corrected to explain that InnoDB type tables
can be used with OTL.
|
|
|
New in (OTL 4.0.157):
-
A problem was reported that OTL doesn't compile with
aCC (HP ANSI C++ B3910B A.03.63), and it requires #define OTL_NO_TMPL_MEMBER_FUNC_SUPPORT
to be enabled. The problem is fixed in this release, and the aCC
compiler has been added to the list of C++ compilers for which the "no
template member function support" feature is enabled by default.
-
A problem was reported that when OTL is used with STL Port, and when STL Port is not
configured to expose some standard C++ functions like
uncaught_exception() in STL Port's own namespace _STL, and when #define
OTL_UNCAUGHT_EXCEPTION_ON
is enabled, the C++ compiler complains that the uncaught_exception()
function is not defined in the _STL namespace. In order to fix the
problem, the following new #define may be used: OTL_UNCAUGHT_EXCEPTION_OWN_NAMESPACE.
Of course, the STL Port can be reconfigured and rebuilt in order to
expose the uncaught_exception() in the _STL namespace, but sometimes
it's not an option.
-
OTL 4.0.156 introduced a bug in its new support for
BINARY_DOUBLE: when an actual BINARY_DOUBLE column gets SELECTed from a
table, it causes a program's crash. The bug is fixed in this release.
|
|
|
New (in OTL 4.0.156):
-
A problem was reported that when OTL is used with the
OCI 10g, and BINARY_DOUBLE, there is a roundup error in the 17th and
16th decimal singificant digits, for example when
1.6666666666666667E+000 gets inserted into a BINARY_DOUBLE column in a
table via OTL, the resulting value that is stored in the table is
1.6666666666666701E+000. A similar thing happens with BINARY_FLOAT
values. In order to bind <float> and <double> with Oracle
NUMBERs, OTL used SQLT_FLT (with sizeof(float), and sizeof(double),
respectively) as an external OCI datatype. The same SQLT_FLT was used
to bind <float> and <double> with BINARY_FLOAT, and
BINARY_DOUBLE. The OCI manual didn't specifiy any ramifications about
doing that.
It appears that better alternatives would be SQLT_BFLOAT and
SQLT_BDOUBLE (OCI manual only mentioned that performance would be
better, and nothing else). It also turned out that SQl_BFLOAT and
SQLT_BDOUBLE work better / have better precision, even when bound with
NUMBERs.
As I understood the mechanism, when you bind a <double> as
SQLT_BDOUBLE with, say, NUMBER or BINARY_DOUBLE, or with any other
numeric type, a <double> value gets sent across the wire /
SQL*Net as is, as opposed to a <double> value would be converted
into some wire format by the OCI, if the <double> variable is
bound as SQLT_FLT (sizof(double)),. In the latter case the conversion
loses the 16th and the 17th decimal significant digits (aka roundup).
The bug has been fixed in this release. When #define OTL_ORA10G or
#define OTL_ORA10G_R2 is defined, <float> and <double> get
bound as SQLT_BFLOAT and SQLT_BDOUBLE respectively, which provides
better precision.
|
|
|
New (int OTL 4.0.155):
|
|
|
New (in OTL 4.0.154):
-
Oracle 10G R2 (10.2) introduced the following bug:
When a 'alter session set NLS%'
statement is first executed in parse only mode and then in normal mode,
the setting changed does not get reflected. Bug # in metalink.oracle.com is 4904743.
Oracle promised to fix the bug in Oracle 11g.
OTL used PARSE ONLY to implement otl_connect::syntax_check(), and
PARSE ONLY + normal mode for direc_exec() functions. So, the bug broke
the OTL logic for 'alter session set NLS%' commands. This release works
around the bug.
-
This release introduces native support for TimesTen via the
following new #defines:
OTL_ODBC_TIMESTEN_WIN, OTL_ODBC_TIMESTEN_UNIX.
Code
examples for TimesTen
have
been updated to reflect the new feature.
|
|
|
New (in OTL 4.0.153):
-
OTL compiles clean with
the latest G++ (GCC 4.2)
-
OTL compiles clean with
Visual C++ 2005 (version 8.0) without disabling warning C4996: #pragma warning (disable:4996). Old C string
functions have been replaced with more secure VC++ 8.0 string
functions (for example, strcpy_s(), strcat_s(), sprintf_s()) whenever
possible, without breaking the existing design too much. Of course, the
new string functions get enabled only when OTL is being compiled with
VC++ 8.0.
-
Actual code examples
have been reworked to compile clean with Visual C++ 8.0.
|
|
|
New (in OTL 4.0.152):
-
A bug was reported that OTL 4.0.147 - OTl 4.0.151
broke inout
bind variables' behavior. The actual problem was that when NULL gets
written into an inout variable, the OTL stream's internal NULL
indicator doesn't get set to non-NULL on the output in case if the
variable receives a non-NULL value from the database. The bug was
introduced by an optimization tweak in OTL 4.0.147, and fixed in
this release.
-
(Updated): There is an open source ODBC driver for
Linux/Unix/Windows for accessing MS SQL 7.0 / 2000 / 2005 and Sybase
10.x / 11.x / 12.x / 15.x:. It's called FreeTDS.
At
this
point
time, the FreeTDS ODBC driver (version 0.63) is high
enough quality to work with OTL. The following FreeTDS based sets of
code examples have been added: MS SQL Server / FreeTDS ODBC,
Sybase SQL
Server / FreeTDS ODBC.
FreeTDS ODBC supports the bulk interface, calls to stored procedures,
etc. It doesn't support some features that are supported by the native
MS SQL and Sybase ODBC drivers, but for a free ODBC driver, it's good
enough performance-wise, and feature-wise. And it provides access to MS
SQL from Linux / Unix. Sybase native ODBC driver is available for
Windows and Linux. So, FreeTDS ODBC can be used for accessing Sybase
from Solaris and AIX (or any other supported platform that FreeTDS
supports). In non-Windows platforms, FreeTDS ODBC can be used with unixODBC, or iODBC.
-
(Updated):TimesTen
code examples have been tested against TimesTen
7.0.
|
|
|
New (in OTL 4.0.151):
|
|
|
New (in OTL 4.0.150):
-
A problem was reported that OTL throws an "Invalid
Handle" (OCI) exception when a PL/SQL block / stored procedure returns
an uninitialized CLOB / BLOB locator, and when the CLOB / BLOB is being
written to / read from via an otl_lob_stream.
To
address
the
problem, a new function has been added to the lob stream
class: is_initialized().
-
This release introduces support for Oracle UTF8 via
the following new #define: #define OTL_ORA_UTF8. See also
examples for Oracle 9i, UTF8,
and
Oracle 10g, UTF8.
|
|
|
New (in OTL 4.0.149):
-
A memory leak was reported in otl_stream, which turned out to be a
call to otl_stream::open() in a loop without a matching call to
otl_stream::close(). In order to simplify debugging of problems
like that, this release introduces the following two new OTL defined
exceptions:
-
code 32030, otl_stream is already open
-
code 32031,
otl_connect is already connected
-
DB2 zOS does not normally release row locks on a
SELECT statement, even after all the rows were already fetched, and
even the underlying cursor was closed. In order to release the row
locks, the SELECT statement has to be "committed" with an explicit
otl_connect::commit() call. The thing gets worse when on the DB2 zOS
side, a timeout on "inactive DB2 threads that lock resources" is set,
which results in a forced disconnect. DB2 CLI manual recommends to
explicitly set the SQL statement's SQL_ATTR_CLOSE_BEHAVIOR attribute to
SQL_CC_RELEASE (read locks are released), in which case the DB2 server
attempts to release read locks. No guarantees, of course.
This release sets the SQL statement's attribute to the recommended
value in case if the SELECT statement's isolation level was either
uncommitted read (UR), or cursor stability (CS, aka "read committed").
-
In this release, for DB2 CLI, all calls to
SQLFreeStmt(hstmt,SQL_CLOSE) were replaced with SQLCloseCursor(hstmt).
The difference between the two types of calls is that the latter will
return a DB2 CLI error if the call is made on a closed cursor.
SQLFreeStmt(hstmt,SQL_CLOSE) will return a "success". This was done in
order to simplify debugging of potential problems with cursor
management.
|
|
|
New (in OTL 4.0.148):
-
#define OTL_TRACE_ENABLE_STREAM_LABELS.
When
this
#define
is enabled, OTL trace records SQL statement labels
instead of the bodies of the SQL statements. It is useful for reducing
the size of the OTL trace.
-
#define OTL_NO_TMPL_MEMBER_FUNC_SUPPORT
was introduced in OTL 4.0.127.
The problem was reported that Visual C++ 7.0 (2002) does not support /
has a bug in template member functions. The OTL header file will
automatically enable the #define for Visual C++ 7.0 from this release
and on. Visual C++ 7.1, and 8.0 do not have the same problem / bug.
|
|
|
New (in OTL 4.0.147):
-
Internal code cleanup. Also, otl_stream::flush() function has been
optimized by 2-2.5%. Mileage may vary from one C++ compiler to another.
-
Following new #defines have been introduced: OTL_ORA7_TIMESTAMP_TO_STRING,OTL_ORA7_STRING_TO_TIMESTAMP.
The #defines should be used when
there is a need to use OCI7 and Oracle 9i/10g TIMESTAMPs in order to
enhance legacy applications. See also example 473.
-
Examples for SQLite have been updated to match what's
available in SQLite 3.3.x, and SQLite ODBC driver
0.71.
|
|
|
New (in OTL 4.0.146):
-
OTL/ODBC didn't compile with the Polyhedra
ODBC header files. The bug has been fixed in this release.
-
Description of #define OTL_ODBC_POSTGRESQL as
well as the PostgreSQL examples
have been changed.
-
The F.A.Q. has more
answers the following questions:
|
|
|
New (in OTL 4.0.145):
-
Basic support for MS SQL 2005 VARCHAR(MAX) and
VARBINARY(MAX) is introduced in this release. VARCHAR(MAX) and
VARBINARY(MAX) data types are "replacements" for "old" TEXT and IMAGE.
The new types are not quite backward compatible as far as MS SQL ODBC
is concerned. Basically it works, only the OTL LOB stream mode
doesn't work. I'd appreciate very much if somebody could point me
to an ODBC based code example that demonstrates how to use VARCHAR(MAX)
/ VARBINARY(MAX) in piece-wise read/write modes.
-
The following code examples have been introduced to
demonstrate more [new] features and code techniques:
-
This release enforces the minimum size of 2 characters
in :var<char[xxx]> declarations.
The reason is that char[1] is invalid because OTL char[xxx] variables
are null terminated
strings. #define OTL_ADD_NULL_TERMINATOR_TO_STRING_SIZE
adds one character to the string length, which makes :var<char[1]> a valid declaration.
-
OTL 4.0.138
relaxed the requirement of presetting the LOB length before the first
chunk of the LOB gets written to the LOB stream (otl_lob_stream), which changed the ODBC
/ DB2 CLI function call sequence. A bug was reported that when a LOB
stream is used for writing the LOB value, and the stream gets destroyed
before the end of the row, which LOB was written to, it causes the
"invaid function call sequence" error. The actual error message is
different in different database types,. The bug is fixed in this
release. This problem affects only ODBC and DB2 CLI applications, and
only if the LOB stream is destroyed before the end of the row. The
following [long] piece of code demonstrates the problem:
void
insert()
// insert rows into table
{
otl_long_string f2(6000); // define long string variable
otl_stream o; // defined an otl_stream variable
o.set_lob_stream_mode(true);
// set the "lob stream mode" flag
o.open(1,
// buffer size has to be set to 1 for operations with LOBs
"insert into test_tab "
"values(:f1<int>,:f2<varchar_long>, "
":f3<varchar_long>) ",
//
SQL statement
db // connect object
);
o.set_commit(0);
// setting stream "auto-commit" to "off". It is required
// when LOB stream mode is used.
int i,j;
otl_lob_stream *lob;
// LOB stream for reading/writing unlimited number
// of bytes regardless of the buffer size.
otl_lob_stream *lob2;
// LOB stream for reading/writing unlimited number
// of bytes regardless of the buffer size.
for(i=1;i<=20;++i){
lob = new otl_lob_stream;
lob2 = new otl_lob_stream;
o<<i;
o<<*lob; // Initialize otl_lob_stream by writing it
// into
otl_stream.
o<<*lob2; // Initialize otl_lob_stream by writing it
// into
otl_stream.
for(j=0;j<5000;++j)
f2[j]='*';
f2[5000]='?';
f2.set_len(5001);
// OTL < 4.0.138
lob->set_len(5001+2123); // setting the total
size of
//
the
TEXT
to be written.
*lob<<f2; // writing first chunk of the TEXT
into lob
f2[2122]='?';
f2.set_len(2123); // setting the size of the second chunk
*lob<<f2; // writing the second chunk of the TEXT into lob
lob->close(); // closing the otl_lob_stream
delete lob;
// here is a problem (in OTL 4.0.138 - 4.0.144),
// OK in 4.0.145 (this release)
// not the end
of the row yet
for(j=0;j<5000;++j)
f2[j]='*';
f2[5000]='?';
f2.set_len(5001);
// OTL <
4.0.138
lob2->set_len(5001+2123);
//
setting
the
total size of
//
the
TEXT
to be written.
*lob2<<f2; // writing first chunk of the TEXT into lob
f2[2122]='?';
f2.set_len(2123); // setting the size of the second chunk
*lob2<<f2; // writing the second chunk of the TEXT into lob
lob2->close(); // closing the otl_lob_stream
// end of the row
//delete lob; // deleting
here is OK
delete lob2;
}
|
|
|
New (in OTL 4.0.144):
-
OTL (4.0.129 - 4.0.143) did not compile with the real
OCI 8.0 header files. There was the following compilation error:
C2065:
'OCI_PARSE_ONLY' : undeclared identifier
The error is fixed in this release..
-
PostgreSQL 8.2 is out. This release has been
successfully tested with PostgreSQL 8.2.
|
|