=head1 NAME
DBD::ODBC::FAQ - Frequently Asked Questions for DBD::ODBC
=head1 SYNOPSIS
perldoc DBD::ODBC::FAQ
=head1 VERSION
($Revision: 11748 $)
=head1 QUESTIONS
=head2 How do I read more than N characters from a Memo | BLOB | LONG field?
See LongReadLen in the DBI docs.
Example:
$dbh->{LongReadLen} = 20000;
$sth = $dbh->prepare("select long_col from big_table");
$sth->execute;
etc
=head2 What is DBD::ODBC?
=head2 Why can't I connect?
=head2 Do I need an ODBC driver?
=head2 What is the ODBC driver manager?
These, general questions lead to needing definitions.
=over 4
=item ODBC Driver
The ODBC Driver is the driver that the ODBC manager uses to connect
and interact with the RDBMS. You B<DEFINITELY> need this to connect to
any database. For Win32, they are plentiful and installed with many
applications. For Linux/Unix, you can find a fairly comprehensive list
at L<http://www.unixodbc.org/drivers.html>.
=item ODBC Driver Manager
The ODBC driver manager is the interface between an ODBC application
(DBD::ODBC in this case) and the ODBC driver. The driver manager
principally provides the ODBC API so ODBC applications may link with a
single shared object (or dll) and be able to talk to a range of ODBC
drivers. At run time the application provides a connection string
which defines the ODBC data source it wants to connect to and this in
turn defines the ODBC driver which will handle this data source. The
driver manager loads the requested ODBC driver and passes all ODBC API
calls on to the driver. In this way, an ODBC application can be built
and distributed without knowing which ODBC driver it will be using.
However, this is a rather simplistic description of what the driver
manager does. The ODBC driver manager also:
* Controls a repository of installed ODBC drivers (on UNIX this is the
file odbcinst.ini).
* Controls a repository of defined ODBC data sources (on UNIX these are
the files odbc.ini and .odbc.ini).
* Provides the ODBC driver APIs (SQLGetPrivateProfileString and
SQLWritePrivateProfileString) to read and write ODBC data source
attributes.
* Handles ConfigDSN which the driver exports to configure data
sources.
* Provides APIs to install and uninstall drivers (SQLInstallDriver).
* Maps ODBC versions e.g. so an ODBC 2.0 application can work with an
ODBC 3.0 driver and vice versa.
* Maps ODBC states between different versions of ODBC.
* Provides a cursor library for drivers which only support
forward-only cursors.
* Provides SQLDataSources and SQLDrivers so an application can find
out what ODBC drivers are installed and what ODBC data sources are
defined.
* Provides an ODBC administrator which driver writers can use to
install ODBC drivers and users can use to define ODBC data sources.
The ODBC Driver Manager is the piece of software which interacts with
the drivers for the application. It "hides" some of the differences
between the drivers (i.e. if a function call is not supported by a
driver, it 'hides' that and informs the application that the call is
not supported. DBD::ODBC needs this to talk to drivers.
Under Win32, you usually get the ODBC Driver Manager as part of the
OS. Under Unix/Linux you may have to find and build the driver
manager yourself. The two main driver managers for Unix are unixODBC
(L<http://www.unixodbc.org>) and iODBC (L<http://www.iodbc.org>).
B<It is strongly advised you get an ODBC Driver Manager before trying to
build DBD::ODBC unless you intend linking DBD::ODBC directly with your
driver.>
For a reasonable description of ODBC on Unix/Linux see
L<http://www.easysoft.com/developer/interfaces/odbc/linux.html>
=item DBD::ODBC
DBD::ODBC uses the driver manager to talk to the ODBC driver(s) on
your system. You need both a driver manager and driver installed and
tested before working with DBD::ODBC. You need to have a DSN (see
below) configured and B<TESTED> before being able to test DBD::ODBC.
=item DSN (Data Source Name)
The DSN is a way of referring to a particular driver and database by
any name you wish. The DSN is usually a key to a list of attributes
the ODBC driver needs to connect to the database (e.g. ip address and
port) but there is always a key which names the driver so the driver
manager knows which driver to use with which data source. Do no
confuse DSNs with ODBC connection strings or DBI's "$data_source" (the
first argument to L<DBI/connect>.
The $data_source argument to DBI is composed of 'dbi:DRIVER:something_else'
where DRIVER is the name of the DBD driver you want to use (ODBC of
course for DBD::ODBC). The "something_else" for DBD::ODBC can be a DSN
name or it can be a normal ODBC connection string.
An ODBC connection string consists of attribute/value pairs separated
with semicolons (;). You can replace "something_else" above with a
normal ODBC connection string but as a special case for DBD::ODBC you can
just use the DSN name without the usual ODBC connection string prefix
of "DSN=dsn_name".
e.g.
=over
=item dbi:ODBC:DSN=fred
ODBC connection string using fred DSN
=item dbi:ODBC:fred
Same as above (a special case).
=item dbi:ODBC:Driver={blah blah driver};Host=1.2.3.4;Port=1000;
This is known as a DSN-less connection string for obvious reasons.
=back
=back
=head2 Where do I get an ODBC driver manager for Unix/Linux?
DBD::ODBC used to come bundled with a driver manager but this became
inconvenient when the driver manager was updated.
The two main ODBC Driver Managers for Unix are unixODBC (L<http://www.unixodbc/org>) and iODBC (L<http://www.iodbc.org>).
If you are running a packaged Linux like RedHat, Ubuntu, Fedora, Suse
etc etc you'll usually find it packaged with unixODBC and using the
package manager to install it is fairly straight forward. However,
make sure that if the driver manager is split into multiple packages
you install the development package as well as that contains the C
header files required by DBD::ODBC.
If you cannot find an ODBC Driver Manager package for your OS you can
download the source tar files for either of the driver managers above
and build it yourself.
=head2 How do I access a MS SQL Server database from Linux/UNIX?
You have loads of choices (in no particular order):
* using DBI::ProxyServer or DBD::Gofer. You'll need the former if you
use transactions.
* using a commercial ODBC Driver or bridge like the ones from Easysoft
or Openlink.
* using FreeTDS an open source TDS library which includes an ODBC Driver.
* using DBD::Sybase and Sybase libraries.
=head2 How do I access a MS-Access database from Linux?
There are basically two choices:
* a commercial ODBC Bridge like the ones from Easysoft or OpenLink.
* using mdbtools although as of writing it has not been updated since
June 2004, only provides read access and seems to be a little buggy.
=head2 Almost all of my tests for DBD::ODBC fail. They complain about not being able to connect or the DSN is not found.
Please, please test your configuration of ODBC and driver before
trying to test DBD::ODBC. Most of the time, this stems from the fact
that the DSN (or ODBC) is not configured properly. unixODBC comes with
a small program isql and iODBC comes with odbctest and you should use
these to test your ODBC configuration is working properly first.
=head2 I'm attempting to bind a Long Var char (or other specific type)
and the binding is not working.
The code I'm using is below:
$sth->bind_param(1, $str, $DBI::SQL_LONGVARCHAR);
^^^
The problem is that DBI::SQL_LONGVARCHAR is not the same as
$DBI::SQL_LONGVARCHAR and that $DBI::SQL_LONGVARCHAR is an error!
It should be:
$sth->bind_param(1, $str, DBI::SQL_LONGVARCHAR);
=head2 Does DBD::ODBC support Multiple Active Statements?
Multiple Active Statements (MAS) are concurrent statements created
from the same database handle which both have pending actions on them
(e.g. they both have executed a select statement but not retrieved all
the available rows yet).
DBD::ODBC does support MAS but whether you can actually use MAS is
down to the ODBC Driver.
By default MS SQL Server did not used to support multiple active
statements if any of them were select statements. You could get around
this (with caution) by changing to a dynamic cursor. There is a "hack"
in DBD::ODBC which can be used to enable MAS but you have to fully
understand the implications of doing so(see
L</DBD/ODBC/odbc_SQL_ROWSET_SIZE> and L</DBD/ODBC/odbc_cursortype>).
In MS SQL Server 2005, there is a new thing called MARS (Multiple
Active Result Sets) which allows multiple active select statements but
it has some nasty implications if you are also doing transactions. To
enable MARS from DBD::ODBC add "MARS_Connection=Yes" to the connection
string as in:
$h->DBI->connect('dbi:ODBC:DSN=mydsn;MARS_Connection=Yes;');
For other drivers it depends. I believe various Oracle ODBC drivers do
support multiple active statements as myodbc does.
Think carefully before using multiple active statements. It is
probably not portable and there is nearly always a better way of doing
it.
If anyone wants to report success with a particular driver and
multiple active statements I will collect them here.
=head2 Why do I get "Datetime field overflow" when attempting to insert a
date into Oracle?
If you are using the Oracle or Microsoft ODBC drivers then you may get
the following error when inserting dates into an Oracle database:
[Oracle][ODBC]Datetime field overflow. (SQL-22008)
If you do then check v$nls_parameters and v$parameter to see if you are
using a date format containing the RR format. e.g.,
select * from v$nls_parameters where parameter = 'NLS_DATE_FORMAT'
select * from v$parameter where name = 'nls_date_format'
If you see a date format like 'DD-MON-RR' (e.g., contains an RR) then
all I can suggest is you change the date format for your session as I
have never been able to bind a date using this format. You can do this
with:
alter session set nls_date_format='YYYY/MM/DD'
and use any format you like but keep away from 'RR'.
You can find some test code in the file examples/rtcpan_28821.pl which
demonstrates this problem. This was originally a rt.cpan issue which
can be found at L<http://rt.cpan.org/Ticket/Display.html?id=28821>.
As an aside, if anyone is reading this and can shed some light on the problem
I'd love to hear from you. The technical details are:
create table rtcpan28821 (a date)
insert into rtcpan28821 values('23-MAR-62') fails
Looking at the ODBC trace, SQLDescribeParam returns:
data type: 93, SQL_TYPE_TIMESTAMP
size: 19
decimal digits: 0
nullable: 1
and DBD::ODBC calls SQLBindParameter with:
ValueType: SQL_C_CHAR
ParameterType: SQL_TYPE_TIMESTAMP
ColumnSize: 9
DecimalDigits: 0
Data: 23-MAR-62
BufferLength: 9
=head2 Why do my SQL Server temporary objects disappear?
If you are creating temporary objects (e.g., temporary tables) in
SQL Server you find they have disappeared when you attempt to use
them. Temporary objects only have a lifetime of the session they
are created in but in addition, they cannot be created using
prepare/execute. e.g., the following fails:
$s = $h->prepare('select * into #tmp from mytable');
$s->execute;
$s = $h->selectall_arrayref('select * from #tmp');
with "Invalid object name '#tmp'". Your should read
L<http://technet.microsoft.com/en-US/library/ms131667.aspx> which
basically says I<Prepared statements cannot be used to create
temporary objects on SQL Server 2000 or later...>. The proper way to
avoid this is to use the C<do> method but if you cannot do that then
you need to add the L</odbc_exec_direct> attribute to your prepare as
follows:
my $s = $h->prepare('select * into #tmp from mytable',
{ odbc_exec_direct => 1});
See L</odbc_exec_direct>.
=head2 Why cannot I connect to my data source on Windows 64?
If you are running a 32bit Perl on a 64bit Windows machine you will
need to be aware there are two ODBC administrators and you need to
create your DSNs with the right one. The ODBC Administrator you get to
from Control Panel, Administrative Tools, Data Sources is the 64bit
one and data sources created here will not be visible or useable from
32bit applications. The ODBC administrator you need to use for 32bit
applications can be found at X:\windows\syswow64\odbcad32.exe.
=head2 How do I use DBD::ODBC with web servers under Win32.
=over 4
=item 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.
=item 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.
=item 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
B<service> user has permissions to access that file.
2) If the file is on a remote computer, check to make sure the Web
B<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
B<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.
=back
=head2 How do I connect without DSN
The ability to connect without a full DSN was 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";
=head1 AUTHOR
Parts of this document were written by Tim Bunce,
Jeff Urlwin and Martin J. Evans.
=head1 LICENSE
This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself, either Perl version 5.8.7 or,
at your option, any later version of Perl 5 you may have available.
=cut