trouble with DBI/CGI

[David Morel]

Hi,

I am having trouble combining DBI and CGI.

Consider the following program:

#!/usr/local/bin/perl -w
use strict;
use DBI;
use CGI ':standard';

print "Content-type: text/plain\n\n";
print "abc\n";
my $dbh = DBI->connect("dbi:Oracle:ORCL", "username", "password");
print "123\n";


When I run the above program from a web browser, I get the output:
abc

When I run the above program from the command line, I get the output:
abc
123

In other words, it seems that when I run the script from the web it
stops immediately after it creates the database handle... but works
properly when run from the command line.

What gives?

Thank you,
David Morel

 

[Gunnar Hjalmarsson]

Consider the following program:

#!/usr/local/bin/perl -w
use strict;
use DBI;
use CGI ':standard';

print "Content-type: text/plain\n\n";
print "abc\n";
my $dbh = DBI->connect("dbi:Oracle:ORCL", "username", "password");
print "123\n";

When I run the above program from a web browser, I get the output:
abc

When I run the above program from the command line, I get the
output:
abc
123

In other words, it seems that when I run the script from the web it
stops immediately after it creates the database handle... but
works properly when run from the command line.

Seems like a permission problem to me. (CGI scripts are probably run
as some other user.)

But why guess? Why not ask Perl about it?

my $dbh = DBI->connect("dbi:Oracle:ORCL", "username", "password")
or die $dbh->errstr;

See more about capturing DBI errors in the docs for DBI.pm.

You may also want to include this line in the beginning of the script:

use CGI::Carp 'fatalsToBrowser';

 

[Sam Holden]

Hi,

I am having trouble combining DBI and CGI.

Consider the following program:

[snip program and output description]

In other words, it seems that when I run the script from the web it
stops immediately after it creates the database handle... but works
properly when run from the command line.

Check the error message that should be logged somewhere by the web server.

Or add "use CGI::Carp 'fatalsToBrowser';" to the top.

 

[Juha Laiho]

(e-mail address removed) (David Morel) said:

I am having trouble combining DBI and CGI. ....
print "abc\n";
my $dbh = DBI->connect("dbi:Oracle:ORCL", "username", "password");
print "123\n";

When I run the above program from a web browser, I get the output:
abc

When I run the above program from the command line, I get the output:
abc
123

In other words, it seems that when I run the script from the web it
stops immediately after it creates the database handle... but works
properly when run from the command line.

My best guess from this information is that the ORACLE_HOME environment
variable isn't set when you're running your script as a CGI. Verify
this with the means provided in the other response.

 

[Ron Reidy]

The problem is malformed header. Check the CGI docs and look in the web
browser's error log.

 

[Eric J. Roode]

The problem is malformed header. Check the CGI docs and look in the web
browser's error log.

What's wrong with the OP's header?

print "Content-type: text/plain\n\n";

 

[James Willmore]

The problem is malformed header. Check the CGI docs and look in the
web browser's error log.

This is part of the problem ....

He's not checking the connection success/failure. So, for
some reason, the connection is failing while running the script
through the web server.
Change to:

my $dbh = DBI->connect("dbi:Oracle:ORCL", "username", "password")
or die "Can't connect: ", $DBI::errstr,"\n";

This will cause the script to fail if it can't connect to the
database. Be careful with the above code. Don't use it in a
production environment. If memory serves - Oracle will report the
username and password in the error message. So, just take the
'$DBI::errstr' portion out if running this code in production.

HTH

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
The idea is to die young as late as possible. -- Ashley Montagu

 

[Sara]

Hi,

I am having trouble combining DBI and CGI.

Consider the following program:

#!/usr/local/bin/perl -w
use strict;
use DBI;
use CGI ':standard';

print "Content-type: text/plain\n\n";
print "abc\n";
my $dbh = DBI->connect("dbi:Oracle:ORCL", "username", "password");
print "123\n";


When I run the above program from a web browser, I get the output:
abc

When I run the above program from the command line, I get the output:
abc
123

In other words, it seems that when I run the script from the web it
stops immediately after it creates the database handle... but works
properly when run from the command line.

What gives?

Thank you,
David Morel

Put this on top, make sure you have RW access to cgi.log in the cgidir
(or put it somewhere safer if you need to..)

use strict;
use CGI::Carp qw(carpout);
use CGI::Carp qw(fatalsToBrowser);
open LOG, ">./cgi.log";
carpout(*LOG);

I've found with DBI, many errors DON'T get to the browser, but the SQL
fails. In those cases, the log file always captures them. This is
particularly true for incorrect SQL statements.

good luck!
G

 

[Alan J. Flavell]

The problem is malformed header.

The original poster reported:

| When I run the above program from a web browser, I get the output:
| abc

How do you suppose he'd have got that, if he had a malformed header?

Check the CGI docs

No bad idea as a general rule, but speaking for myself, I think I'm
sufficiently familiar with them to know that they won't throw any
light on this particular issue.

and look in the web browser's error log.

