Irrelevant to the DB issue but may make debugging easier:

In your CGI program always print the HTTP headers before you do anything else.

print "Content-Type: text/html\r\n\r\n";
[download]

in this way, any print statement (to STDOUT) from you or from a module you are calling will end up in the browser. Failure to print headers results in server response error 500 when anyone prints to STDOUT an innocent debug message.

Another helpful thing will be to redirect STDERR to a server-side log file using:

if( ! open(STDERR, '>>', '/tmp/log.txt') ){ ... }
[download]

In my experience, one may control own program's print statements but not 3rd party modules'.

Poj's suggestion for using

use CGI::Carp 'fatalsToBrowser';

covers some of the cases I mentioned

As per the DB problem in particular: you have to make sure that the DB itself but also the *directory* it resides in are writable by the OWNER-USER OF THE CGI script.

Lastly, multiple access to a DB will initiate file-locking making the DB temporarily read-only. I am not acquainted with SQLite but there may be stale lock files somewhere?