If you run the script via CGI (you haven't said what kind of webserver setup you have), you can put the path to the 64-bit perl in the shebang line as usual. And if the DBI/DBD modules are in a non-standard location, you could use lib ... in the script.

Thanks, almut. I am running the script via CGI, but if I put the 64-bit path in the shebang line without environment variables (from a browser or in Taint mode), Perl can't find lib.pm, which makes me think something is set up wrong with the 64-bit installation.

...which makes me think something is set up wrong with the 64-bit installation.

Did you maybe move the Perl tree from a different installation location (i.e. was it originally compiled for and installed to a different location)?  The problem with this is that the installation and default search paths are (by default) hard-coded in the perl binary, so when you move it, it'll look in the wrong places...

You could work around that by saying something like this (at the top of every script):

BEGIN { 
    unshift @INC,
        "/usr/local/perl/5.10.1/lib/5.10.1/x86_64-linux-thread-multi",
+   # for lib.pm
        "/usr/local/perl/5.10.1/lib/5.10.1";                          
+   # for strict.pm 
}
[download]

(of course with the correct paths where lib.pm and strict.pm (needed by lib.pm) are found in your case)

After that you can then say use lib ... as usual to add other directories to @INC.  Note that when you manually manipulate @INC, the architecture-specfic subdirectories (here .../x86_64-linux-thread-multi) are not added automatically (as use lib does).

Better yet, compile a new perl specifying the proper installation target at build time (e.g. ./Configure -Dprefix=...), such that the compiled-in paths will match the final installation location on the webserver.