for ($a=0; $a<= scalar(@abst_listing); $a++){
[download]

to:

for ($a=0; $a< scalar(@abst_listing); $a++){
[download]

A more Perl-ish way to create this for loop is as follows:

for my $a (0 ..  $#abst_listing){
[download]

Notice that I declared the loop variable in the for statement itself. You should do the same for your b and c loops as well.

If you had shown some actual data, it would be easier to figure out why you are not getting the matches you expect. Perhaps some other tips in the Basic debugging checklist will help you. If your arrays contain metacharacters, perhaps you need to use quotemeta for your regular expressions. You could try to chomp your arrays, then simplify your regexes by removing the //m modifiers.

As a side note, your get_data sub is very similar to File::Slurp::read_file.

use lib'/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/mys
+ql.pm';
[download]

use lib '/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi';
[download]

Update: fixed typo (thanks amedico).

Also, an even better way to write the array loops is:

for my $cont_name (@cont_names) {
    # do stuff with $cont_name
}
[download]

Rather than:

for ($c=0; $c < scalar(@cont_names); $c++) {
    # do stuff with $cont_names[$c]
}
[download]

When you don't specifically need the index number, it's best to avoid it altogether. Not dealing with the array index number makes your code more readable, more maintainable, and less error-prone.

Typo... I think you mean:

for ($a=0; $a<scalar(@abst_listing); $a++){

Thank you very much. the codes do work well now. I handled the off-by-one error as advised. I also hadn't chomped the arrays earlier. Thanks a lot.

my $sth = $dbh->prepare(  "SELECT pmid, abstract FROM PM_text "
                        . "WHERE title LIKE '%E.coli%'"        );
$sth->execute;

my @text_refs = ($sth->fetchrow_hashref());

$sth->finish;

...

for my $text_ref (@text_refs) {
    for my $cont_name (@cont_names) {
        if ($text_ref->{abstract} =~ m/$cont_name/im) {
            for my $bact_name (@bact_names) {
                if ($text_ref->{abstract} =~ m/$bact_name/im) {
                    print  "matched at text $text_ref->{pmid}, "
                         . "for $cont_name and $bact_name\n";

                    $sth2->execute( $bact_name,
                                    $cont_name,
                                    $text_ref->{pmid} );

                    $sth3->execute( $cont_name,
                                    $text_ref->{pmid} );
                }                          
            }                              
        }
    }
}
[download]

Thanks amedico. I notice the improvement from using 'fetchrow_hashref'. Thanks. I'm currently 'having a go' at the 2nd suggestion, to see how it affects the entire scheme. Thanks a lot

Without the database it is difficult to run the script. So it might be better to help you debug than to just guess wildly. But nevertheless here is one wild guess: The line

push(@abst_listing,$abstracts[1]);
[download]

pushes into @abst_listing without checking the value in $abstracts[$1]. Maybe @abstracts has only one value, that would push the undefined value into @abst_listing, eventually generating an error message like you have seen.

By the way, the error message you get normally tells the variable that is undefined as well as the line number. You should read those error messages with an alert mind and think about it, or if you ask questions somewhere, include this information.

Now to debugging: There is a module called Data::Dumper which prints out data stored in variables of arbitrary complexity. Use that to print out values of variables, arrays, hashes and compare that with what you expect. For example try this:

# at the top of your script:
use Data::Dumper;

...
my $a; 
my $b; 
my $c;
# *** find out what the contents of your arrays is
print Dumper(\@abst_listing,\@cont_names,\@bact_names);
for ($a=0; $a<= scalar(@abst_listing); $a++){
    for ($c=0; $c<= scalar(@cont_names); $c++){
[download]

The backslash is there to make the output of Dumper easier to read. Run the script and maybe you will see something unexpected in one of your arrays. If you do, concentrate on the lines where this array was filled and try to imagine how such a result could have come about. Maybe put some more Dumper() calls there to check other variables. Or ask about it here, with such detailed information posted you should have a definite answer in minutes

Thanks jethro. Indeed some of the variables being returned were undefs. Using Data::Dumper they became glaring. So I put in some code to turn the nulls into empty strings and that helped a lot. Thanks so much for this help.