view release on metacpan or  search on metacpan

Firebird.pm  view on Meta::CPAN

=item * DESCRIBE

Provides information about columns that are retrieved by a DSQL statement,
or about placeholders in a statement. This functionality is supported by the
driver, and transparent for users. Column names are available via
$sth->{NAME} attributes.

=item * EXECUTE IMMEDIATE

Calling do() method without bind value(s) will do the same.

 view release on metacpan or  search on metacpan

Illustra.pm  view on Meta::CPAN

    }

Due to the limitations in the Illustra API, it is not
possible to support reading large objects from each row, as they are fetched.
This means that future versions of DBD::Illustra will never be able to
transparently return large objects with normal column data. However, you can
cast large object values to large_text, in which case they will be returned
as normal values.

=head1 AUTHOR

 view release on metacpan or  search on metacpan

InterBase.pm  view on Meta::CPAN

=item * DESCRIBE

Provides information about columns that are retrieved by a DSQL statement,
or about placeholders in a statement. This functionality is supported by the
driver, and transparent for users. Column names are available via
$sth->{NAME} attributes.

=item * EXECUTE IMMEDIATE

Calling do() method without bind value(s) will do the same.

 view release on metacpan or  search on metacpan

lib/DBD/Multi.pm  view on Meta::CPAN

=head1 DESCRIPTION

This software manages multiple database connections for failovers and also
simple load balancing.  It acts as a proxy between your code and your database
connections, transparently choosing a connection for each query, based on your
preferences and present availability of the DB server.

This module is intended for read-only operations (where some other application
is being used to handle replication).

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

  to ODBC 2.0 drivers (why are you still using ODBC 2.0 drivers?).
  From now on DBD::ODBC needs to be linked with an ODBC Driver Manager
  and I recommend unixODBC on UNIX and the MS ODBC Driver Manager
  on Windows. There are really good reasons for this but mainly it
  is because an ODBC Driver Manager will map ODBC 2.0 calls to an
  ODBC 3.0 driver and vice versa and handle UNICODE transparently.

  Bumped Test::Simple requirement up to 0.90 so we can use done_testing
  and note.

  Bump Perl requirement to 5.8 as per DBI.

 view release on metacpan or  search on metacpan

lib/DBD/Oracle.pm  view on Meta::CPAN

When fetching LOBs with this interface a 'LOB Locator' is created then used to get the lob with the LongReadLen and LongTruncOk attributes.
The value for 'LongReadLen' is dependent on the version and settings of the Oracle DB you are using. In theory it ranges from 8GBs
in 9iR1 up to 128 terabytes with 11g but you will also be limited by the physical memory of your PERL instance.

When inserting or updating LOBs some I<major> magic has to be performed
behind the scenes to make it transparent.  Basically the driver has to
insert a 'LOB Locator' and then refetch the newly inserted LOB
Locator before being able to write the data into it.  However, it works
well most of the time, and I've made it as fast as possible, just one
extra server-round-trip per insert or update after the first.  For the
time being, only single-row LOB updates are supported.

 view release on metacpan or  search on metacpan

debian/changelog  view on Meta::CPAN

 -- Rainer Weikusat <rweikusat@talktalk.net>  Thu, 03 Jul 2025 10:37:59 +0100

libdbd-pg-async-perl (0.5) unstable; urgency=medium

  * make dbh cancel method work in face of asychronous operations
    transparently issued by the driver

 -- Rainer Weikusat <rweikusat@talktalk.net>  Thu, 03 Jul 2025 10:00:53 +0100

libdbd-pg-async-perl (0.4.2) unstable; urgency=medium

  * fixed pg_db_result to work as documented in face of asychronous
    statements transparently issued by the driver

 -- Rainer Weikusat <rweikusat@talktalk.net>  Thu, 26 Jun 2025 19:16:47 +0100

libdbd-pg-async-perl (0.4.1) unstable; urgency=medium

 view release on metacpan or  search on metacpan

lib/DBD/PgLite.pm  view on Meta::CPAN

  my $get_nid = "SELECT NEXTVAL('news_news_id_seq')";
  my $news_id = $dbh->selectrow_array($get_nid);

=head1 DESCRIPTION

The module automatically and transparently transforms a broad range of
SQL statements typical of PostgreSQL into a form suitable for use in
SQLite. This involves both (a) parsing and filtering of the SQL; and
(b) the addition of several PostgreSQL-compatible functions to SQLite.

Mainly because of datatype issues, support for many PostgreSQL

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

