dbd::oracle.3

视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.

Constants for the Oracle datatypes may be imported using
.Sp
.Vb 1
\&  use DBD::Oracle qw(:ora_types);
.Ve
.Sp
Potentially useful values when DBD::Oracle was built using \s-1OCI\s0 7 and later:
.Sp
.Vb 2
\&  ORA_VARCHAR2, ORA_STRING, ORA_LONG, ORA_RAW, ORA_LONGRAW,
\&  ORA_CHAR, ORA_MLSLABEL, ORA_RSET
.Ve
.Sp
Additional values when DBD::Oracle was built using \s-1OCI\s0 8 and later:
.Sp
.Vb 1
\&  ORA_CLOB, ORA_BLOB, ORA_NTY, ORA_VARCHAR2_TABLE, ORA_NUMBER_TABLE
.Ve
.Sp
See \*(L"Binding Cursors\*(R" for the correct way to use \s-1ORA_RSET\s0.
.Sp
See \*(L"Handling LOBs\*(R" for how to use \s-1ORA_CLOB\s0 and \s-1ORA_BLOB\s0.
.Sp
See \*(L"\s-1SYS\s0.DBMS_SQL datatypes\*(R" for \s-1ORA_VARCHAR2_TABLE\s0, \s-1ORA_NUMBER_TABLE\s0.
.Sp
See \*(L"Other Data Types\*(R" for more information.
.Sp
See also \*(L"Placeholders and Bind Values\*(R" in \s-1DBI\s0.
.IP "ora_csform" 4
.IX Item "ora_csform"
Specify the \s-1OCI_ATTR_CHARSET_FORM\s0 for the bind value. Valid values
are \s-1SQLCS_IMPLICIT\s0 (1) and \s-1SQLCS_NCHAR\s0 (2). Both those constants can
be imported from the DBD::Oracle module. Rarely needed.
.IP "ora_csid" 4
.IX Item "ora_csid"
Specify the \fIinteger\fR \s-1OCI_ATTR_CHARSET_ID\s0 for the bind value. 
Character set names can't be used currently.
.IP "ora_maxdata_size" 4
.IX Item "ora_maxdata_size"
Specify the integer \s-1OCI_ATTR_MAXDATA_SIZE\s0 for the bind value. 
May be needed if a character set conversion from client to server
causes the data to use more space and so fail with a truncation error.
.IP "ora_maxarray_numentries" 4
.IX Item "ora_maxarray_numentries"
Specify the maximum number of array entries to allocate. Used with
\&\s-1ORA_VARCHAR2_TABLE\s0, \s-1ORA_NUMBER_TABLE\s0. Define the maximum number of
array entries Oracle can pass back to you in \s-1OUT\s0 variable of type
\&\s-1TABLE\s0 \s-1OF\s0 ... .
.IP "ora_internal_type" 4
.IX Item "ora_internal_type"
Specify internal data representation. Currently is supported only for
\&\s-1ORA_NUMBER_TABLE\s0.
.Sh "Trailing Spaces"
.IX Subsection "Trailing Spaces"
Please note that only the Oracle \s-1OCI\s0 8 strips trailing spaces from \s-1VARCHAR\s0 placeholder
values and uses Nonpadded Comparison Semantics with the result. 
This causes trouble if the spaces are needed for
comparison with a \s-1CHAR\s0 value or to prevent the value from
becoming '' which Oracle treats as \s-1NULL\s0.
Look for Blank-padded Comparison Semantics and Nonpadded
Comparison Semantics in Oracle's \s-1SQL\s0 Reference or Server
\&\s-1SQL\s0 Reference for more details.
.PP
To preserve trailing spaces in placeholder values for Oracle clients that use \s-1OCI\s0 8, 
either change the default placeholder type with \*(L"ora_ph_type\*(R" or the placeholder
type for a particular call to \*(L"bind\*(R" in \s-1DBI\s0 or \*(L"bind_param_inout\*(R" in \s-1DBI\s0
with \*(L"ora_type\*(R" or \f(CW\*(C`TYPE\*(C'\fR.
Using \s-1ORA_CHAR\s0 with ora_type or \f(CW\*(C`SQL_CHAR\*(C'\fR with \f(CW\*(C`TYPE\*(C'\fR
allows the placeholder to be used with Padded Comparison Semantics
if the value it is being compared to is a \s-1CHAR\s0, \s-1NCHAR\s0, or literal.
.PP
Please remember that using spaces as a value or at the end of
a value makes visually distinguishing values with different
numbers of spaces difficult and should be avoided.
.PP
Oracle Clients that use \s-1OCI\s0 9.2 do not strip trailing spaces.
.Sh "Padded Char Fields"
.IX Subsection "Padded Char Fields"
Oracle Clients after \s-1OCI\s0 9.2 will automatically pad \s-1CHAR\s0 placeholder values to the size of the \s-1CHAR\s0.
As the default placeholder type value in DBD::Oracle is \s-1ORA_VARCHAR2\s0 to access this behavior you will 
have to change the default placeholder type with \*(L"ora_ph_type\*(R" or placeholder 
type for a particular call with \*(L"bind\*(R" in \s-1DBI\s0 or \*(L"bind_param_inout\*(R" in \s-1DBI\s0
with \*(L"\s-1ORA_CHAR\s0\*(R" or \f(CW\*(C`ORA_CHARZ\*(C'\fR.
.SH "Metadata"
.IX Header "Metadata"
.ie n .Sh """get_info()"""
.el .Sh "\f(CWget_info()\fP"
.IX Subsection "get_info()"
DBD::Oracle supports \f(CW\*(C`get_info()\*(C'\fR, but (currently) only a few info types.
.ie n .Sh """table_info()"""
.el .Sh "\f(CWtable_info()\fP"
.IX Subsection "table_info()"
DBD::Oracle supports attributes for \f(CW\*(C`table_info()\*(C'\fR.
.PP
In Oracle, the concept of \fIuser\fR and \fIschema\fR is (currently) the
same. Because database objects are owned by an user, the owner names
in the data dictionary views correspond to schema names.
Oracle does not support catalogs so \s-1TABLE_CAT\s0 is ignored as
selection criterion.
.PP
Search patterns are supported for \s-1TABLE_SCHEM\s0 and \s-1TABLE_NAME\s0.
.PP
\&\s-1TABLE_TYPE\s0 may contain a comma-separated list of table types.
The following table types are supported:
.PP
.Vb 4
\&  TABLE
\&  VIEW
\&  SYNONYM
\&  SEQUENCE
.Ve
.PP
The result set is ordered by \s-1TABLE_TYPE\s0, \s-1TABLE_SCHEM\s0, \s-1TABLE_NAME\s0.
.PP
The special enumerations of catalogs, schemas and table types are
supported. However, \s-1TABLE_CAT\s0 is always \s-1NULL\s0.
.PP
An identifier is passed \fIas is\fR, i.e. as the user provides or
Oracle returns it.
\&\f(CW\*(C`table_info()\*(C'\fR performs a case-sensitive search. So, a selection
criterion should respect upper and lower case.
Normally, an identifier is case-insensitive. Oracle stores and
returns it in upper case. Sometimes, database objects are created
with quoted identifiers (for reserved words, mixed case, special
characters, ...). Such an identifier is case-sensitive (if not all
upper case). Oracle stores and returns it as given.
\&\f(CW\*(C`table_info()\*(C'\fR has no special quote handling, neither adds nor
removes quotes.
.ie n .Sh """primary_key_info()"""
.el .Sh "\f(CWprimary_key_info()\fP"
.IX Subsection "primary_key_info()"
Oracle does not support catalogs so \s-1TABLE_CAT\s0 is ignored as
selection criterion.
The \s-1TABLE_CAT\s0 field of a fetched row is always \s-1NULL\s0 (undef).
See \*(L"\fItable_info()\fR\*(R" for more detailed information.
.PP
If the primary key constraint was created without an identifier,
\&\s-1PK_NAME\s0 contains a system generated name with the form SYS_Cn.
.PP
The result set is ordered by \s-1TABLE_SCHEM\s0, \s-1TABLE_NAME\s0, \s-1KEY_SEQ\s0.
.PP
An identifier is passed \fIas is\fR, i.e. as the user provides or
Oracle returns it.
See \*(L"\fItable_info()\fR\*(R" for more detailed information.
.ie n .Sh """foreign_key_info()"""
.el .Sh "\f(CWforeign_key_info()\fP"
.IX Subsection "foreign_key_info()"
This method (currently) supports the extended behavior of \s-1SQL/CLI\s0, i.e. the
result set contains foreign keys that refer to primary \fBand\fR alternate keys.
The field \s-1UNIQUE_OR_PRIMARY\s0 distinguishes these keys.
.PP
Oracle does not support catalogs, so \f(CW$pk_catalog\fR and \f(CW$fk_catalog\fR are
ignored as selection criteria (in the new style interface).
The \s-1UK_TABLE_CAT\s0 and \s-1FK_TABLE_CAT\s0 fields of a fetched row are always
\&\s-1NULL\s0 (undef).
See \*(L"\fItable_info()\fR\*(R" for more detailed information.
.PP
If the primary or foreign key constraints were created without an identifier,
\&\s-1UK_NAME\s0 or \s-1FK_NAME\s0 contains a system generated name with the form SYS_Cn.
.PP
The \s-1UPDATE_RULE\s0 field is always 3 ('\s-1NO\s0 \s-1ACTION\s0'), because Oracle (currently)
does not support other actions.
.PP
The \s-1DELETE_RULE\s0 field may contain wrong values. This is a known Bug (#1271663)
in Oracle's data dictionary views. Currently (as of 8.1.7), '\s-1RESTRICT\s0' and
\&'\s-1SET\s0 \s-1DEFAULT\s0' are not supported, '\s-1CASCADE\s0' is mapped correctly and all other
actions (incl. '\s-1SET\s0 \s-1NULL\s0') appear as '\s-1NO\s0 \s-1ACTION\s0'.
.PP
The \s-1DEFERABILITY\s0 field is always \s-1NULL\s0, because this columns is
not present in the \s-1ALL_CONSTRAINTS\s0 view of older Oracle releases.
.PP
The result set is ordered by \s-1UK_TABLE_SCHEM\s0, \s-1UK_TABLE_NAME\s0, \s-1FK_TABLE_SCHEM\s0,
\&\s-1FK_TABLE_NAME\s0, \s-1ORDINAL_POSITION\s0.
.PP
An identifier is passed \fIas is\fR, i.e. as the user provides or
Oracle returns it.
See \*(L"\fItable_info()\fR\*(R" for more detailed information.
.ie n .Sh """column_info()"""
.el .Sh "\f(CWcolumn_info()\fP"
.IX Subsection "column_info()"
Oracle does not support catalogs so \s-1TABLE_CAT\s0 is ignored as
selection criterion.
The \s-1TABLE_CAT\s0 field of a fetched row is always \s-1NULL\s0 (undef).
See \*(L"\fItable_info()\fR\*(R" for more detailed information.
.PP
The \s-1CHAR_OCTET_LENGTH\s0 field is (currently) always \s-1NULL\s0 (undef).
.PP
Don't rely on the values of the \s-1BUFFER_LENGTH\s0 field!
Especially the length of FLOATs may be wrong.
.PP
Datatype codes for non-standard types are subject to change.
.PP
Attention! The \s-1DATA_DEFAULT\s0 (\s-1COLUMN_DEF\s0) column is of type \s-1LONG\s0.
.PP
The result set is ordered by \s-1TABLE_SCHEM\s0, \s-1TABLE_NAME\s0, \s-1ORDINAL_POSITION\s0.
.PP
An identifier is passed \fIas is\fR, i.e. as the user provides or
Oracle returns it.
See \*(L"\fItable_info()\fR\*(R" for more detailed information.
.SH "Unicode"
.IX Header "Unicode"
DBD::Oracle now supports Unicode \s-1UTF\-8\s0. There are, however, a number
of issues you should be aware of, so please read all this section
carefully.
.PP
In this section we'll discuss \*(L"Perl and Unicode\*(R", then \*(L"Oracle and
Unicode\*(R", and finally \*(L"DBD::Oracle and Unicode\*(R".
.PP
Information about Unicode in general can be found at:
<http://www.unicode.org/>. It is well worth reading because there are
many misconceptions about Unicode and you may be holding some of them.
.Sh "Perl and Unicode"
.IX Subsection "Perl and Unicode"
Perl began implementing Unicode with version 5.6, but the implementation
did not mature until version 5.8 and later. If you plan to use Unicode
you are \fIstrongly\fR urged to use perl 5.8.2 or later and to \fIcarefully\fR read
the perl documentaion on Unicode:
.PP
.Vb 2
\&   perldoc perluniintro    # in perl 5.8 or later
\&   perldoc perlunicode
.Ve
.PP
And then read it again.
.PP
Perl's internal unicode format is \s-1UTF\-8\s0
which corresponds to the Oracle character set called \s-1AL32UTF8\s0.
.Sh "Oracle and Unicode"
.IX Subsection "Oracle and Unicode"
Oracle supports many characters sets, including several different forms
of Unicode.  These include:
.PP
.Vb 3
\&  AL16UTF16  =>  valid for NCHAR columns (CSID=2000)
\&  UTF8       =>  valid for NCHAR columns (CSID=871), deprecated
\&  AL32UTF8   =>  valid for NCHAR and CHAR columns (CSID=873)
.Ve
.PP
When you create an Oracle database, you must specify the \s-1DATABASE\s0 
character set (used for \s-1DDL\s0, \s-1DML\s0 and \s-1CHAR\s0 datatypes) and the \s-1NATIONAL\s0 
character set (used for \s-1NCHAR\s0 and \s-1NCLOB\s0 types).
The character sets used in your database can be found using:
.PP
.Vb 3
\&  $hash_ref = $dbh\->ora_nls_parameters()
\&  $database_charset = $hash_ref\->{NLS_CHARACTERSET};
\&  $national_charset = $hash_ref\->{NLS_NCHAR_CHARACTERSET};
.Ve
.PP
The Oracle 9.2 and later default for the national character set is \s-1AL16UTF16\s0.
The default for the database character set is often \s-1US7ASCII\s0.
Although many experienced DBAs will consider an 8bit character set like
\&\s-1WE8ISO8859P1\s0 or \s-1WE8MSWIN1252\s0.  To use any character set with Oracle
other than \s-1US7ASCII\s0, requires that the \s-1NLS_LANG\s0 environment variable be set.
See the \*(L" 8\-bit text issues\*(R"\*(L" in \*(R"International \s-1NLS\s0  section below.
.PP
You are strongly urged to read the Oracle Internationalization documentation
specifically with respect the choices and trade offs for creating
a databases for use with international character sets.
.PP
Oracle uses the \s-1NLS_LANG\s0 environment variable to indicate what
character set is being used on the client.  When fetching data Oracle
will convert from whatever the database character set is to the client
character set specified by \s-1NLS_LANG\s0. Similarly, when sending data to
the database Oracle will convert from the character set specified by
\&\s-1NLS_LANG\s0 to the database character set.
.PP
The \s-1NLS_NCHAR\s0 environment variable can be used to define a different
character set for 'national' (\s-1NCHAR\s0) character types.
.PP
Both \s-1UTF8\s0 and \s-1AL32UTF32\s0 can be used in \s-1NLS_LANG\s0 and \s-1NLS_NCHAR\s0.
For example:
.PP
.Vb 4
\&   NLS_LANG=AMERICAN_AMERICA.UTF8
\&   NLS_LANG=AMERICAN_AMERICA.AL32UTF8
\&   NLS_NCHAR=UTF8
\&   NLS_NCHAR=AL32UTF8
.Ve
.PP
Oracle 8 client libraries have a number of bugs related to character
set handling, especially when connected to an Oracle 9+ server.
For this reason a number of DBD::Oracle tests are disabled when
using an Oracle 8 client. If you wish to use Unicode, I recommend
upgrading client and server to Oracle 9 or later.
.Sh "Oracle \s-1UTF8\s0 is not \s-1UTF\-8\s0"
.IX Subsection "Oracle UTF8 is not UTF-8"
\&\s-1AL32UTF8\s0 should be used in preference to \s-1UTF8\s0 if it works for you,
which it should for Oracle 9.2 or later. If you're using an old
version of Oracle that doesn't support \s-1AL32UTF8\s0 then you should
avoid using any Unicode characters that require surrogates, in other
words characters beyond the Unicode \s-1BMP\s0 (Basic Multilingual Plane).
.PP
That's because the character set that Oracle calls \*(L"\s-1UTF8\s0\*(R" doesn't
conform to the \s-1UTF\-8\s0 standard in its handling of surrogate characters.
Technically the encoding that Oracle calls \*(L"\s-1UTF8\s0\*(R" is known as \*(L"\s-1CESU\-8\s0\*(R".
Here are a couple of extracts from <http://www.unicode.org/reports/tr26/>:
.PP
.Vb 4
\&  CESU\-8 is useful in 8\-bit processing environments where binary
\&  collation with UTF\-16 is required. It is designed and recommended
\&  for use only within products requiring this UTF\-16 binary collation
\&  equivalence. It is not intended nor recommended for open interchange.
\&
\&  As a very small percentage of characters in a typical data stream
\&  are expected to be supplementary characters, there is a strong
\&  possibility that CESU\-8 data may be misinterpreted as UTF\-8.
\&  Therefore, all use of CESU\-8 outside closed implementations is
\&  strongly discouraged, such as the emittance of CESU\-8 in output
\&  files, markup language or other open transmission forms.
.Ve
.PP
Oracle uses this internally because it collates (sorts) in the same order
as \s-1UTF16\s0, which is the basis of Oracle's internal collation definitions.
.PP
Rather than change \s-1UTF8\s0 for clients Oracle chose to define a new character
set called \*(L"\s-1AL32UTF8\s0\*(R" which does conform to the \s-1UTF\-8\s0 standard.
(The \s-1AL32UTF8\s0 character set can't be used on the server because it
would break collation.)
.PP
Because of that, for the rest of this document we'll use \*(L"\s-1AL32UTF8\s0\*(R".
If you're using an Oracle version below 9.2 you'll need to use \*(L"\s-1UTF8\s0\*(R"
until you upgrade.
.Sh "DBD::Oracle and Unicode"
.IX Subsection "DBD::Oracle and Unicode"
DBD::Oracle Unicode support has been implemented for Oracle versions 9
or greater, and perl version 5.6 or greater (though we \fIstrongly\fR
suggest that you use perl 5.8.2 or later).
.PP
You can check which Oracle version your DBD::Oracle was built with by
importing the \f(CW\*(C`ORA_OCI\*(C'\fR constant from DBD::Oracle.
.PP
\&\fBFetching Data\fR
.PP
Any data returned from Oracle to DBD::Oracle in the \s-1AL32UTF8\s0