DBD-Ingres
view release on metacpan or search on metacpan
received from Ingres. If no event was fetched, C<undef> is returned.
See F<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->{$_};
}
=head2 do
$dbh->do is implemented as a call to 'EXECUTE IMMEDIATE' with all the
limitations that this implies. An exception to that are the DML statements
C<INSERT>, C<DELETE> and C<UPDATE>. For them, a call to C<PREPARE> is
made, possible existing parameters are bound and a subsequent C<EXECUTE>
does the job. C<SELECT> isn't supported since $dbh->do doesn't give back
a statement handler hence no way to retrieve data.
=head2 Binary Data
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.
=head2 Long Data Types
DBD::Ingres supports the LONG VARCHAR and LONG BYTE data types
as detailed in L<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:
=over 4
=item *
When inserting blobs, use bind variables with types specified.
=item *
When fetching blobs, set LongReadLen and LongTruncOk in the $dbh.
=item *
Blob fields are returned as undef if LongReadLen is 0.
=back
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.)
=head2 ing_readonly
Normally cursors are declared C<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
=over 4
=item *
the C<select> statement contains an C<for update of> clause, or
= item *
the C<$dbh-E<gt>prepare> calls includes the attribute C<{ing_readonly =E<gt> 0}>.
=back
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 C<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. B<Note> that an C<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 C<for update>
part.
If you wish to update such a cursor you B<must> include the C<ing_readonly>
attribute.
B<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.
=head2 ing_rollback
The DBI docs state that 'Changing C<AutoCommit> from off to on will
trigger a C<commit>'.
Setting ing_rollback to B<on> will change that to 'Changing C<AutoCommit>
from off to on will trigger a C<rollback>'.
Default value is B<off>.
=head2 ing_statement
This has long been deprecated in favor of C<$sth-E<gt>{Statement}>,
which is a DBI standard.
$sth->{ing_statement} provides access to the SQL statement text.
=head2 ing_types
$sth->{ing_types} (\@)
Returns an array of the "perl"-type of the return fields of a select
statement.
The types are represented as:
=over 4
=item 'i': integer
All integer types, i.e., int1, int2 and int4.
These values are returned as integers. This should not cause loss of
precision as the internal Perl integer is at least 32 bit long.
=item 'f': float
The types float, float8 and money.
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)
=item 'l': long / blob
Either of the two long datatypes, long varchar or long byte.
=item 's': string
All other supported types, i.e., char, varchar, text, date etc.
=back
=head2 Ingres Types and their DBI Equivalents
$sth->TYPE (\@)
Have I forgotten any?
=head2 ing_lengths
$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.
C<$sth-E<gt>{SqlLen}> is the same as C<$sth-E<gt>{ing_lengths}>,
but the use of it is deprecated.
See also the C<$sth-E<gt>{PRECISION}> field in the DBI docs. This returns
a 'reasonable' value for all types including money and date-fields.
=head2 ing_sqltypes
$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
C<$sth-E<gt>{NULLABLE}>.
See also the C$sth-E<gt>{TYPE}> field in the DBI docs.
=head2 ing_ph_ingtypes
$sth->{ing_ph_ingtypes} (\@)
Returns an array containing the Ingres types of the columns the place-
holders represent. This is a guess from the context of the placeholder
in the prepared statement. Be aware, that the guess isn't always correct
and sometypes a zero (illegal) type is returned. Plus negative values
indicate nullability of the parameter. A C<$sth-E<gt>{ing_ph_nullable}>
field is to be implemented yet.
=head2 ing_ph_inglengths
$sth->{ing_ph_inglengths} (\@)
Returns an array containing the lengths of the placeholders analog to
the $sth->{ing_lengths} field.
=head1 FEATURES NOT IMPLEMENTED
=head2 state
$h->state (undef)
SQLSTATE is not implemented.
=head2 disconnect_all
Not implemented
=head2 commit and rollback invalidate open cursors
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
=head2 Cached statements
A new feature in DBI that is not implemented in DBD::Ingres.
=head2 bind_param_inout (Procedure calls)
It is possible to call database procedures from DBD::Ingres. It is B<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 L<get_event>) if the need arises and
someone is willing to do it.
=head1 NOTES
=head2 $dbh->(table|column|get)_info
The table_info and column_info functions are just working against tables.
Views and synonyms still have to be implemented. The get_info function
returns just the newer version strings correctly, since I'm still looking
for documentation for the older ones.
I wonder if I have forgotten something?
=head1 SEE ALSO
The DBI documentation in L<DBI> and L<DBI::DBD>.
=head1 AUTHORS
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.
Stefan Reddig, <sreagle@cpan.org> is currently (2008) adopting it to
include some more features.
=cut
( run in 1.063 second using v1.01-cache-2.11-cpan-5837b0d9d2c )