All of the sudden we have CGI errors showing up in the logs and one of the pages isn't working. I checked the syntax but I can't find the bug.. Any help would be greatly appreciated.
Here is the error we get in the browser:
Archive.pl: DBD::mysql::st execute failed: SELECT command denied to user 'mnin_user'#'localhost' for table 'needs' at /home/mnin/MNN_Code/Prod/lib/MySQL.lib line 52.
Compilation failed in require at archive.pl line 9.
Line 47-61 of MySQL.lib reads:
sub RunSQL {
## Executes an sql statement on the database.
my $sqlquery = shift;
$sth = $dbh->prepare($sqlquery);
$sth->execute(); #this is line 52
$MySQL_LastQuery = $sqlquery;
if ($sth->err()) {
return 1, $sth->errstr();
} else {
return 0, $sth->rows;
}
}
This is the Archvie.pl up to line 10
#!/usr/bin/perl
use CGI::Carp qw(fatalsToBrowser); # uncommenting this during debugging phase may be helpful
#use HTML::Template;
#use Win32::ODBC;
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
if($ENV{'REQUEST_METHOD'} eq "POST") { #pairs = split(/&/, $buffer);}
else { #pairs = split(/&/, $ENV{'QUERY_STRING'});}
Althought I don't think the problem is in the Archive.pl becaue these Compilation errors are showing in more than one place.
SELECT command denied to user 'mnin_user'#'localhost' for table 'needs'
This indicates you simply lack the permissions necessary to perform the query. At a minimum, you need the permissions granted by the following command:
GRANT SELECT ON `needs` TO 'mnin_user'#'localhost';
Related
Why does the following code:
#!/usr/bin/env tclsh
package require cmdline;
set options {{d.arg "" "destination directory"}}
set usage ": $::argv0 \[options] filename ...\noptions:"
set params [::cmdline::getoptions ::argv $options $usage]
throw the following error upon execution of ./main.tcl -help?
main : ./main.tcl [options] filename ...
options:
-d value destination directory <>
-help Print this message
-? Print this message
while executing
"error [usage $optlist $usage]"
(procedure "::cmdline::getoptions" line 15)
invoked from within
"::cmdline::getoptions ::argv $options $usage"
invoked from within
"set params [::cmdline::getoptions ::argv $options $usage]"
(file "./main.tcl" line 8)
It should display the usage information, but I didn't expect the error afterwards. Did I do something wrong?
From what I understand from the docs (emphasis mine):
The options -?, -help, and -- are implicitly understood. The first two abort option processing by throwing an error and force the generation of the usage message, whereas the the last aborts option processing without an error, leaving all arguments coming after for regular processing, even if starting with a dash.
using -help or -? will always throw an error.
Further down in the docs you can see an example where try { ... } trap { ... } is being used in conjunction with ::cmdline::getoptions, which might be how you might want to do it:
try {
array set params [::cmdline::getoptions ::argv $options $usage]
} trap {CMDLINE USAGE} {msg o} {
# Trap the usage signal, print the message, and exit the application.
# Note: Other errors are not caught and passed through to higher levels!
puts $msg
exit 1
}
My Perl script is supposed to print the results from my query. However, at the moment I'm getting the error:
Can't locate object method "fetchrow_array" via package "SELECT * FROM SERVER" (perhaps you forgot to load "SELECT * FROM SERVER"?) at updateDB.pl line 32
I imagine the problem is an easy one to fix.. but my perl / MySQL skills have much to be desired. My script is below:
#!/usr/bin/perl
use DBI;
use DBD::mysql;
use strict;
use warnings;
MySQL("SELECT * FROM SERVER");
# define subroutine to submit MySQL command
sub MySQL
{
# establish connection with 'serverDNA' database
my $connection = DBI->connect("DBI:mysql:database=serverDNA;host=localhost");
my $query = $_[0]; #assign argument to string
my $statement = $connection->prepare($query); #prepare query
$statement->execute(); #execute query
#loop to print MySQL results
while (my #row = $query->fetchrow_array)
{
print "#row\n";
}
}
Thanks so much!
You're calling fetchrow_array on the query string; you want to call it on the statement.
while (my #row = $statement->fetchrow_array)
{
print "#row\n";
}
I've researched a bit and found that using mysql_use_result=1 is supposed to alleviate the memory issue. However, since I am new to this DBI module I don't understand what is happening here:
#!/usr/bin/perl -w
use strict;
use DBI;
my $dbh = DBI>connect('DBI:mysql:blah;host=blah.blah.blah.blah;mysql_use_result=1','blah','blah',{RaiseError => 1});
my $sth = $dbh->prepare('select * from TaqMinute where tradeDate<=\'2014-04-22\' and symbol<=\'AAPL\' ;') ;
if (defined($sth)) {
$sth->execute();
my #row;
while (#row = $sth-> fetchrow_array()) {
print "#row\n" ;
}
}
$sth->finish();
$dbh->disconnect
Before I added mysql_use_result=1, the script would fail after about 1.5 minutes complaining that it ran out of memory. After adding this my query arguments are ignored and I simply get all the data in the database.
Any ideas how to help me or how to use this switch properly? Btw, the database that I am querying is very large.
Thanks in advance!
Craig
Try to use parametized queries, maybe something wrong with your qoutes.
my $dbh = DBI>connect('DBI:mysql:blah;host=blah.blah.blah.blah','blah','blah',{RaiseError => 1});
my $sth = $dbh->prepare_cached('select * from TaqMinute where tradeDate<=? and symbol<=?') ;
die "sth undef!" if ! defined $sth;
$sth->execute('2014-04-22','AAPL');
while (my $rowref = $sth->fetchrow_arrayref()) {
print Dumper($rowref) ;
}
$sth->finish;
I am updating a few records in database. And all the processing is done in eval block.
The problem is that even if the records are successfully updated , I still see a exception being raised.
To debug the exception, I tried printing it using Data Dumper but the exception is blank.
Can any one please help me identify what is this error and why is it thrown every time ?
Environment Details (Perl 5.8 and Unix SUSE)
Dump from Data Dumper:
$VAR1 = '
';
I am using various internal APIs, to update these records.. so I have modified my code to look similar:
sub main{
eval{
DB->updateRecord($value)
};
if($#){
Mail->SendMail(__PACKAGE__,$#):
}
}
package DB;
sub updateRecord{
my ($self , $value) = #_;
my $query = "update set column_value = $value ..<update query> ";
API->processQuery($query );
}
Does your code use warnings;?
The symptom your describing indicated that in your code you are passing die the string "\n". My guess would be that in your source you have a line that is trying to die with an error message but your error message was not initialized. It could be something like
my $error;
if (some_test()) {
$error = 'Some String';
}
if (some_other_test()) {
die "$error\n";
}
If some_test() passes but some_other_test() fails the die will report an error containing only a new line. It would also emit an warning if warnings are enabled.
Another possibility is a typo. If you don't use strict; the error variable might not be correct.
my $error = 'Some String';
if ($error) {
#note the typo (transposed ro to or)
die "$erorr\n";
}
Without use strict; this can be an easy mistake to miss.
I have the following script to update one of my FTP passwords every 15 days through a cronjob and e-mail the appropriate people after the attempt has been made. It randomly will fail and so I will run it again manually and it will work. I can't seem to find where it's going wrong.
The script is connecting to a local mysql database grabbing the login and password for an account and then changing that password on FTP. Everything is successful up until the changing the password part. Again it's random, sometimes it works, sometime it doesn't.
Thanks!
#!/usr/bin/perl -w
#
use DBI;
use Net::FTP;
our $dbh = DBI->connect('DBI:mysql:database:127.0.0.1','user','password') or die "Aargh $!\n";
$transquery=q{SELECT dest_login,dest_password FROM list where id=123};
$sth=$dbh->prepare($transquery);
$sth->execute();
while($co=$sth->fetchrow_hashref){
$login=$co->{'dest_login'};
$pass=$co->{'dest_password'};
}
$changeresult='FAIL';
$actionlog='';
$newstring='';
$upperchars='ABCDEFGHIJKLMNOPQRSTUVWXYZ';
$lowerchars='abcdefghijklmnopqrstuvwxyz';
$allowedchars='ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789##$';
$l=length($upperchars);
$newstring.=substr($upperchars,int(rand($l)),1);
$newstring.=substr($lowerchars,int(rand($l)),1);
$l=length($allowedchars);
for ($i=0;$i<6;$i++){
$newstring.=substr($allowedchars,int(rand($l)),1);
}
print "$newstring\n";
$actionlog .= "Setting Password for $login from $pass to $newstring\n";
$username=
eval{
$ftp=Net::FTP->new('x.x.x.x',Timeout=>480,Debug=>1) or die "Error connecting FTP $!\n";
$changepassword="$pass/$newstring/$newstring";
$ftp->login($login,$changepassword) or die "Error changing password $!\n";
#If we are here, time to update the password
$changeresult='SUCCESS';
$actionlog .= "Password successfully updated\n";
$transquery=q{UPDATE list set dest_password=(?) where id=123};
$sth=$dbh->prepare($transquery);
$sth->execute($newstring);
};
if ($#) {
$actionlog = $actionlog . "$#\n";
};
if($actionlog ne ""){
#print $actionlog;
#my $send_to = "To: someone\#example.com\n";
my $send_to = "To: databaseusers\#example.com\n";
my $sendmail = "/usr/sbin/sendmail -t";
open(SENDMAIL, "|$sendmail") or die "Cannot open $sendmail: $!";
print SENDMAIL "Reply-to: databasepassword\#example.com\n";
print SENDMAIL "Subject: Password Change Information [$changeresult]\n";
print SENDMAIL $send_to;
print SENDMAIL "Content-type: text/plain\n\n";
print SENDMAIL $send_to;
print SENDMAIL "Content-type: text/plain\n\n";
print SENDMAIL $actionlog;
close(SENDMAIL);
$actionlog='';
}
else{
#print "Nothing done this session\n";
USUW might tell you something. ( use strict; use warnings; )
Does anything print?
You don't do much error checking in the DBI part at the beginning, perhaps you're getting a connect error. AIX boxes used to have this problem of getting a client port that the system was unsure about whether or not it was in use. When that happened, it would just fail to connect to the database.
I finally fixed that problem for our scripts by examining the $OS_ERROR ( aka $! ) for that particular code ( Errno::EADDRINUSE ) and then waiting and retrying, with an exponential falloff ( wait 2 seconds, then 4, then 8 ... ).
If your script "dies for some reason" then it's important the script can tell you that reason. I would investigate the topic of error reporting in the various modules you are using.
For example Net::FTP allows you to pass a Debug => 1 switch, and then you'll see the whole conversation.
And I know that there is a whole lot more with DBI where you can get error reporting.