I see that my code example was not sufficiently complete. Here is a full, runnable case:

use strict;
use warnings;
use BerkeleyDB;

my $home = ".";
my $tableName = "testDB";
my $dbName = "testDex";

my $table = BerkeleyDB::Btree->new(
    -Filename => "$home/$tableName/$tableName",
    -Compare  => sub { my($a, $b) = @_; return $a <=> $b; }, # numeric
    -Flags    => DB_CREATE,
) or die "Could not open \'$home/$tableName/$tableName\' ... ";

my $db = BerkeleyDB::Btree->new(
     -Property => DB_DUP,        
     -Flags    => DB_CREATE,
     -Filename => "$home/$tableName/$dbName",
     -Compare => sub { my($a, $b) = @_; return $a cmp $b; }, # ascii
) or die "Could not open \'$home/$tableName/$dbName\' ... ";

sub key_sub {
   my $pkey = shift;
   my $pdata = shift;
   $_[0] = (split /\|/,$pdata)[1];
   return 0;
}

$table->associate($db, \&key_sub);
$table->db_put(1,"x|w60");
$table->db_put(2,"y|w61");
[download]

The error messages in this case are:

Argument "w60" isn't numeric in numeric comparison (<=>) at hhh.pl lin
+e 11.
Argument "w61" isn't numeric in numeric comparison (<=>) at hhh.pl lin
+e 11.
Argument "w60" isn't numeric in numeric comparison (<=>) at hhh.pl lin
+e 11.
Argument "w61" isn't numeric in numeric comparison (<=>) at hhh.pl lin
+e 11.
[download]

What I expect to happen is that whenever I do a "db_put" to the primary table, the key_sub will be called to extract a key (e.g. "w60") and that a secondary index will be made using that key.

I expect to be able to specify a "-Compare" function for that secondary table that is appropriate for the ascii keys I am using. But for some reason the "-Compare" function of the first table is being used for the keys of the second table.

I have a work-around for it for now, but I'd still like to find out where the problem is so that it can be fixed in the module. Here's my work-around:

my $digits = qr/^\d+$/;

sub eitherComp {
   my($a, $b) = @_;
   return $a <=> $b if ($a =~ $digits and $b =~ $digits);
   return $a cmp $b;
}
[download]

If I make the "-Compare" function for the first table a reference to eitherComp, the problem goes away.

Update: I think I'm on the track of the bug. In the XS wrapper code for BerkeleyDB, I find the function btree_compare, which uses a global variable called CurrentDB. The comparison function is called as follows:

    count = perl_call_sv(CurrentDB->compare, G_SCALAR);
[download]

Suppose that CurrentDB was set to the first table, and that it isn't changed when the associated tables are being updated. That would explain the bug I am seeing. I will email Paul Marquess about this.