Hello ticfranca,
It sounds very much like you are new to both DBI and MySQL and maybe even perl. I would suggest that you start a little smaller when trying to get this setup properly at the admin level before moving on to cgi and apache integration.
Take this little script for example. You simply run it from the command prompt and it connects to MySQL and prints out the tables in the database that you specify. If you can't get this to work, then hopefully you can track down the problem to either something with the configuration of your mysql server, or maybe your connect string information.
-
#! /usr/bin/perl
-
-
use DBI;
-
-
use strict;
-
-
# Database Connect Values
-
my $name = 'bundinha';
-
my $user = 'myhumoradm';
-
my $pass = 'my8xr2d2';
-
my $host = 'localhost';
-
-
# Database URL
-
my $url = "dbi:mysql:$name:$host";
-
-
my $dbh = DBI->connect($url, $user, $pass) or die "Database connection failed.";
-
-
# Determine Existing Tables
-
my $name;
-
my $sth = $dbh->prepare(q{SHOW TABLES});
-
$sth->execute or die $dbh->errstr;
-
$sth->bind_columns(\$name);
-
while ($sth->fetch) {
-
print "$name\n";
-
}
-
$sth->finish; undef $sth;
-
-
$dbh->disconnect; undef $dbh;
-
-
1;
-
-
__END__
-
When I run this on my local machine, I get the following results:
-
> perl scratch.pl
-
DBI connect('bundinha:localhost','myhumoradm',...) failed: Can't connect to MySQL server on 'localhost' (10061) at scratch.pl line 16
-
Database connection failed. at scratch.pl line 16.
-
This is good, because I don't actually have mysql installed on my home computer so it's no surprise that it can't connect to MySQL server.
On my development machine I get the following results
-
$ perl scratch.pl
-
DBI->connect(bundinha:localhost) failed: Access denied for user: 'myhumoradm@localhost' (Using password: YES) at scratch.pl line 16
-
Database connection failed. at scratch.pl line 16.
-
This is also as expected because while I have a MySQL server, I have no permissions setup for user myhumoradm.
Getting DBI to work is all about putting yourself in a position to receive meaningful error messages. Without those you can never come close to knowing how to fix something that goes wrong.
Your first error message was meaningful, although you didn't know what it meant.
Can't call method "execute" on an undefined value at This meant quite simply that the object that you were trying to run execute on was undefined. This led me to immediately ask, what value or object is this error message talking about? Well, it could only be one, $sth. Then I ask why is this value undefined? Well, the only way to know this is to look at the previous line and see that your assignment was malformed because of the inclusion of the if statement. You fixed that, great.
Next you came back with an "Internal Server Error". Well this means that your apache server died for some reason, but unfortunately you don't know the reason. Well, we can presume that because you only changed two lines that the die was in this line "$sth->execute() or die $dbh->errstr". However, to be able to diagnose this we must know what the errstr was. To get this you either need to look at the error log or run the cgi script outside of the apache environment, which you eventually decided to do.
This lead you to the next clue. " perl: relocation error: ... undefined symbol: mysql_warning_count". Guess what, I have no idea what this means, so the quickest place to be enlightened is google. This actually doesn't bring up too much information other than what this function is. "Description: Returns the number of warnings generated during execution of the previous SQL statement. ". This isn't very enlightening although it does tell us that DBI is at least trying to work.
So this brings me to my only suggested approach. Limit the number of possible causes by reducing your MySQL code to the minimum necessary to test if things are working. The script that I just provided should do that, and if this works, then see about testing the exact query that you use in your cgi script.
Then if that works see about importing it into a basic CGI script. And on and on, slowly adding layers of uncertainty and risk until you either reach your final goal or something breaks that you can recognize and diagnose.
This is called debugging. It's tedious. But it's something that all programmers and developers have to learn as we all make mistakes. We just must aim to setup our environments to minimize risk and be certain that errors are reported in meaningful ways.
Good luck,
- Miller