Olivier Poulet wrote:
> Hello to all,
>
> I am running a snippet similar to this against MSSQL 2000, on a Win32
> box.
>
> my $sql =<<'EOFSQL';
> SELECT
> LOWER(field_one), field_two, UPPER(field_three)
> FROM sample_table (NOLOCK)
> WHERE
> field_one = ?
> EOFSQL
>
> my $sth = $dbh->prepare($sql) or die;
>
> my ($field_one, $field_two, $field_three);
>
> for my $test_value (@test_values) {
> $sth->bind_param(1, $test_value);
> $sth->execute;
> $sth->bind_columns(\$field_one, \$field_two, \$field_three);
> while ($sth->fetch) {
> print join "-", ($field_one, $field_two, $field_three);
> }
> }
>
> Using the MSSQL 'LOWER' and 'UPPER' functions (or any other), gives me
> back 2 "unnamed" columns.
>
> When run through DBD::ADO, $field_one gets clobbered by the contents of
> $field_three, as if $sth->fetch were returning/storing things in a hash.
> I've expanded the statement to fetch several more "unnamed" columns, and
> the value(s) returned, for every "unnamed" column, is _always_ the value
> of the "last" column in the SELECT statement.
>
> However, running the same code/statement with DBD::ODBC does not have
> this behaviour, and the results returned are correct.
>
> Is this a problem, or something known and to avoid when using DBD::ADO ?
Looks like this bug:
<http://www.xray.mpe.mpg.de/mailing-lists/dbi/2004-01/msg00206.html>
It was fixed in 2.87:
<http://www.xray.mpe.mpg.de/mailing-lists/dbi/2004-02/msg00023.html>
Do you use a pre-2.87 release?
Steffen
