The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.

NAME

DBD::Unify - DBI driver for Unify database systems

SYNOPSIS

    $dbh = DBI->connect ("DBI:Unify:[\$dbname]", "", $schema, {
                            AutoCommit => 0,
                            ChopBlanks => 1,
                            ScanLevel  => 2,
                            });
    $dbh->do ($statement);
    $dbh->commit ();
    $dbh->rollback ();
    $dbh->disconnect ();

    @row = $dbh->selectrow_array ($statement);

    $sth = $dbh->prepare ($statement);
    $sth->execute ();
    @row = $sth->fetchrow_array ();
    $sth->finish ();

    $sth = $dbh->prepare ($statement);  # W/ placeholders like where field = ?
    $sth->execute (3);
    @row = $sth->fetchrow_array ();
    $sth->finish ();
    ...

DESCRIPTION

DBD::Unify is an extension to Perl which allows access to Unify databases. It is built on top of the standard DBI extension an implements the methods that DBI require.

This document describes the differences between the "generic" DBD and DBD::Unify.

Extensions/Changes

returned types

The DBI docs state that:

    Most data is returned to the perl script as strings (null values are returned as undef). This allows arbitrary precision numeric data to be handled without loss of accuracy. Be aware that perl may not preserve the same accuracy when the string is used as a number.

This is not the case for Unify.

Data is returned as it would be to an embedded C program:

    Integers are returned as integer values (perl's IVs).

    (Huge) amounts, floats and doubles are returned as numeric values (perl's NVs).

    Chars are returned as strings (perl's PVs).

    Dates, varchars and others are returned as undef (for the moment).

connect
    connect ("DBI:Unify:dbname[;options]" [, user [, auth [, attr]]]);

Options to the connection are passed in the datasource argument. This argument should contain the database name possibly followed by a semicolon and the database options which are ignored.

Since Unify database authorisation is done using grant's using the user name, the <user> argument me be empty or undef. The auth field will be used as a default schema. If the auth field is empty or undefined connect will check for the environment variable $USCHEMA to use as a default schema. If neither exists, you will end up in your default schema, or if none is assigned, in the schema PUBLIC.

At the moment none of the attributes documented in DBI's "ATTRIBUTES COMMON TO ALL HANDLES" are implemented specifically for the Unify DBD driver, but they might have been inhereted from DBI. The ChopBlanks attribute is implemented, but defaults to 1 for DBD::Unify. The Unify driver supports "ScanLevel" to set the transaction scan level to a value between 1 and 16 and "DBDverbose" to set DBD specific debugging, allowing to show only massages from DBD-Unify without using the default DBI->trace () call.

The connect call will result in statements like:

    CONNECT;
    SET CURRENT SCHEMA TO PUBLIC;  -- if auth = "PUBLIC"
    SET TRANSACTION SCAN LEVEL 7;  -- if attr has { ScanLevel => 7 }
local database
       connect ("/data/db/unify/v63AB", "", "SYS")

and so on.

It is recommended that the connect call ends with the attributes { AutoCommit = 0 }>, although it is not implemented (yet).

If you dont want to check for errors after every call use { AutoCommit = 0, RaiseError => 1 }> instead. This will die with an error message if any DBI call fails.

do
    $dbh->do ($statement)

This is implemented as a call to 'EXECUTE IMMEDIATE' with all the limitations that this implies.

commit and rollback invalidates open cursors

DBD::Unify does 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, ie. they are closed and the DBI/DBD will warn if an attempt is made to fetch from them.

A future version of DBD::Unify might re-prepare the statement.

NOTES

Far from complete ...

SEE ALSO

The DBI documentation in DBI, other DBD documentation.

AUTHORS

DBI/DBD was developed by Tim Bunce, <Tim.Bunce@ig.co.uk>, who also developed the DBD::Oracle.

H.Merijn Brand, <h.m.brand@hccnet.nl> developed the DBD::Unify extension.