1.12
	- Brought up to date with SQLite 3.3.5

1.11
    - Make blobs work transparently (without SQLBLOB binding)

1.10
    - Fix Unicode support (DOMQ)
    - Support usleep on all Linux (inc. debian) (DOMQ)
    - Upgrade to sqlite 3.2.7

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

1.12
	- Brought up to date with SQLite 3.3.5

1.11
    - Make blobs work transparently (without SQLBLOB binding)

1.10
    - Fix Unicode support (DOMQ)
    - Support usleep on all Linux (inc. debian) (DOMQ)
    - Upgrade to sqlite 3.2.7

 view release on metacpan or  search on metacpan

lib/DBD/SQLite2.pm  view on Meta::CPAN

Returns either "UTF-8" or "iso8859" to indicate how the SQLite library was compiled.

=item sqlite_handle_binary_nulls

Set this attribute to 1 to transparently handle binary nulls in quoted
and returned data.

B<NOTE:> This will cause all backslash characters (C<\>) to be doubled
up in all columns regardless of whether or not they contain binary
data or not. This may break your database if you use it from another

 view release on metacpan or  search on metacpan

lib/DBD/Safe.pm  view on Meta::CPAN

database. If you are going to use DBIx::Connector you must explicitly call
C<< $conn->dbh >> to get a real dbh connection. And if you want to add some fault tolerance
in a tons of existed code, you must refactor all this code where you use database
connections.

DBD::Safe has a transparent interface. You just need to replace C<connect()> options
and after this you can use it as usual database handler.

=head1 METHODS

=over

lib/DBD/Safe.pm  view on Meta::CPAN

=head1 BUGS AND CAVEATS

Connection is checked on each query. This can double your request execution time if all your requests are fast and network latency of your database is big enough.

Statement objects are not safe. Once you've prepared the statement, it won't reconnect to the database transparently.

There are no retries. If the request fails, it fails. This module just check that DB is alive *before* it tries to execute the statement. (Custom, per-query policies support is planned for the future releases).

=head1 SEE ALSO

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

       	  Recent versions used to set $xxx->err to -1 independent 
	  of the error returned by Solid.
	* SELECT statements not longer require a finish() between 
	  execute() of the same sth.
        * All binary columns (including BINARY and VARBINARY
	  types) may be used from perl in a transparent fashion.
        * ping() not raising error even if RaiseError is set.
        * DBD::Solid::Const not longer used inside Solid.pm 
	  due to problems with mod_perl/embperl. SQL type values 
	  are included in recent DBI modules.
	* tests use now DBI_DSN/DBI_USER/DBI_PASS env vars.

 view release on metacpan or  search on metacpan

lib/XBase.pm  view on Meta::CPAN

1/1000 s). To get the fields, use the gmtime (or similar) Perl function.

If there is a memo field in the dbf file, the module tries to open
file with the same name but extension dbt, fpt or smt. It uses module
XBase::Memo(3) for this. It reads and writes this memo field
transparently (you do not know about it) and returns the data as
single scalar.

=head1 INDEX, LOCKS

B<New:> A support for ndx, ntx, mdx, idx and cdx index formats is

 view release on metacpan or  search on metacpan

lib/DBI/BabyConnect.pm  view on Meta::CPAN

fails, by calling finish on the cursor, and by disconnecting the handle.

However DBI::BabyConnect objects are designed to be persisted and to be pooled
within an application. Programmers, 
do not need to call any of the functions aforementioned because 
DBI::BabyConnect will do that transparently for you. You use DBI::BabyConnect so that
you can work with an object whose connection is persisted to a data source, and
the object will do all clean up upon object destruction.

The following functions are provided so that if you chose to port an application that
uses DBI directly, you can easily make use of DBI::BabyConnect without making extensive changes

 view release on metacpan or  search on metacpan

README.md  view on Meta::CPAN

