Question

Possible Duplicate:
error of importing DBI in Perl

I have a problem when I use the DBI module in another module, script.pm.

package CC;


use DBI;
use strict; 
use Alias;


my $dbFile = 'XXXXXXXX.db';

my $db = DBI->connect("dbi:SQLite:$dbFile","","",
    {RaiseError =>1, AutoCommit => 1})or "Unable to connect:  $DBI::errstr\n";


use Alias qw(attr);
our ($CURRENTOFFSET,@LANGUAGE);

sub new {
    my $that = shift;
    my $class = ref($that)|| $that;
    my $self = {
        CURRENTOFFSET=> undef,
        LANGUAGE => []  
    };
    bless($self, $class);
    return $self;
}

Answer 1

Substantive

Conventionally, a package XYZ is kept in a file XYZ.pm; Perl won’t find your package otherwise. Thus, your file should be CC.pm rather than script.pm.

Note that a package Organization::Team::Purpose is kept in a file Purpose.pm, but the file is kept in a sub-directory Organization/Team and the base directory holding Organization has to be found by Perl (using -I/some/where if Organization is a sub-directory of the directory /some/where, for example; if it is a sub-directory of the current directory, it will be found anyway).

You should probably review the or clause after your connection attempt. Normally, you do a die or croak there. You simply evaluate a string, which is not very useful.

You have:

my $db = DBI->connect("dbi:SQLite:$dbFile","","",
    {RaiseError =>1, AutoCommit => 1})or "Unable to connect:  $DBI::errstr\n";

You should consider what to do, but one technique is:

use Carp;
my $db = DBI->connect("dbi:SQLite:$dbFile", "", "",
                      { RaiseError => 1, AutoCommit => 1 })
         or croak "Unable to connect: $DBI::errstr\n";

The downside of that is that this is going into a module, and it isn’t necessarily a good idea to croak in the BEGIN code of a module (and I’m making an assumption that the code is executed as the module is loaded). You might need to store the undef database handle and protect other methods from using it. You might be better off deferring the ‘connect to database’ operation until the constructor new is used (possibly for the first time). It is at least legitimate to raise errors at that point.

As the answer by DVK noted (before I wrote my answer), modules should end with 1; to indicate successful loading. Maybe you can exploit that to report an error on failure to load – the final condition might be ‘defined $db ? 0 : 1;‘ (or even just ‘defined $db;‘), but it would be crucial to generate an error message somehow to explain the problem.

Trivia

You should be ruthlessly consistent in the spacing around operators, too. Your example includes:

{RaiseError =>1, AutoCommit => 1}
my $class = ref($that)|| $that;
CURRENTOFFSET=> undef,

which would be better written as:

{RaiseError => 1, AutoCommit => 1}
my $class = ref($that) || $that;
CURRENTOFFSET => undef,

The first might benefit from a little more space:

{ RaiseError => 1, AutoCommit => 1 }

It doesn’t directly affect the operation of the code. It does make it a little less easy to read. Learning to be consistent is an important part of learning to program.