otl3_compile.htm

otl是c++数据库封装好的一个数据库接口

hiararchy
is a good example. otl_exception can be derived from one of the classes
in the hierarchy, so that a catch block, that catches exception of the
base class, will be able to catch exceptions of the otl_exception
class.
In the OTL header file, in case if this #define is defined, the class,
defined in the #define, will be specified as a base class for the
otl_exception
class. </td>
    </tr>
    <tr>
      <td style="vertical-align: top;"><span style="font-weight: bold;"><a
 name="OTL_EXCEPTION_ENABLE_ERROR_OFFSET"></a>OTL_EXCEPTION_<br>
ENABLE_<br>
ERROR_<br>
OFFSET</span></td>
      <td style="vertical-align: top;">This #define enables the so
called SQL Statement Parse Error Offset, and it is available for
OTL/OCIx only. When an otl_exception gets thrown, and it has
otl_exception::stm_text field populated, the parse error offset will
point to the actual position of the SQL error.<br>
      </td>
    </tr>
    <tr>
      <td style="vertical-align: top;"><font size="-1"><a
 name="OTL_EXCEPTION_HAS_MEMBERS"></a><b>OTL_EXCEPTION<br>
_HAS_MEMBERS</b></font></td>
      <td style="vertical-align: top;">This #define
allows the user to
define new member functions or data
members
in the <a href="otl3_exception_class.htm">otl_exception</a>
class. The
OTL header file checks out whether this #define is defined, and then
the
body of the #define gets included textually into the body of the
otl_exception
class. This simple technique allows the otl_exception class to have new
members. This #define can be used in a combination with #define <a
 href="otl3_compile.htm#OTL_EXCEPTION_DERIVED_FROM">OTL_EXCEPTION_DERIVED_FROM</a>.
      </td>
    </tr>
    <tr>
      <td style="vertical-align: top;"><font size="-1"><a
 name="OTL_EXPLICIT_NAMESPACES"></a><b>OTL_EXPLICIT<br>
_NAMESPACES</b> <br>
      </font></td>
      <td style="vertical-align: top;">(for
turning on namespaces) </td>
    </tr>
    <tr>
      <td style="vertical-align: top;"><span style="font-weight: bold;"><a
 name="OTL_EXCEPTION_STM_TEXT_SIZE"></a>OTL_EXCEPTION_<br>
STM_TEXT_<br>
SIZE</span><br>
      </td>
      <td style="vertical-align: top;">This #define specifies a new
size for the <a href="otl3_exception_class.htm">otl_exception</a>::<a
 href="otl3_exception_class.htm#stm_text">stm_text</a> buffer. By
default, it's 2048 bytes, that is, the actual otl_exception will
contain only 2047 first bytes of the SQL statement, associated with the
exception. If more bytes of the SQL statement text is needed, the
#define can come handy.This #define can be used in a combination with
#define <a href="#OTL_EXCEPTION_ENABLE_ERROR_OFFSET">OTL_EXCEPTION_ENABLE_ERROR_OFFSET</a>,
for example:<br>
      <br>
      <span style="font-family: monospace;">#define
OTL_EXCEPTION_ENABLE_ERROR_OFFSET<br>
#define OTL_EXCEPTION_STM_TEXT_SIZE 32767<br>
      </span><br>
      </td>
    </tr>
    <tr>
      <td style="vertical-align: top;"><font size="-1"><a
 name="OTL_EXTENDED_EXCEPTION"></a><b>OTL_EXTENDED<br>
_EXCEPTION</b>&nbsp;</font></td>
      <td style="vertical-align: top;">(for
enabling the otl_exception's <a
 href="otl3_exception_class.htm#EXTENDED">extended
fields</a> for OTL/ODBC and OTL/DB2-CLI). This is for fixing problem <a
 href="otl3_prob.htm#prob47">47.</a> </td>
    </tr>
    <tr>
      <td style="vertical-align: top;"><span style="font-weight: bold;"><a
 name="OTL_MAP_SQL_GUID_TO_CHAR"></a>OTL_MAP_<br>
SQL_GUID_<br>
TO_CHAR</span><br>
      </td>
      <td style="vertical-align: top;">Before OTL 4.0.140, MS SQL GUIDs
(uniqueidentifier) were mapped to char[XXX]. OTL 4.0.140 and
higher&nbsp; maps the GUIDs to <a href="otl3_bind_variables.htm#raw">raw</a>[16],
This #define should be used to map GUIDs to char[XXX] by default. Of
course, the new default mapping can be overriden manually Also, see
example <a href="otl3_ex105.htm">105</a>.<br>
      </td>
    </tr>
    <tr>
      <td style="vertical-align: top;"><span style="font-weight: bold;"><a
 name="OTL_MAP_SQL_BINARY_TO_CHAR"></a>OTL_MAP_<br>
