well, I'm thinking maybe it's a bug

I've tried different queries:

my $sql0 = qq|SELECT "MARQUE" FROM $table|;
my $sql1 = qq|SELECT "DESC1" FROM $table|;
my $sql2 = qq|SELECT "DESC2" FROM $table|;
my $sql3 = qq|SELECT "PRIX" FROM $table|;
my $sql4 = qq|SELECT "REF" FROM $table|;
my $sql5 = qq|SELECT "TAILLE", "COULEUR" FROM $table|;
my $sql6 = qq|SELECT "REF" FROM $table LIMIT 5|;
my $sql7 = qq|SELECT "DESC1" FROM $table ORDER BY "REF"|;
my $sql8 = qq|SELECT "REF" FROM $table ORDER BY "PRIX"|;
[download]

sql0, 1, 3, 4, 5 return all records

sql2 produces a 500 internal server error (so there is a problem in one or more rows in the "DESC2" column)

sql6, 7 and 8 return nothing

Like you said, I do not think now that the problem is perl-related. It's either DBI or DBD::ODBC

500 internal server error sounds awfully like an HTTP error and not an ODBC one. What happens when you run sql2 from a command prompt within a simple perl script? What error is raised/output? When we see what actual error you are getting we might be able to help.

With sql 6/7/8 it would probably be useful to know the schema and possibly a DBD::ODBC trace which you can get by setting (and exporting if UNIX) DBI_TRACE to "15=x.log" then the trace goes to x.log. But you need to simplify further to a straight forward perl script run from the command line. BTW, you did run DBD::ODBC's test suite to MS Access didn't you?

What versions of DBI and DBD::ODBC are you using? and what platform are you running this on.

I run it from the command line on an ubuntu box.

He's the dbi rap:

henri@henri-desktop:~$ perl -MDBI -e 'DBI->installed_versions;'
  Perl            : 5.008008    (i486-linux-gnu-thread-multi)
  OS              : linux    (2.6.24-19-server)
  DBI             : 1.609
  DBD::mysql      : 4.012
  DBD::Sponge     : 12.010002
  DBD::Proxy      : 0.2004
  DBD::ODBC       : 1.22
  DBD::Multiplex  : 2.09
  DBD::Gofer      : 0.011565
  DBD::File       : 0.37
  DBD::ExampleP   : 12.010007
  DBD::DBM        : 0.03
[download]

what got ran :

use DBI;
use DBD::ODBC;
use strict;
use warnings;

DBI->trace(DBD::ODBC->parse_trace_flags('odbcconnection|odbcunicode'))
+;

my $dbh = DBI->connect('dbi:ODBC:boutique', {RaiseError => 1, PrintErr
+or => 1} ); # data source set up in /etc/odbc.ini
my $table = "ARTICLES";
my $sql;
my $query;
my $result;
my ($i, $j);

$sql = SELECT "REF" FROM "$table" LIMIT 5|;
print qq~sql : $sql\n\n~;

$query = $dbh->prepare($sql);
$query->execute;
$result = $query->fetchall_arrayref();
for $i ( 0 .. $#{$result} ) {
   print qq~row $i : \t~;
      for $j ( 0 .. $#{$result->[$i]} ) {
         if ($result->[$i][$j] eq ""){
            print qq~NULL\t~;
         } else {
        print qq~$result->[$i][$j]\t~;
     }
      }
      print qq~\n~;
}

$query->finish();
$dbh->disconnect();
[download]

trace ends with :

sql : SELECT "REF" FROM "ARTICLES" LIMIT 5

Error at Line : syntax error near LIMIT
[download]

the last few lines of /tmp/x.log are :

    SQLDriverConnect 'boutique', 'HASH(0x8153c28)', 'xxxx'
    SQLConnect 'boutique', 'HASH(0x8153c28)'
Turning autocommit on
DRIVER_ODBC_VER = 
DRIVER_NAME = 
DRIVER_VERSION = 
DBD::ODBC is unicode built : NO
SQL_DBMS_NAME = zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
+zzzzzzzzzz
SQLMoreResults supported: 0
SQLDescribeParam supported: 0
SQLDescribeParam supported: 0
    Processing sql in non-unicode mode
SQLDisconnect=0
[download]

The 500 error I was refering to was partly solved by the command

export LC_TYPE=fr_FR
[download]

But I got only about 20 rows of of the 2000.

H