It would help to show some code and the exact error message (by all means s/real_username/username/ s/real_password/password/ s/real_ip/x.x.x.x/ etc). The actual error message in all its exacting detail is typically relevant. Do you actually get '***', .... ? When a script runs on the command line (as user you presumbably, IP ? localhost) you need to understand that under CGI it probably runs as user ? apache ? nobody, IP ? real_ip. In other words the environment is different. It seems as though you are connecting to a remote DB which will have in it a remote access perms table that might look like:

user          perms
you@somewhere *
you@%         *
[download]

That's fine when you try to connect but not so good when apache@perhaps_some_other_ip tries to connect. If that is not the problem you also possibly have a firewall between you and the remote DB. DBs connect on unusual ports, and you can punch holes through firewalls on a global or per user basis.....

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Hi,

Here's some code below:


#!c:\Perl\bin\perl.exe

use strict;

use DBI;
use CGI;
use CGI::Carp qw(fatalsToBrowser set_message);
set_message("There has been a problem submitting this form. Please con
+tact the Reception desk.");
$CGI::POST_MAX=1024 * 100; # max 100k posts
$CGI::DISABLE_UPLOADS = 1; # no uploads allowed
use Data::Dumper;

my $user='foo';
my $pwd='bar';

my $dbh = DBI->connect('dbi:ODBC:Oracle7', $user, $pwd, { RaiseError =
+> 1 }) or die "Failed to connect to $DBI::errstr\n";

my $sql = "insert into users (surname,forename,title,nationality,dob,g
+ender,email,status,created,created_by)
values
('Smith','Fred','Mr','UK','27031972','m','f.smith\@hotmail.com','Frien
+ds',SYSDATE,'SelfReg')";

print "SQL is [$sql]\n";

my $sth = $dbh->prepare($sql) || do {
    die "Failed to prepare\n" };

$sth->execute;


$sth->finish;

$dbh->disconnect;
[download]

The error message from the log is:

c:\PROGRA~1\APACHE~1\apache\cgi-bin\TEST_I~1.CGI: DBI connect('Oracle7
+','foo',...) failed:  at c:\PROGRA~1\APACHE~1\apache\cgi-bin\TEST_I~1
+.CGI line 18
[download]

The failure is at the connect().

How can I test to see if it's a port/connection problem that's causing it?
Many thanks,
Mike

First is the DB remote ie on another boxen as asked? Anyway I expect it is so try this:

$user = 'foo@localhost';
[download]

Replace localhost with the external NUMERICAL (probably ;-) IP of your box - the one it is going to use to connect to Oracle.

Now ITFM it is noted that:

If the environment variable DBI_AUTOPROXY is defined (and the driver i
+n $data_source is not ``Proxy'') then the connect request will automa
+tically be changed to:

  $ENV{DBI_AUTOPROXY};dsn=$data_source
DBI_AUTOPROXY is typically set as ``dbi:Proxy:hostname=...;port=...''.
+ If $ENV{DBI_AUTOPROXY} doesn't begin with 'dbi:' then ``dbi:Proxy:''
+ will be prepended to it first. See the DBD::Proxy documentation for 
+more details.
[download]

So it may well be that your actual connect is specifying diffenerent details like the hostname and port perhaps? Hostnames and ports are handy connecting to remote DBs. But I am speculating because you don't supply enough detail. Still this is one of my current working theorums. Perhaps this env variable is set for you but not apache. To test the ENV dump in off the command line where it is working and dump it in you CGI before it explodes. If there are differences you could do worse than to fix them and see if the problem goes away.

Thinking about it on Win32 with ODBC database access you set up (or the installer does) a mapping from a DSN (Data Source Name) to the actual DB. Do this. Start|Run|odbcad32. You will see a dialog. I expect that you have a user DSN (which lets you connect to Oracle) but Apache does not. Add a system DSN and the problem should go away. If that is the problem. But then other people could perhaps get a the DB which may be another problem. Too many problems for one night.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print