| DBD::ODBC - ODBC Driver for DBI |
DBD::ODBC - ODBC Driver for DBI
use DBI;
$dbh = DBI->connect('dbi:ODBC:DSN', 'user', 'password');
See DBI for more information.
Please note that the change log has been moved to DBD::ODBC::Changes.pm To easily access this documentation, use perldoc DBD::ODBC::Changes
Also, while this document documents features, etc, I'm really trying to keep the FAQ type questions answered in the DBI FAQ itself... DBI FAQ (http://www.xmlproj.com/cgi/fom.cgi) =item B<An 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.
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.
Without this, DBD::ODBC will think :new and :old are placeholders for binding and get confused.
=item 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()
SQLPrepare() then SQLExecute.
There are drivers that only support SQLExecDirect and the DBD::ODBC
do() override doesn't allow returning result sets. Therefore, the
way to do this now is to set the attributed odbc_exec_direct.
There are currently two ways to get this:
$dbh->prepare($sql, { odbc_execdirect => 1});
and
$dbh->{odbc_execdirect} = 1;
When $dbh->prepare() is called with the attribute ``ExecDirect'' set to a non-zero value
dbd_st_prepare do NOT call SQLPrepare, but set the sth flag odbc_exec_direct to 1.
=item odbc_err_handler
Allow errors to be handled by the application. A call-back function supplied by the application to handle or ignore messages. If the error handler returns 0, the error is ignored, otherwise the error is passed through the normal DBI error handling structure(s).
=item 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
>
get_info() is captured here. I may get rid of this
as I only used it for debugging purposes.
=item 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});
=item B<Private DBD::ODBC Functions>
$value = $dbh->func(6, GetInfo);
This function returns a scalar value, which can be a numeric or string value. This depends upon the argument passed to GetInfo.
use DBI qw(:sql_types);
$sth = $dbh->func(SQL_ALL_TYPES, GetInfo);
while (@row = $sth->fetch_row) {
...
}
This function returns a DBI statement handle, which represents a result
set containing type names which are compatible with the requested
type. SQL_ALL_TYPES can be used for obtaining all the types the ODBC
driver supports. 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.
Use the DBI statement handle attributes NAME, NULLABLE, TYPE, PRECISION and SCALE, unless you have a specific reason.
| 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''; |
=item SQLPrimaryKeys
See DBI's get_primary_keys
=item SQLDataSources
Handled, currently (as of 0.21), also see DBI's data_sources()
=item Others/todo?
Level 1
SQLTables (use tables()) call
Level 2
SQLColumnPrivileges
SQLProcedureColumns
SQLProcedures
SQLTablePrivileges
SQLDrivers
SQLNativeSql
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.
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.
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";
These are in need of sorting and annotating. Some are relevant only to ODBC developers (but I don't want to loose them).
http://www.ids.net/~bjepson/freeODBC/index.html
http://dataramp.com/
http://www.syware.com
http://www.microsoft.com/odbc
For Linux/Unix folks, compatible ODBC driver managers can be found at:
http://www.easysoft.com unixODBC driver manager source
*and* ODBC-ODBC bridge for accessing Win32 ODBC sources from Linux
http://www.iodbc.org iODBC driver manager source
For Linux/Unix folks, you can checkout the following for another ODBC-ODBC bridge and support for iODBC.
http://www.openlink.co.uk
or
http://www.openlinksw.com
And another:
OpenRDA
http://www.atinet.com/support/openrda_samples.asp
| Example: | |
| $dbh->{LongReadLen} = 20000; | |
| $sth = $dbh->prepare(``select long_col from big_table''); | |
| $sth->execute; | |
| etc |
1) ODBC Driver - the driver that the ODBC manager uses to connect and interact with the RDBMS. You DEFINITELY need this to connect to any database. For Win32, they are plentiful and installed with many applications. For Linux/Unix, some hunting is required, but you may find something useful at:
http://www.openlinksw.com
http://www.easysoft.com
http://www.intersolv.com
http://www.atinet.com/support/openrda_samples.asp
2) ODBC Driver Manager - 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, it is built in to the OS. Under Unix/Linux, in most cases, you will want to use freeODBC, unixODBC or iODBC. iODBC was bundled with DBD::ODBC, but you will need to find one which suits your needs. Please see www.openlinksw.com, www.easysoft.com or www.iodbc.org
3) 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* TESTED before being able to test DBD::ODBC.
4) DSN -- Data Source Name. It's a way of referring to a particular database by any name you wish. The name itself can be configured to hide the gory details of which type of driver you need and the connection information you need to provide. For example, for some databases, you need to provide a TCP address and port. You can configure the DSN to have use information when you refer to the DSN.
If someone does have more information, please, please send it to me and I will put it in this FAQ.
$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);
| DBD::ODBC - ODBC Driver for DBI |