Why not adopt me?

This distribution is up for adoption! If you're interested then please contact the PAUSE module admins via email.

NAME

DBD::ODBC - ODBC Driver for DBI

SYNOPSIS

  use DBI;

  $dbh = DBI->connect('dbi:ODBC:DSN', 'user', 'password');

See DBI for more information.

DESCRIPTION

Change log and FAQs

Please note that the change log has been moved to DBD::ODBC::Changes.pm. To access this documentation, use perldoc DBD::ODBC::Changes.

The FAQs have also moved to DBD::ODBC::FAQ.pm. To access the FAQs use perldoc DBD::ODBC::FAQ.

Important note about the tests

Please note that some tests may fail or report they are unsupported on this platform. Notably Oracle's ODBC driver will fail the "advanced" binding tests in t/08bind2.t. These tests run perfectly under SQL Server 2000. This is normal and expected. Until Oracle fixes their drivers to do the right thing from an ODBC perspective, it's going to be tough to fix the issue. The workaround for Oracle is to bind date types with SQL_TIMESTAMP. Also note that some tests may be skipped, such as t/09multi.t, if your driver doesn't seem to support returning multiple result sets. This is normal.

Version Control

DBD::ODBC source code is under version control at svn.perl.org. If you would like to use the "bleeding" edge version, you can get the latest from svn.perl.org via Subversion version control. Note there is no guarantee that this version is any different than what you get from the tarball from CPAN, but it might be :)

You may read about Subversion at http://subversion.tigris.org

You can get a subversion client from there and check dbd-odbc out via:

   svn checkout http://svn.perl.org/modules/dbd-odbc/trunk <your directory name here>

Which will pull all the files from the subversion trunk to your specified directory. If you want to see what has changed since the last release of DBD::ODBC read the Changes file or use "svn log" to get a list of checked in changes.

Contributing

Please use Subversion (see above) to get the latest version of DBD::ODBC from the trunk and submit any patches against that.

Please, before submitting a patch:

   svn update
   <try and included a test which demonstrates the fix/change working>
   <test your patch>
   svn diff > describe_my_diffs.patch

and send the resulting file to me and cc the dbi-users@perl.org mailing list (if you are not a member - why not!).

Private attributes common to connection and statement handles

odbc_ignore_named_placeholders

Use this if you have special needs (such as Oracle triggers, etc) where :new or :name mean something special and are not just place holder names You must then use ? for binding parameters. Example:

 $dbh->{odbc_ignore_named_placeholders} = 1;
 $dbh->do("create trigger foo as if :new.x <> :old.x then ... etc");

Without this, DBD::ODBC will think :new and :old are placeholders for binding and get confused.

odbc_default_bind_type

This value defaults to 0.

Older versions of DBD::ODBC assumed that the binding type was 12 (SQL_VARCHAR). Newer versions default to 0, which means that DBD::ODBC will attempt to query the driver via SQLDescribeParam to determine the correct type. If the driver doesn't support SQLDescribeParam, then DBD::ODBC falls back to using SQL_VARCHAR as the default, unless overridden by bind_param().

odbc_force_rebind

This is to handle special cases, especially when using multiple result sets. Set this before execute to "force" DBD::ODBC to re-obtain the result set's number of columns and column types for each execute. Especially useful for calling stored procedures which may return different result sets each execute. The only performance penalty is during execute(), but I didn't want to incur that penalty for all circumstances. It is probably fairly rare that this occurs. This attribute will be automatically set when multiple result sets are triggered. Most people shouldn't have to worry about this.

odbc_async_exec