OK, you got one bit right. But when testing, it might be better to
arrange for the program to report errors to the browser. Others have
already supplied those details (i.e testing for success of calls,
using CGI::Carp options etc.): after you've revised your knowledge of
usenet posting netiquette (the group's posting guidelines have useful
advice on the topic), you might want to get up to speed by reading the
other postings on the thread.

You then quoted:

David Morel wrote: [...]

print "Content-type: text/plain\n\n";
print "abc\n"; [...]
When I run the above program from a web browser, I get the output:
abc

Indeed he did write that, but like many typical TOFU-posters, you see
to have blurted out an answer without grasping the meaning of what you
are so comprehensively quoting.

good luck.

 

[Juha Laiho]

(e-mail address removed) (David Morel) said:

I am having trouble combining DBI and CGI.

Consider the following program:

#!/usr/local/bin/perl -w
use strict;
use DBI;
use CGI ':standard';

print "Content-type: text/plain\n\n";

Btw, as you already have "use CGI ':standard';" there you might
as well use it to your advantage by replacing the
print "Content-type: text/plain\n\n";
with
print header('text/plain');

 

[James Willmore]

On 30 Nov 2003 07:06:53 -0800

(e-mail address removed) (David Morel) wrote in message
news:<[email protected]>...

I've found with DBI, many errors DON'T get to the browser, but the
SQL fails. In those cases, the log file always captures them. This
is particularly true for incorrect SQL statements.

Because of improper use of the module You *need* to code so that
errors from DBI calls *are* reported. For example:

my $dbh = DBI->connect('dbi:ODBC:mydb', 'user', 'pass')
or die "Connection failed: ", $DBI::errstr,"\n";

The error *will* show in the web server's error log (at least Apache
will do such trival things - not sure about IIS). And, it *will* show
in the browser, just like other errors, if you use CGI::Carp
(importing 'fatalsToBrowser').

HTH

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
Disco is to music what Etch-A-Sketch is to art.

 

[Sara]

On 30 Nov 2003 07:06:53 -0800



Because of improper use of the module You *need* to code so that
errors from DBI calls *are* reported. For example:

my $dbh = DBI->connect('dbi:ODBC:mydb', 'user', 'pass')
or die "Connection failed: ", $DBI::errstr,"\n";

The error *will* show in the web server's error log (at least Apache
will do such trival things - not sure about IIS). And, it *will* show
in the browser, just like other errors, if you use CGI::Carp
(importing 'fatalsToBrowser').

HTH

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
Disco is to music what Etch-A-Sketch is to art.

 

[Malcolm Dew-Jones]

Sara ([email protected]) wrote:

: ... I'd rather ensure
: my SQL statements are correct by construction rather than error-check
: everytime I issue one, wasting code and resources.

I would disagree. Every call should be error checked unless you don't
care about an error at that point (which is ok in some situations).

No sql query is every "correct by construction" except at the moment you
test it. Many databases change over time, and old queries become
incorrect, and any number of other things can occur.

Of course I haven't read this thread, I just noticed the above, which
sounds wrong to me, so maybe i'm out to lunch.

 

[James Willmore]

On 4 Dec 2003 12:27:28 -0800

Just take note of the example - no SQL is involved - we want to see if
we can *connect* to the datasource. You would like to know that
first, right?

Not so fast Mogambo aka Mister Jim. Unless you want to check the
error status of every single query, which is wasteful in more ways
than one, its much simpler to log the errors and botta-bing "there's
your problem".

Define "wasteful". If this were COBOL, I could understand. It *is*
wasteful in COBOL to do things like check to see if a file exists or
was opened, etc., etc. - because JCL will do the task with less code
and resources. But ... this is Perl So, you'll have to explain
to me *why* it's wastful to check for errors.

In fact, you're doing double duty with using a log to log errors to.
How do you maintain the log (or logs - because if you apply this
principle to *each* script that uses DBI, you'll have more than *one*
log I presume)? How about rotation of the log(s)? Hum ... I guess
you didn't think of that one, eh? Now you'll have to write a script
to take care of this newly added log(s) - or the log(s) will overrun
the filesystem over time.

And - What's wrong with the *server's* log? *All* errors will get
logged to the server's log - *if* you code properly.

Even with "Errors Raised", failed SQL statements don't result in a
fatal error, Therefore "FatalsToBrowser" does nothing in those
cases unless you explicitly die or croak as you did above. I'd
rather ensure my SQL statements are correct by construction rather
than error-check everytime I issue one, wasting code and resources.
Talk about code bloat! ack.. I mean really..

True - not all errors with a *query* will result in an *fatal* error.
However, if you want to *know* something went wrong, you need to
*code* for that.

The error checking is *not* just to see if the SQL syntax is correct -
it's to see if the query *worked* - there is a difference.

Use the CGI log, like Barney its your friend

No - I'll use the server log like most who code CGI scripts

Check out this link which will show *how* to debug buggy CGI
(long link follows)

http://cvs.sourceforge.net/viewcvs....ting_CGI.html?rev=HEAD&content-type=text/html

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
The light at the end of the tunnel is the headlight of an
approaching train.