SQL_BINARY_<br>
TO_CHAR</span><br>
      </td>
      <td style="vertical-align: top;">Before OTL 4.0.140, MS SQL
TIMESTAMPs were mapped to char[XXX], which was effectively a conversion
from the binary format to the hexadecimal string format. OTL 4.0.140
and higher maps MS SQL TIMESTAMPs to <a
 href="otl3_bind_variables.htm#raw">raw</a>[XXX]. This #define should
be used to map MS SQL TIMESTAMPs to&nbsp; the hexadecimal string format
by default. Of course, the new default mapping can be overriden
manually.&nbsp; </td>
    </tr>
    <tr>
      <td style="vertical-align: top;"><span style="font-weight: bold;"><a
 name="OTL_MAP_SQL_VARBINARY_TO_RAW_LONG"></a>OTL_MAP_<br>
SQL_VARBINARY_<br>
TO_RAW_LONG</span><br>
      </td>
      <td style="vertical-align: top;">Before OTL 4.0.140,, "<a
 href="otl3_bind_variables.htm#raw">binary</a>" database types were
mapped to <a href="otl3_bind_variables.htm#raw_log">raw_long</a>. OTL
4.0.140 and higher maps the "binary" types to <a
 href="otl3_bind_variables.htm#raw">raw</a>[XXX]&nbsp; This #define
should be used to map the binary types to raw_long by default. Of
course, the new default mapping can be overriden manually.&nbsp; Also,
see example <a href="otl4_ex346.htm">346</a>.<br>
      </td>
    </tr>
    <tr>
      <td style="vertical-align: top;"><span style="font-weight: bold;"><a
 name="OTL_STREAM_LEGACY_BUFFER_SIZE_TYPE"></a>OTL_STREAM_<br>
LEGACY_<br>
BUFFER_<br>
SIZE_TYPE</span><br>
      </td>
      <td style="vertical-align: top;">OTL 4.0.115 introduces a larger
datatype for the OTL stream <a href="otl3_stream_class.htm#buffer_size">buffer
size</a>: <span style="font-style: italic;">int</span> instead of the
old <span style="font-style: italic;">short int</span>. The buffer
size parameter was short int for a long time to keep all OTL based code
compatible with older database APIs (like original OCI7, or
restrictions on some old ODBC drivers), and portable across platforms /
databases. Now is time to move on. "int" as a datatype for the buffer
size provides a much wider value range. "int" is the default for the
OTL stream buffer size parameter from OTL 4.0.115 and on. However,
those old, legacy applicationz based on OTL cannot be left behind. This
#define, when enabled, turns the old "short int" type for the buffer
size back on.<br>
      </td>
    </tr>
    <tr>
      <td style="vertical-align: top;"><font size="-1"><a
 name="OTL_FUNC_THROW_SPEC_ON"></a><b>OTL_FUNC<br>
_THROW_SPEC_ON</b>&nbsp;</font></td>
      <td style="vertical-align: top;">This
#define works in a combination with #define <a
 href="otl3_compile.htm#OTL_ANSI_CPP">OTL_ANSI_CPP</a>
(when OTL_ANSI_CPP is defined). This #define enables the <i>function
throw
specification clause </i>(introduced in OTL 4.0.50) in all OTL
functions,
to make them explicitly declare what type C++ exceptions the function
may
throw. It looks like there is no consesus in the C++ community whether
function throw specs are good or not, and I decided to make it up to
each
OTL user to whether enable or not enable this OTL feature&nbsp; by
introducing
this #define. </td>
    </tr>
    <tr>
      <td style="vertical-align: top;"><span style="font-weight: bold;"><a
 name="OTL_MAP_LONG_TO_SQL_C_SBIGINT"></a>OTL_MAP_<br>
LONG_TO_<br>
SQL_C_SBIGINT</span><br>
      </td>
      <td style="vertical-align: top;">In the ODBC/DB2 CLI standard,