Allow asynchronous execution of queries. This causes a spin-loop (with a small "sleep") until the SQL is complete. This is useful, however, if you want the error handling and asynchronous messages (see the "odbc_err_handler" and t/20SQLServer.t for an example of this.

odbc_query_timeout

This allows you to change the ODBC query timeout (the ODBC statement attribute SQL_ATTR_QUERY_TIMEOUT). ODBC defines the query time out as the number of seconds to wait for a SQL statement to execute before returning to the application. A value of 0 (the default) means there is no time out. Do not confuse this with the ODBC attributes SQL_ATTR_LOGIN_TIMEOUT and SQL_ATTR_CONNECTION_TIMEOUT. Add

  { odbc_query_timeout => 30 }

to your connect, set on the dbh before creating a statement or explicitly set it on your statement handle. The odbc_query_timeout on a statement is inherited from the parent connection.

Note that internally DBD::ODBC only sets the query timeout if you set it explicitly and the default of 0 (no time out) is implemented by the ODBC driver and not DBD::ODBC.

Note that some ODBC drivers implement a maximum query timeout value and will limit time outs set above their maximum. You may see a warning if your time out is capped by the driver but there is currently no way to retrieve the capped value back from the driver.

Note that some drivers may not support this attribute.

See t/20SqlServer.t for an example.

Private connection attributes

odbc_err_handler

Allow errors to be handled by the application. A call-back function supplied by the application to handle or ignore messages.

The callback function receives three parameters: state (string), error (string) and the native error code (number).

If the error handler returns 0, the error is ignored, otherwise the error is passed through the normal DBI error handling.

This can also be used for procedures under MS SQL Server (Sybase too, probably) to obtain messages from system procedures such as DBCC. Check t/20SQLServer.t and t/10handler.t.

  $dbh->{RaiseError} = 1;
  sub err_handler {
     ($state, $msg, $native) = @_;
     if ($state = '12345')
         return 0; # ignore this error
     else
         return 1; # propagate error
  }
  $dbh->{odbc_err_handler} = \$err_handler;
  # do something to cause an error
  $dbh->{odbc_err_handler} = undef; # cancel the handler

odbc_SQL_ROWSET_SIZE

Here is the information from the original patch, however, I've learned since from other sources that this could/has caused SQL Server to "lock up". Please use at your own risk!

SQL_ROWSET_SIZE attribute patch from Andrew Brown > There are only 2 additional lines allowing for the setting of > SQL_ROWSET_SIZE as db handle option. > > The purpose to my madness is simple. SqlServer (7 anyway) by default > supports only one select statement at once (using std ODBC cursors). > According to the SqlServer documentation you can alter the default setting > of > three values to force the use of server cursors - in which case multiple > selects are possible. > > The code change allows for: > $dbh->{SQL_ROWSET_SIZE} = 2; # Any value > 1 > > For this very purpose. > > The setting of SQL_ROWSET_SIZE only affects the extended fetch command as > far as I can work out and thus setting this option shouldn't affect > DBD::ODBC operations directly in any way. > > Andrew >

odbc_exec_direct

Force DBD::ODBC to use SQLExecDirect instead of SQLPrepare/SQLExecute.

There are drivers that only support SQLExecDirect and the DBD::ODBC do() override does not allow returning result sets. Therefore, the way to do this now is to set the attribute odbc_exec_direct.

NOTE: You may also want to use this option if you are creating temporary objects (e.g., tables) in MS SQL Server and for some reason cannot use the do method. see http://technet.microsoft.com/en-US/library/ms131667.aspx which says Prepared statements cannot be used to create temporary objects on SQL Server 2000 or later.... Without odbc_exec_direct, the temporary object will disappear before you can use it.

There are currently two ways to get this:

    $dbh->prepare($sql, { odbc_exec_direct => 1});

and

    $dbh->{odbc_exec_direct} = 1;

SQL_DRIVER_ODBC_VER

This, while available via get_info() is captured here. I may get rid of this as I only used it for debugging purposes.

odbc_cursortype

This allows multiple concurrent statements on SQL*Server. In your connect, add

  { odbc_cursortype => 2 }.

If you are using DBI > 1.41, you should also be able to use

 { odbc_cursortype => DBI::SQL_CURSOR_DYNAMIC }

instead. For example:

    my $dbh = DBI->connect("dbi:ODBC:$DSN", $user, $pass,
                  { RaiseError => 1, odbc_cursortype => 2});
    my $sth = $dbh->prepare("one statement");
    my $sth2 = $dbh->prepare("two statement");
    $sth->execute;
    my @row;
    while (@row = $sth->fetchrow_array) {
       $sth2->execute($row[0]);
    }

See t/20SqlServer.t for an example.

odbc_has_unicode

A read-only attribute signifying whether DBD::ODBC was built with the C macro WITH_UNICODE or not. A value of 1 indicates DBD::ODBC was built with WITH_UNICODE else the value returned is 0.

Building WITH_UNICODE affects columns and parameters which are SQL_C_WCHAR, SQL_WCHAR, SQL_WVARCHAR, and SQL_WLONGVARCHAR.

When odbc_has_unicode is 1, DBD::ODBC will:

bind columns the database declares as wide characters as SQL_Wxxx: This means that UNICODE data stored in these columns will be returned to Perl in UTF-8 and with the UTF8 flag set.
bind parameters the database declares as wide characters as SQL_Wxxx: Parameters bound where the database declares the parameter as being a wide character (or where the parameter type is explicitly set to a wide type - SQL_Wxxx) can be UTF8 in Perl and will be mapped to UTF16 before passing to the driver.

NOTE: You will need at least Perl 5.8.1 to use UNICODE with DBD::ODBC.

NOTE: At this time SQL statements are still treated as native encoding i.e. DBD::ODBC does not call SQLPrepareW with UNICODE strings. If you need a unicode constant in an SQL statement, you have to pass it as parameter or use SQL functions to convert your constant from native encoding to Unicode.

NOTE: Binding of unicode output parameters is coded but untested.

NOTE: When building DBD::ODBC on Windows ($^O eq 'MSWin32') the WITH_UNICODE macro is automatically added. To disable specify -nou as an argument to Makefile.PL (e.g. nmake Makefile.PL -nou). On non-Windows platforms the WITH_UNICODE macro is not enabled by default and to enable you need to specify the -u argument to Makefile.PL. Please bare in mind that some ODBC drivers do not support SQL_Wxxx columns or parameters.

NOTE: Unicode support on Windows 64 bit platforms is currently untested. Let me know how you get on with it.

UNICODE support in ODBC Drivers differs considerably. Please read the README.unicode file for further details.

odbc_version

This was added prior to the move to ODBC 3.x to allow the caller to "force" ODBC 3.0 compatibility. It's probably not as useful now, but it allowed get_info and get_type_info to return correct/updated information that ODBC 2.x didn't permit/provide. Since DBD::ODBC is now 3.x, this can be used to force 2.x behavior via something like: my

  $dbh = DBI->connect("dbi:ODBC:$DSN", $user, $pass,
                      { odbc_version =>2});

Private statement attributes

odbc_more_results

Use this attribute to determine if there are more result sets available. SQL Server supports this feature. Use this as follows:

do { my @row; while (@row = $sth->fetchrow_array()) { # do stuff here } } while ($sth->{odbc_more_results});

Note that with multiple result sets and output parameters (i.e. using bind_param_inout, don't expect output parameters to be bound until ALL result sets have been retrieved.

Private DBD::ODBC Functions

You use DBD::ODBC private functions like this:

  $dbh->func(arg, private_function_name);

GetInfo

This private function is now superceded by DBI's get_info method.

This function maps to the ODBC SQLGetInfo call and the argument should be a valid ODBC information type (see ODBC specification). e.g.

  $value = $dbh->func(6, 'GetInfo');

which returns the SQL_DRIVER_NAME.

This function returns a scalar value, which can be a numeric or string value depending on the information value requested.

SQLGetTypeInfo

This private function is now superceded by DBI's type_info and type_info_all methods.

This function maps to the ODBC SQLGetTypeInfo API and the argument should be a SQL type number (e.g. SQL_VARCHAR) or SQL_ALL_TYPES. SQLGetTypeInfo returns information about a data type supported by the data source.

e.g.

  use DBI qw(:sql_types);

  $sth = $dbh->func(SQL_ALL_TYPES, GetTypeInfo);
  DBI::dump_results($sth);

This function returns a DBI statement handle for the SQLGetTypeInfo result-set containing many columns of type attributes (see ODBC specification).

NOTE: It is VERY important that the use DBI includes the qw(:sql_types) so that values like SQL_VARCHAR are correctly interpreted. This "imports" the sql type names into the program's name space. A very common mistake is to forget the qw(:sql_types) and obtain strange results.

GetFunctions

This function maps to the ODBC SQLGetFunctions API which returns information on whether a function is supported by the ODBC driver.

The argument should be SQL_API_ALL_FUNCTIONS (0) for all functions or a valid ODBC function number (e.g. SQL_API_SQLDESCRIBEPARAM which is 58). See ODBC specification or examine your sqlext.h and sql.h header files for all the SQL_API_XXX macros.

If called with SQL_API_ALL_FUNCTIONS (0), then a 100 element array is returned where each element will contain a '1' if the ODBC function with that SQL_API_XXX index is supported or '' if it is not.

If called with a specific SQL_API_XXX value for a single function it will return true if the ODBC driver supports that function, otherwise false.

e.g.

    my @x = $dbh->func(0,"GetFunctions");
    print "SQLDescribeParam is supported\n" if ($x[58]);

    print "SQLDescribeParam is supported\n"
        if $dbh->func(58, "GetFunctions");

GetStatistics

This private function is now superceded by DBI's statistics_info method.

See the ODBC specification for the SQLStatistics API. You call SQLStatistics like this:

  $dbh->func($catalog, $schema, $table, $unique, 'GetStatistics');

Prior to DBD::ODBC 1.16 $unique was not defined as being true/false or SQL_INDEX_UNIQUE/SQL_INDEX_ALL. In fact, whatever value you provided for $unique was passed through to the ODBC API SQLStatistics call unchanged. This changed in 1.16, where $unique became a true/false value which is interpreted into SQL_INDEX_UNIQUE for true and SQL_INDEX_ALL for false.

GetForeignKeys

This private function is now superceded by DBI's foreign_key_info method.

See the ODBC specification for the SQLForeignKeys API. You call SQLForeignKeys like this:

  $dbh->func($pcatalog, $pschema, $ptable,
             $fcatalog, $fschema, $ftable,
             "GetForeignKeys");

GetPrimaryKeys

This private function is now superceded by DBI's primary_key_info method.

See the ODBC specification for the SQLPrimaryKeys API. You call SQLPrimaryKeys like this:

  $dbh->func($catalog, $schema, $table, "GetPrimaryKeys");

data_sources

This private function is now superceded by DBI's data_sources method.

You call data_sources like this:

  @dsns = $dbh->func("data_sources);

Handled since 0.21.

GetSpecialColumns

See the ODBC specification for the SQLSpecialColumns API. You call SQLSpecialColumns like this:

  $dbh->func($identifier, $catalog, $schema, $table, $scope,
             $nullable, 'GetSpecialColumns');

Handled as of version 0.28

head3 ColAttributes

This private function is now superceded by DBI's statement attributes NAME, TYPE, PRECISION, SCLARE, NULLABLE etc).

See the ODBC specification for the SQLColAttributes API. You call SQLColAttributes like this:

  $dbh->func($column, $ftype, "ColAttributes");

head3 DescribeCol

This private function is now superceded by DBI's statement attributes NAME, TYPE, PRECISION, SCLARE, NULLABLE etc).

See the ODBC specification for the SQLDescribeCol API. You call SQLDescribeCol like this:

  @info = $dbh->func($column, "DescribeCol");

The returned array contains the column attributes in the order described in the ODBC specification for SQLDescribeCol.

Tracing

DBD::ODBC now supports the parse_trace_flag and parse_trace_flags methods introduced in DBI 1.42 (see DBI for a full description). As of DBI 1.604, the only trace flag defined which is relevant to DBD::ODBC is 'SQL' which DBD::ODBC supports by outputting the SQL strings (after modification) passed to the prepare and do methods.

Currently DBD::ODBC only supports one private trace flag. The 'odbcdev' trace flag is used to output development tracing so it should not be relevant in normal use.

To enable tracing of particular flags you use:

  $h->trace($h->parse_trace_flags('SQL|odbcdev'));
  $h->trace($h->parse_trace_flags('1|odbcdev'));

In the first case 'SQL' and 'odbcdev' tracing is enabled on $h. In the second case trace level 1 is set and 'odbcdev' tracing is enabled.

If you want to enable a DBD::ODBC private trace flag before connecting you need to do something like:

  use DBD::ODBC;
  DBI->trace(DBD::ODBC->parse_trace_flag('odbcdev');

DBD::ODBC outputs tracing at levels 3 and above (as levels 1 and 2 are reserved for DBI).

Deviations from the DBI specification

Mixed placeholder types

There are 3 conventions for place holders in DBI. These are '?', ':N' and ':name' (where 'N' is a number and 'name' is an alpha numeric string not beginning with a number). DBD::ODBC supports all these methods for naming placeholders but you must only use one method throughout a particular SQL string. If you mix placeholder methods you will get an error like:

  Can't mix placeholder styles (1/2)

Using the same placeholder more than once

DBD::ODBC does not support (currently) the use of one placeholder more than once in the a single SQL string. i.e.,

  insert into foo values (:bar, :p1, :p2, :bar);

is not supported because 'bar' is used more than once but:

  insert into foo values(:bar, :p1, :p2)

is ok. If you do the former you will get an error like:

  DBD::ODBC does not yet support binding a named parameter more than once

Binding named placeholders

Although the DBI documentation (as of 1.604) does not say how named parameters are bound Tim Bunce has said that in Oracle they are bound with the leading ':' as part of the name and that has always been the case. i.e.,

  prepare("insert into mytable values (:fred)");
  bind_param(":foo", 1);

DBD::ODBC does not support binding named parameters with the ':' introducer. In the above example you must use:

  bind_param("foo", 1);

In discussion on the dbi-dev list is was suggested that the ':' could be made optional and there were no basic objections but it has not made it's way into the pod yet.

Others/todo?

Level 1

    SQLTables (use tables()) call

Level 2

    SQLColumnPrivileges
    SQLProcedureColumns
    SQLProcedures
    SQLTablePrivileges
    SQLDrivers
    SQLNativeSql

Connect without DSN

The ability to connect without a full DSN is introduced in version 0.21.

Example (using MS Access): my $DSN = 'driver=Microsoft Access Driver (*.mdb);dbq=\\\\cheese\\g$\\perltest.mdb'; my $dbh = DBI->connect("dbi:ODBC:$DSN", '','') or die "$DBI::errstr\n";

Using DBD::ODBC with web servers under Win32.

General Commentary re web database access

This should be a DBI faq, actually, but this has somewhat of an Win32/ODBC twist to it.

Typically, the Web server is installed as an NT service or a Windows 95/98 service. This typically means that the web server itself does not have the same environment and permissions the web developer does. This situation, of course, can and does apply to Unix web servers. Under Win32, however, the problems are usually slightly different.

Defining your DSN -- which type should I use?

Under Win32 take care to define your DSN as a system DSN, not as a user DSN. The system DSN is a "global" one, while the user is local to a user. Typically, as stated above, the web server is "logged in" as a different user than the web developer. This helps cause the situation where someone asks why a script succeeds from the command line, but fails when called from the web server.

Defining your DSN -- careful selection of the file itself is important!

For file based drivers, rather than client server drivers, the file path is VERY important. There are a few things to keep in mind. This applies to, for example, MS Access databases.

1) If the file is on an NTFS partition, check to make sure that the Web service user has permissions to access that file.

2) If the file is on a remote computer, check to make sure the Web service user has permissions to access the file.

3) If the file is on a remote computer, try using a UNC path the file, rather than a X:\ notation. This can be VERY important as services don't quite get the same access permissions to the mapped drive letters and, more importantly, the drive letters themselves are GLOBAL to the machine. That means that if the service tries to access Z:, the Z: it gets can depend upon the user who is logged into the machine at the time. (I've tested this while I was developing a service -- it's ugly and worth avoiding at all costs).

Unfortunately, the Access ODBC driver that I have does not allow one to specify the UNC path, only the X:\ notation. There is at least one way around that. The simplest is probably to use Regedit and go to (assuming it's a system DSN, of course) HKEY_LOCAL_USERS\SOFTWARE\ODBC\"YOUR DSN" You will see a few settings which are typically driver specific. The important value to change for the Access driver, for example, is the DBQ value. That's actually the file name of the Access database.

Connect without DSN

The ability to connect without a full DSN is introduced in version 0.21.

Example (using MS Access): my $DSN = 'driver=Microsoft Access Driver (*.mdb);dbq=\\\\cheese\\g$\\perltest.mdb'; my $dbh = DBI->connect("dbi:ODBC:$DSN", '','') or die "$DBI::errstr\n";

The above sample uses Microsoft's UNC naming convention to point to the MSAccess file (\\\\cheese\\g$\\perltest.mdb). The dbq parameter tells the access driver which file to use for the database.

Example (using MSSQL Server): my $DSN = 'driver={SQL Server};Server=server_name; database=database_name;uid=user;pwd=password;'; my $dbh = DBI->connect("dbi:ODBC:$DSN") or die "$DBI::errstr\n";