Not simply. Unlike some pure-Perl modules, the DBD::SQLite distribution includes a number of C files that must be compiled. (This includes the code for the SQLite database itself.)

If you know exactly what type of server you're running on, and can get access to another machine of a similar type, you might be able to compile it there and then FTP the binary up to the web server, but there are so many variables involved that I would not recommend this unless you are extremely comfortable with C compilation.

Thanks simonm

The C bit was what I suspected might put a halt to the idea!
Oh well, I shall stick to the (very good) DBD::AnyData module for now.

Lance

Kia Kaha, Kia Toa, Kia Manawanui!
Be Strong, Be Brave, Be perservering!

Now do a few tests to make sure it's running things as your UID (most CGI servers are set to suidexec your scripts) and that you can view your home directory. Now upload the DBD-SQLite tar-ball. Then issue the magic command:

   cd ~ && tar zxvf DBD-SQLite*gz && cd DBD-SQLite* && perl Makefile.P
+L PREFIX=~ && make install;
[download]

If all goes well you should have a compiled copy of DBD::SQLite in ~/lib.

-sam

Good thought overall, and very clever suggestion. Just be be careful that this isn't considered abuse by your host. There is a chance that the host wouldn't care for sneaky compiler running when they've got ssh blocked.

Of course, if they suck that bad, there are better hosts available for cheap :-)

Why don't you just contact your ISP and ask if they'd install it. It isn't such a crazy request. Might take a week, but as you said, you're writing your code with the right hooks anyway...

As long as they've got a compiler, it should be possible. First, write a CGI script that will do a qx// on whatever you send it and send you back the results ... Now upload the DBD-SQLite tar-ball. Then issue the magic command ...

Better yet, just have that CGI script use CPAN. Here's a (completely untested) outline of a "cpan_installer.cgi" script:

  #!perl

  use CGI qw/:standard/;
  use CPAN;

  print header();

  if ( my $module = param('module') ) {
    print start_html("Installing $module"), 
                  h1("Installing $module");
    $ENV{PREFIX} = '~';
    eval {
      CPAN::Shell->expand('Module',$module)->install
    };
    if ( $@ ) {
      print "<font color=red>Failure: $@</font>";
    }
  } else {
    print start_html("CPAN Installer Tool"), 
                  h1("CPAN Installer Tool");
    print start_form(), 
          textfield('module', ""),
          submit('install', "Click to Install"),
          end_form();
  }
  print end_html();
[download]

Properly fitted out with some logic to detect common configuration problems and extra form controls to allow futzing with the make process, this might serve as a useful resource... I notice a routine stream of postings along the lines of "I only have FTP and CGI access on my web server account, and want to install X." It'd be nice if we could reply with something like "Just upload this script and it will either guide you through the process, or explain why it can't be done on your server."

Update: On second thought, this is more complicated than the above suggests; for example, we may need to deal with configuring CPAN for the first time, which this script doesn't do... But I still think that a suitably enhanced "cpan.cgi" script could be useful to many.

If you want to stick with DBD::AnyData, you'll have to escape the data before inserting with s/\n/\\n/g and then unescape it after fetching with s/\\n/\n/g

If your host has BerkeleyDB or DB_File or something better than SDBM_File, you could also use DBD::DBM which wouldn't require additional compiled components.

You might also consider things like kwiki or bryar which can manage content using the file system as a database and which don't require AFAIK any compiled components.

You should be able to transfer the module over to your remote directory and then do a 'use lib' in your script. That will modify @INC so that Perl can find the module, just as if you'd written it yourself and put it there.

Recipe 12.7 if you happen to have the Perl Cookbook.

You should be able to transfer the module over to your remote directory and then do a 'use lib' in your script.

Although usually helpful, this advice only applies to pure-Perl modules; the DBD::SQLite distribution includes the C source code for the SQLite database library, and thus must be compiled on the target machine (or a very close equivalent).

Please, if you suggest simplicistic solutions, also make sure that they apply. DBD::SQLite is a module with an XS part and that means that additional files need to be transferred, and, most important, the compiler and architecture used to compile the XS portion of the module must match the compiler and architecture that the webserver uses for its Perl. If they don't match, copying the files will not achieve anything at all.

Understood and agreed, but since there's a 95+% chance that the server is either win32 or linux, I'd still go for it. IMO, it would be much more profitable to spend a little time getting SQLite to work than it would to spend the time re-coding its capabilities.

You make a good case, but I'd (obviously) try my way before giving up a real database for something lesser. (But that's just me.)