SQL_C_SLONG contains 32 bits regardless of the size of "long int" on a
given 64-bit platform. Similarly, SQL_C_SBIGINT is a signed 64-bit
integer, regardless of whether the platform is 32-bit or 64-bit. ODBC
drivers have different implementations of SQL_C_SLONG, meaning that
some ODBC drivers deviate from the standard. OTL tries to covver all
implementations of the SQL_C_SLONG. This #define maps "long" (in bind
variable declarations) into SQL_C_SBIGINT in case if sizeof(long) == 8.
For example, <span style="font-family: monospace;">:v1&lt;long&gt;</span>
will be mapped to SQL_C_SBIGINT, which is a signed 64-bit integer. <br>
      </td>
    </tr>
    <tr>
      <td style="vertical-align: top;"><span style="font-weight: bold;"><a
 name="OTL_NO_TMPL_MEMBER_FUNC_SUPPORT"></a>OTL_NO_TMPL_<br>
MEMBER_<br>
FUNC_<br>
SUPPORT</span><br>
      </td>
      <td style="vertical-align: top;">OTL 4.0.127 or higher tries to
use template member functions for implementing operator
&gt;&gt;/&lt;&lt; for numeric data types (int, unsigned, short, long,
float, double, signed 64-bit int) for C++ compilers that have support
for the feature.&nbsp; However, even after so many years since the C++
standard was adopted back in the summer of 1998, some C++ compilers
either still have bugs in their support of the feature, or are missing
any support completely. If that happens, it's possible to make OTL fall
back on the old proven plain nontemplate member functions. This #define
can be used to do just that.<br>
      </td>
    </tr>
    <tr>
      <td style="vertical-align: top;"><span style="font-weight: bold;"><a
 name="OTL_ORA_SUBSCRIBE"></a>OTL_ORA_<br>
SUBSCRIBE</span><br>
      </td>
      <td style="vertical-align: top;">This #define enables the <a
 href="otl4_subscriber.htm">otl_subscriber</a> class. The class is
Oracle 9/10 (or higher) specific. It uses the Oracle Change
Notification OCI functions, which allow the user to get notified about
changes on database tables of interest. This feature is especially
useful in an Oracle RAC environment, though the interface works in a
stand alone Oracle instance. When #define OTL_ORA_SUBSCRIBE is enabled,
the following #define's need to enabled as well:<br>
      <pre>#define OTL_ORA_OCI_ENV_CREATE<br>#define OTL_ORA_OCI_ENV_CREATE_MODE (OCI_THREADED|OCI_OBJECT|OCI_EVENTS)<br></pre>
      </td>
    </tr>
    <tr>
      <td style="vertical-align: top;"><span style="font-weight: bold;"><a
 name="OTL_ORA_UTF8"></a>OTL_ORA_UTF8</span><br>
      </td>
      <td style="vertical-align: top;">This #define enables OCI9i/10g
support for Oracle UTF8 character encodings (UTF8, AL32UTF8). This
#define is mutually exclusive with #define <a href="#OTL_UNICODE">OTL_UNICODE</a>,
which supports UTF-16. UTF-8 seems to be more popular <big>with Oracle
C++ <small>developers at least in Linux/Unix. The basic difference
between UTF-8 and UTF-16 is that UTF-8 is byte oriented. It's okay to
use a '\0' terminated array of unsigned chars with UTF-8 as opposed to
an array of unsigned 16-bit integers with UTF-16.</small></big><br>
      </td>
    </tr>
    <tr style="font-weight: bold;">
      <td style="vertical-align: top;"><a
 name="OTL_ORA7_STRING_TO_TIMESTAMP"></a>OTL_ORA7_<br>
STRING_TO_<br>
TIMESTAMP<br>
      </td>
      <td style="vertical-align: top;"><span
 style="font-weight: normal;">OCI7 is still important even when used
against Oracle 9i or Oracle 10g. In fact, OCI7 is supported by all
Oracle Clients with no exception, and it is called the <span
 style="font-style: italic;">classic OCI</span>. In addition to DATE,
Oracle 9i introduced TIMESTAMP as a new temporal datatype which
supports fractional parts of the second: milliseconds, microseconds,
etc. Sometimes, there is a need to use TIMESTAMPs and OCI7 together in
order to enhance legacy applications. This #define makes the use of
TIMESTAMPs transparaent through OCI7. For example:<br>
      <br>
      <small><small><span style="font-family: monospace;">#define
OTL_ORA7 // Compile OTL 4.0/OCI7</span><br
 style="font-family: monospace;">
      <span style="font-family: monospace;">#define <a
 href="#OTL_ORA7_TIMESTAMP_TO_STRING">OTL_ORA7_TIMESTAMP_TO_STRING</a>(tm,s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
\</span><br style="font-family: monospace;">
      <span style="font-family: monospace;">{&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
\</span><br style="font-family: monospace;">