DBD::Ingres - DBI driver for Ingres database systems |
DBD::Ingres - DBI driver for Ingres database systems
$dbh = DBI->connect("DBI:Ingres:$dbname", $user, $options, {AutoCommit=>0}) $sth = $dbh->prepare($statement) $sth = $dbh->prepare($statement, {ing_readonly=>1}) $sth->execute @row = $sth->fetchrow $sth->finish $dbh->commit $dbh->rollback $dbh->disconnect ...and many more
DBD::Ingres is a database driver for the perl DBI system that allows access to Ingres databases. It is built on top of the standard DBI extension and implements the methods that DBI requires.
This document describes the differences between the ``generic'' DBD and DBD::Ingres.
DBI->connect("DBI:Ingres:dbname[;options]"); DBI->connect("DBI:Ingres:dbname[;options]", user [, password]); DBI->connect("DBI:Ingres:dbname[;options]", user [, password], \%attr);
To use DBD::Ingres call connect
specifying a datasource option beginning
with ``DBI:Ingres:'', followed by the database instance name and
optionally a semi-colon followed by any Ingres connect options.
Options must be given exactly as they would be given in an ESQL-connect statement, i.e., separated by blanks.
The connect call will result in a connect statement like:
CONNECT dbname IDENTIFIED BY user PASSWORD password OPTIONS=options
E.g.,
DBI->connect("DBI:Ingres:mydb", "me", "mypassword")with options and no password
DBI->connect("DBI:Ingres:mydb;-Rmyrole/myrolepassword", "me")Ingres/Net database
DBI->connect("DBI:Ingres:thatnode::thisdb;-xw -l", "him", "hispassword")
and so on.
Important: The DBI spec defines that AutoCommit is ON after connect. This is the opposite of the normal Ingres default.
It is recommended that the connect
call ends with the attributes
{ AutoCommit => 0 }
.
The DBI docs state that:
This is not the case for Ingres.
Data is returned as it would be to an embedded C program:
This does not cause loss of precision, because the Ingres API uses these types to return the data anyway.
This non-DBI method calls GET DBEVENT
and INQUIRE_INGRES
to
fetch a pending database event. If called without argument a blocking
GET DBEVENT WITH WAIT
is called. A numeric argument results in a
call to GET DBEVENT WITH WAIT= :seconds
.
In a second step
INQUIRE_INGRES
is called to fetch the related information, wich is
returned as a reference to a hash with keys name
, database
,
text
, owner
and time
. The values are the dbevent
* values
received from Ingres. If no event was fetched, undef
is returned.
See t/event.t for an example of usage.
$event_ref = $dbh->func(10, 'get_dbevent') # wait 10 secs at most $event_ref = $dbh->func('get_dbevent') # blocks
for (keys %$event_ref) { printf "%-20s = '%s'\n", $_, $event_ref->{$_}; }
$dbh->do is implemented as a call to 'EXECUTE IMMEDIATE' with all the limitations that this implies.
Placeholders and binding are not supported with $dbh->do
.
Fetching binary data from char and varchar fields is not guaranteed to work, but probably will most of the time. Use 'BYTE' or 'BYTE VARYING' data types in your database for full binary data support.
DBD::Ingres supports the LONG VARCHAR and LONG BYTE data types as detailed in DBI/``Handling BLOB / LONG / Memo Fields''.
The default value for LongReadLen in DBD::Ingres is 2GB, the maximum size of a long data type field. DBD::Ingres dynamically allocates memory for long data types as required, so setting LongReadLen to a large value does not waste memory.
In summary:
Due to their size (and hence the impracticality of copying them inside the DBD driver), variables bound as blob types are always evaluated at execute time rather than bind time. (Similar to bind_param_inout, except you don't pass them as references.)
Normally cursors are declared READONLY
to increase speed. READONLY cursors don't create
exclusive locks for all the rows selected; this is
the default.
If you need to update a row then you will need to ensure that either
select
statement contains an for update of
clause, or
the $dbh->prepare
calls includes the attribute {ing_readonly => 0}
.
E.g.,
$sth = $dbh->prepare("select ....", {ing_readonly => 0});
will be opened for update, as will
$sth = $dbh->prepare("select .... for direct update of ..")
while
$sth = $dbh->prepare("select .... for direct update of ..", { ing_readonly => 1} );
will be opened FOR READONLY
.
When you wish to actually do the update, where you would normally put the cursor name, you put:
$sth->{CursorName}
instead, for example:
$sth = $dbh->prepare("select a,b,c from t for update of b"); $sth->execute; $row = $sth->fetchrow_arrayref; $dbh->do("update t set b='1' where current of $sth->{CursorName}");
Later you can reexecute the statement without the update-possibility by doing:
$sth->{ing_readonly} = 1; $sth->execute;
and so on. Note that an update
will now cause an SQL error.
In fact the ``FOR UPDATE'' seems to be optional, i.e., you can update
cursors even if their SELECT statements do not contain a for update
part.
If you wish to update such a cursor you must include the ing_readonly
attribute.
NOTE DBD::Ingres version later than 0.19_1 have opened all cursors for update. This change breaks that behaviour. Sorry if this breaks your code.
The DBI docs state that 'Changing AutoCommit
from off to on will
trigger a commit
'.
Setting ing_rollback to on will change that to 'Changing AutoCommit
from off to on will trigger a rollback
'.
Default value is off.
This has long been deprecated in favor of $sth->{Statement}
,
which is a DBI standard.
$sth->{ing_statement} provides access to the SQL statement text.
$sth->{ing_types} (\@)
Returns an array of the ``perl''-type of the return fields of a select statement.
The types are represented as:
These values are returned as integers. This should not cause loss of precision as the internal Perl integer is at least 32 bit long.
These values are returned as floating-point numbers. This may cause loss of precision, but that would occur anyway whenever an application referred to the data (all Ingres tools fetch these values as floating-point numbers)
$sth->TYPE (\@)
See DBI for a description. The Ingres translations are:
Have I forgotten any?
$sth->{ing_lengths} (\@)
Returns an array containing the lengths of the fields in Ingres, eg. an
int2 will return 2, a varchar(7)
7 and so on.
Note that money and date fields will have length returned as 0.
$sth->{SqlLen}
is the same as $sth->{ing_lengths}
,
but the use of it is deprecated.
See also the $sth->{PRECISION}
field in the DBI docs. This returns
a 'reasonable' value for all types including money and date-fields.
$sth->{ing_sqltypes} (\@)
Returns an array containing the Ingres types of the fields. The types are given as documented in the Ingres SQL Reference Manual.
All values are positive as the nullability of the field is returned in
$sth->{NULLABLE}
.
See also the C$sth->{TYPE}> field in the DBI docs.
$h->state (undef)
SQLSTATE is not implemented.
Not implemented
DBD::Ingres should warn when a commit or rollback is isssued on a $dbh with open cursors.
Possibly a commit/rollback should also undef the $sth's. (This should probably be done in the DBI-layer as other drivers will have the same problems).
After a commit or rollback the cursors are all ->finish'ed, i.e., they are closed and the DBI/DBD will warn if an attempt is made to fetch from them.
A future version of DBD::Ingres wil possibly re-prepare the statement.
This is needed for
A new feature in DBI that is not implemented in DBD::Ingres.
It is possible to call database procedures from DBD::Ingres. It is NOT possible to get return values from the procedure.
A solution is underway for support for procedure calls from the DBI. Until that is defined procedure calls can be implemented as a DB::Ingres-specific function (like get_event) if the need arises and someone is willing to do it.
Some new features of OpenIngres are not (yet) supported in DBD::Ingres, including spatial datatypes.
Support will be added when the need arises - if you need it you add it ;-)
I wonder if I have forgotten something?
The DBI documentation in DBI and the DBI::DBD manpage.
DBI/DBD was developed by Tim Bunce, <Tim.Bunce@ig.co.uk>, who also developed the DBD::Oracle that is the closest we have to a generic DBD implementation.
Henrik Tougaard, <htoug@cpan.org> developed the DBD::Ingres extension.
DBD::Ingres - DBI driver for Ingres database systems |