[![Build Status](https://travis-ci.org/perl5-dbi/DBI-Test.png?branch=master)](https://travis-ci.org/perl5-dbi/DBI-Test)

## Description

This module aims at a transparent test suite for the DBI API
to be used from both sides of the API (DBI and DBD) to check
if the provided functionality is working and complete.

## Copying

 view release on metacpan or  search on metacpan

lib/DBD/Gofer.pm  view on Meta::CPAN

=head1 DESCRIPTION

DBD::Gofer is a DBI database driver that forwards requests to another DBI
driver, usually in a separate process, often on a separate machine. It tries to
be as transparent as possible so it appears that you are using the remote
driver directly.

DBD::Gofer is very similar to DBD::Proxy. The major difference is that with
DBD::Gofer no state is maintained on the remote end. That means every
request contains all the information needed to create the required state. (So,

lib/DBD/Gofer.pm  view on Meta::CPAN

The L<DBD::Gofer::Policy::Base> class is the base class for all the policy
packages and describes all the available policies.

Three policy packages are supplied with DBD::Gofer:

L<DBD::Gofer::Policy::pedantic> is most 'transparent' but slowest because it
makes more  round-trips to the Gofer server.

L<DBD::Gofer::Policy::classic> is a reasonable compromise - it's the default policy.

L<DBD::Gofer::Policy::rush> is fastest, but may require code changes in your applications.

 view release on metacpan or  search on metacpan

Browse.pm  view on Meta::CPAN

=head1 DESCRIPTION

The purpose of DBIx::Browse is to handle the browsing of relational
tables.

DBIx::Browse transparently translates SELECTs, UPDATEs, DELETEs and INSERTs
from the desired "human view" to the values needed for the table. This is the
case when you have related tables (1 to n) where the detail table
has a reference (FOREIGN KEY) to a generic table (i.e. Customers and
Bills) with some index (tipically an integer).

 view release on metacpan or  search on metacpan

lib/DBIx/BulkUtil.pm  view on Meta::CPAN

=head1 UTILITY OBJECT METHODS

Methods that may be called on the utility object that is optionally returned
from the connect or connect_cached DBIX::BulkUtil class methods. These methods
provide convenience and/or make some operations between Oracle and Sybase
databases more transparent.

=over 4

=item now

lib/DBIx/BulkUtil.pm  view on Meta::CPAN

you can pass in a cursor as an output parameter. When you pass in a
parameter ":cursor", we assume its an output parameter that will
hold a statement handle, so you can return a single result set in a
nearly "backwards compatible" way. But we don't handle "multiple" result
sets (yet), we don't deal with other output parameters, and so this
this method is not meant to be completely transparent for
all stored procedures.

=item sp_sth

Prepares and executes a stored procedure with arguments, and returns

 view release on metacpan or  search on metacpan

Chart.pm  view on Meta::CPAN

#
#	DBIx::Chart - subclass of DBI to transparently provide
#		charting capability
#
#	History:
#
#	2005-01-26		D. Arnold

 view release on metacpan or  search on metacpan

lib/DBIx/Class/FilterColumn/Encrypt.pm  view on Meta::CPAN

 # in application code
 $rs->create({ data => 'some secret' });

=head1 DESCRIPTION

This components transparently encrypts any value with the currently active key, or decrypts them with any known value. This is useful when needing read/write access to values that are too sensitive to store in plaintext, such as credentials for other...

To enable encryption, C<encrypt> must be a hash containing the key C<keys>, which shall be a hash mapping numberic identifiers to keys. An optional argument C<active_key> may be given which one will be used for encrypting, otherwise the key with the ...

=head1 AUTHOR

 view release on metacpan or  search on metacpan

lib/DBIx/Class/FrozenColumns.pm  view on Meta::CPAN

This module allows you to store multiple columns in one. This is useful when
you want to store dynamic number of columns in database or you just don't know
what columns will be stored there. Or when you can't (or don't want) to alter
your tables in database.

Module allows you to transparently use this columns as if they were normal
columns in your table. With one obvious restriction: you cannot search rows in a
table and therefore you cannot add relationships using these columns (search is
needed to build reverse relationship).

Module handles its own dirty column management and will not update the parent

 view release on metacpan or  search on metacpan

lib/DBIx/Class/Helper/Row/ProxyResultSetMethod.pm  view on Meta::CPAN

is the column that the data being retrieved is stored as in the ResultSet
method being proxied to.  C<$resultset_method> is (duh) the ResultSet method
being proxied to.

If you did not call the C<with_*> method on your ResultSet, and call the
proxy method, it will transparently B<fallback> and do the call and fetch
the needed data. E.g.:

 my $foo = $schema->resultset('Foo')->first; ## did not call with_friend_count
 print $foo->friend_count; ## will produce desired result magically

 view release on metacpan or  search on metacpan

lib/DBIx/Class/I18NColumns.pm  view on Meta::CPAN

=head1 DESCRIPTION

This module allows you to define columns that will store multiple values asociated to a language string and use it as normal columns. This is useful when you need to internationalize attributes of your DB entities.

This component will create a new resultset on your schema for each one that use it. The auto-created resultset will use the columns definition you give to add_i18n_columns() plus a FK and language columns. The i18n values of each language will reside...

Language will be propagated to relationships with result sources that also use this component.

=head1 METHODS

 view release on metacpan or  search on metacpan

lib/DBIx/Class/ResultSource/MultipleTableInheritance.pm  view on Meta::CPAN

        "flavor"
        "aroma"
        ..

Inherit from this package and you can make a resultset class from a view, but
that's more than a little bit misleading: the result is B<transparently
writable>.

This is accomplished through the use of stored procedures that map changes
written to the view to changes to the underlying concrete tables.

 view release on metacpan or  search on metacpan

lib/DBIx/Class/ResultSet.pm  view on Meta::CPAN

To create related objects, pass a hashref of related-object column values
B<keyed on the relationship name>. If the relationship is of type C<multi>
(L<DBIx::Class::Relationship/has_many>) - pass an arrayref of hashrefs.
The process will correctly identify columns holding foreign keys, and will
transparently populate them from the keys of the corresponding relation.
This can be applied recursively, and will work correctly for a structure
with an arbitrary depth and width, as long as the relationships actually
exists and the correct column data has been supplied.

Instead of hashrefs of plain related data (key/value pairs), you may

 view release on metacpan or  search on metacpan

lib/DBIx/DataModel/Doc/Design.pod  view on Meta::CPAN

L<class()|DBIx::DataModel::Doc::Reference/"Meta-source methods"> method
to retrieve the application subclass to which they are bound.

Metaclasses hold information about application classes,
and implement some of their methods. In most cases,
this is totally transparent to end users; however, users
can interact with metaclasses to get some information
about the available tables, associations, etc., or
even to change their behaviour.
The picture below shows relationships between application classes and
the meta-objects to which they are related (classes start with capital

lib/DBIx/DataModel/Doc/Design.pod  view on Meta::CPAN

the changed columns, then the final value of C<column1> or
C<column2> is unpredictable.

To diminish the efficiency problem, some ORMs offer the possibility
to partition columns into several I<column groups>. The ORM layer
then transparently fetches the appropriate groups in several steps,
depending on which columns are requested from the client. However,
this might be another source of inefficiency, if the client
frequently needs one column from the first group and one from the
second group.

lib/DBIx/DataModel/Doc/Design.pod  view on Meta::CPAN

which columns to transfer, because these can be specified separately at
each method call. Whenever efficiency is not an issue, one
can be lazy and specify nothing, in which case the SELECT columns will
default to "*". Actually, the schema
I<does not know about column names>, except for primary and
foreign keys, and therefore would be unable to transparently
decide which columns to retrieve. Consequently, objects from a
given class may be of I<variable size> :

  my $objs_A = My::Table->select(-columns => [qw/c1 c2/],
		 	         -where   => {name => {-like => "A%"}};

 view release on metacpan or  search on metacpan

lib/DBIx/DataStore.pm  view on Meta::CPAN

=over

=item Hash and Array accessors

Each time you retrieve a record (aka "result row") from a query's result set,
the values for each column in that record can be transparently accessed through
hash keys (where the keys are the column names as defined by the original query)
or array indices (in the order the columns were defined by the query).  Both
methods of accessing the record's values are available at all times (unlike the
standard DBI methods where you have to choose up front between using
C<fetchrow_array[ref]()> or C<fetchrow_hashref()>).  Thus, something like the

 view release on metacpan or  search on metacpan

lib/DBIx/EAV/ResultSet.pm  view on Meta::CPAN

To create related entities, pass a hashref of related-object attribute values
B<keyed on the relationship name>. If the relationship is of type C<has_many>
or C<many_to_many> - pass an arrayref of hashrefs.
The process will correctly identify the relationship type and side, and will
transparently populate the L<entitiy_relationships table>.
This can be applied recursively, and will work correctly for a structure
with an arbitrary depth and width, as long as the relationships actually
exists and the correct data has been supplied.

Instead of hashrefs of plain related data (key/value pairs), you may

 view release on metacpan or  search on metacpan

lib/DBIx/FullTextSearch.pm  view on Meta::CPAN

=item file

To index files, use the frontend B<file>. Here the content of the document
is clearly the content of the file specified by the filename, so in
a call to index_document, only the name is needed -- the content of the
file is read by the DBIx::FullTextSearch transparently:

	$fts->index_document('/usr/doc/FAQ/Linux-FAQ');
	my @files = $fts->contains('penguin');

=item url