view release on metacpan or  search on metacpan

FAQ  view on Meta::CPAN

B<WSID> sets the workstation name recorded in the hostname column in
master.dbo.sysprocesses.

To set these add these attributes to the call to DBIs connect like this:

  my $h = DBI->connect('dbi:ODBC:DSN=mydsn;APP=appname;WSID=wsname',
                       'dbuser', 'dbpass');

=head2 Why do I get "The specified DSN contains an architecture mismatch between the Driver and Application" on Windows?

You've got a 64 bit Windows.

Your attempting to connect to a SYSTEM DSN.

You are trying to connect to a 64bit SYSTEM DSN from a 32 bit
application or vice versa. See my initial experience
http://www.martin-evans.me.uk/node/81.

More confusing is if you use the data_sources method, that calls
SQLDataSources and the list returned matches the architecture of your
Perl binary and yet when you attempt to connect to a DSN for the
wrong architecture you get this error instead of the more sensible
(and usual) data source not found.

NOTE: User DSNs don't exhibit this - they just seem to pick the right
driver.

See also http://www.easysoft.com/developer/interfaces/odbc/64-bit.html

=head2 Why does my transaction get committed when I disable AutoCommit?

If you are doing something like this:

  {local $h->{AutoCommit} = 0;
   $h->do(q/insert into mje values(1)/);
  }

then what really happens is AutoCommit is disabled at the start of the
block and when the block is exited AutoCommit is re-enabled. In ODBC
enabling AutoCommit will commit any outstanding transaction. Don't do
this. Instead, either rollback or commit at the end of the block or
leave AutoCommit alone and call begin_work/commit/rollback yourself in
the block.

=head2 Why do I get the wrong row count from execute_for_fetch?

Some drivers don't return the correct value from SQLRowCount when
binding arrays of parameters. e.g., freeTDS 8 and 0.91 seems to return
a 1 for each batch. e.g., if you run a SQL insert to insert 15 rows
and pass an array of 15 rows to execute_array with the default array
size of 10 it takes 2 batches to execute all the parameters and
freeTDS will return 1 row affected for each batch hence returns 2
instead of 15.

See rt 75687.

=head2 Why are my pound signs (£), dashes and quotes (and other characters) returned garbled

The first question in response is why do you think what you got back was incorrect? Did you print the data to a terminal and it looks wrong, or perhaps sent it to a browser in a piece of CGI or even wrote it to a file? The mantra you need to stick to...

The classic case I keep seeing I've repeated here because it illustrates the most common problem. Database is MS SQL Server, data is viewed in the management console and looks good but when retrieved via DBD::ODBC it looks wrong. The most common caus...

Bear in mind that in a unicode build of DBD::ODBC (the default on Windows) all string data is retrieved as unicode. When you output your unicode data anywhere you need to encode it with Encode::encode e.g.,

binmode(STDOUT, ":encoding(cp1252)");

Just because you think you are working in a single codepage does not mean the data you retrieve will be returned as single byte characters in that codepage. DBD::ODBC (in a unicode build) retrieves all string data as wide (unicode) characters and mos...

If you are absolutely sure you are using a single code page and don't want to be bothered with unicode, look up the odbc_old_unicode attribute but better still, rebuild DBD::ODBC without unicode support using:

perl Makefile.PL -nou

=head2 Does DBD::ODBC support the new table valued parameters?

Not yet. Patches welcome.

=head2 Why do I get "COUNT field incorrect or syntax error (SQL-07002)"?

In general this error is telling you the number of parameters bound or
passed to execute does not match the number of parameter markers in
your SQL. However, this can also happen if you attempt to use too many
parameters.

For instance, for MS SQL Server
(http://msdn.microsoft.com/en-us/library/ms143432.aspx) the maximum is
2100.

=head2 Why are my column names truncated to 30 characters when using freeTDS?

You should note this is only an observed answer. The person who
reported this to me was using MS SQL Server 2008. If he set TDS
protocol 6.0, 9.0 or 10.0 his column names were truncated to 30
charatcers. If he specified TDS protocol 7.0 or 8.0 his column names
were not truncated. We guessed his server did not support protocols
9.0 or 10.0 and fall back to 6.0 where column names are restricted to
30 characters.

=head2 Why are my doubles truncated from MS Access DB?

If you have a double column in your MS Access DB and the retrieved
values are truncated you have probably hit a known (and fixed) bug in
the MS Access ODBC driver. Typical truncation lookes like this:

  8.93601020357839E-06 returned as E-6

If you have the Microsoft Access 2010 accdb ODBC driver (v14) or older
then try upgrading to the 2013 (v15) driver as my experiments showed
that fixed the issue. Search for "Microsoft Access 2013
redistributable engine" and download the appropriate version for your
operating system.

=head2 Why is my (long)binary data inserted into MS Access incorrect?

A typical example of this is trying to insert binary data into a
MS Access table using parameters and the data ends up full of null bytes.

The MS Access ODBC driver does not support the ODBC API SQLDescribeParam
so DBD::ODBC has no idea what parameter type to use when binding placeholders.
By default, DBD::ODBC defaults in this situations to SQL_CHAR type. However,
when you bind binary data as SQL_CHAR with the MS Access ODBC Driver the data
stored in your DB will no longer be the data you expect as the driver translates
your data bound as a string to binary. The way around this is to bind the parameter
specifying the binary type e.g.,

  $sth->bind_param(1, undef, SQL_LONGVARBINARY)

or one of the other binary types. Note, that you don't actually have to pass the
parameter into bind_param as parameter types are sticky so (as in this example) you
can tell DBD::ODBC to use a different type in the bind_param call but still go on to