halfcountplus has asked for the wisdom of the Perl Monks concerning the following question:

I am using DBI::SQLite in a mason context. Since I'm new to this stuff, I'm writing (non mason) test scripts and then transferring the syntax into the web app code. So, this is the "mason" code that worked in a script:

% my $db = DBI->connect("DBI:SQLite:$db_file"); % if (exists $ARGS{name}) { $db->do("insert into subjects (name) value +s ('$ARGS{name}');"); % print $ARGS{name}; } % my $sql = $db->prepare("select * from subjects"); % $sql->execute;

The prepare and execute work fine. However, initially the write (do insert) line produced this in httpd's error log:

unable to open database file at /var/www/html/mason/subjlist.comp line 4.

Even tho the file is owned by apache. So I changed the mode to 666 from 644 (probably not advisable) to see what would happen (ie, if maybe perl is running as a different user), but I get the same response. The print debugging line comes out correct, and there is no SQLite error.

What have I missed?

Replies are listed 'Best First'.
Re: DBI::SQLite and apache
by perrin (Chancellor) on Jun 12, 2009 at 18:22 UTC
    Either you used a relative path to the file, which you should change, or there's a permissions problem with an enclosing directory.
      Changing the ownership of the db's directory worked. Thanks!
Re: DBI::SQLite and apache
by CountZero (Bishop) on Jun 12, 2009 at 18:56 UTC
    How do you know that the connect, the prepare and the execute "work fine"? You do not test the return value of these functions.

    Add some or die ... or or warn ... code to these functions and see what that does.


    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

      Even better: Let DBI do that for you: connect with RaiseError => 1 and every failing DBI method will die automatically. If you expect that a function may die, wrap in in an eval { BLOCK }. This is the usual way to handle transactions: Code that may fail and the final commit are wrapped in eval, followed by a rollback when $@ is true.


      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
        Much appreciated!
      How do you know that the connect, the prepare and the execute "work fine"? You do not test the return value of these functions.

      No, but there are already "subjects" in the database and these are read and displayed correctly. Perhaps I should have explained this any case, it is *not* because $db is a bad handle. I will add the warns tho, you are right, they should be there from the start.