📄 otl3_compile.htm
字号:
use with FreeTDS/ODBC against MS SQL. otl_connect::<a
href="otl3_connect_class.htm#auto_commit_on">auto_commit_on</a>() /
otl_connect::<a href="otl3_connect_class.htm#auto_commit_off">auto_commit_off</a>()
functions don't work for MS SQL with FreeTDS/ODBC. Until a fix becomes
available, it's not recommended to use them.<br>
<br>
Sybase is slightly d<span style="font-weight: bold;">i</span>fferent:
otl_connect::<a href="otl3_connect_class.htm#auto_commit_on">auto_commit_on</a>()
/
otl_connect::<a href="otl3_connect_class.htm#auto_commit_off">auto_commit_off</a>()
functions seem to work even though the otl_connect::rlogon()'s
auto_commit doesn't work. After rlogon() has been called, it's
recommended to call auto_commit_off(). See <a
href="otl4_sybsql_freetds_examples.htm">Sybase
SQL Server / FreeTDS ODBC</a> examples for more detail.<br>
<br>
In FreeTDS/ODBC, the default for the database session's auto-commit
mode is "auto-commit ON", which can't be turned off or on again. When
#define OTL_FREETDS_ODBC_WORKAROUNDS is enabled, OTL emulates the
database session's "auto-commit off" mode by executing "begin
transaction" at the beginning of each transaction, and not executing
anything when the "auto-commit" is set to ON, which is the default in
FreeTDS/ODBC. <br>
<br>
Also, FreeTDS/ODBC doesn't support "transaction isolation" level, that
is, otl_connect::<a
href="otl3_connect_class.htm#set_transaction_isolation_level">set_transaction_isolation_level</a>()
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.<span style="font-family: monospace;"><br>
</span><br>
</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 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 the hexadecimal string format
by default. Of course, the new default mapping can be overriden
manually. </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] 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. 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> </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 by
introducing
this #define. </td>
</tr>
<tr>
<td style="vertical-align: top;"><span style="font-weight: bold;"><a
name="OTL_ORA_LEGACY_NUMERIC_TYPES"></a>OTL_ORA_<br>
LEGACY_<br>
NUMERIC_TYPES</span><br>
</td>
<td style="vertical-align: top;">This #define should be used in a
combination with #define <a href="#OTL_ORA10G">OTL_ORA10G,</a> or <a
href="#OTL_ORA10G_R2">OTL_ORA10G_R2,</a> or <a href="#OTL_ORA11G">OTL_ORA11G</a>.
It disables the use of OCI10 native SQLT_BDOUBLE / SQLT_BFLOAT
bindings, and reverts to <code>SQLT_FLT</code> bindings, which are
compatible with older versions of the OCI. This define can be enabled
when the Oracle Client 10g, or 1g is used against older versions of the
Oracle server, say, Oracle 9.2. When the OCI10 native SQLT_BDOUBLE /
SQLT_BFLOAT bindings are used via the Oracle 10 Client with, say,
Oracle 9i database backend, the bindings don't work, because the Oracle
9i server doesn't support them. </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 cover 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<long></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
>>/<< for numeric data types (int, unsigned, short, long,
float, double, signed 64-bit int) for C++ compilers that have support
for the feature. 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)
\</span><br style="font-family: monospace;">
<span style="font-family: monospace;">{
\</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
sprintf(s,
\</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
"%02d/%02d/%04d %02d:%02d:%02d.%06ld",\</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
tm.month,
\</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
tm.day,
\</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
tm.year,
\</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
tm.hour,
\</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
tm.minute,
\</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
tm.second,
\</span><br style="font-family: monospace;">
<span style="font-family: monospace;">
tm.fraction
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -