|
Re: PostgreSQL UPDATE
by merlyn (Sage) on Jul 18, 2001 at 23:32 UTC
|
I don't like that you are looking at both $ENV{QUERY_STRING} and param. If this is a GET, then QUERY_STRING is gonna be ugly, not just the old_email. If this is a POST, then QUERY_STRING will be empty on compliant browsers, and it all shows up in params.
Time to redesign your calling interface.
-- Randal L. Schwartz, Perl hacker | [reply] |
|
|
hmm. What suggestions do you have for Replacing $ENV{QUERY_STRING} and param? What are the problems with using these?
| [reply] |
|
|
| [reply] |
Re: PostgreSQL UPDATE
by lestrrat (Deacon) on Jul 18, 2001 at 23:40 UTC
|
I'd strongly suggest using RaiseError, since
Error handling is so much easier that way. Plus,
you're not making sure that $sth->execute actually
worked or not
I have a feeling that if you set RaiseError, then
you would start getting fatal errors... then you can
debug
As a side note, I personally like to use AutoCommit => 0 as well, just so that I know exactly what I'm doing...
| [reply] |
|
|
| [reply] |
Re: PostgreSQL UPDATE
by Cubes (Pilgrim) on Jul 18, 2001 at 21:29 UTC
|
I had similar problems with PostgreSQL (silently failing inserts/updates). Mine ended up being permissions in the database -- be sure you do the appropriate grants to whatever user you're connecting as. | [reply] |
Re: PostgreSQL UPDATE
by TheoPetersen (Priest) on Jul 18, 2001 at 23:10 UTC
|
l_name = '$l_name',
extension - '$extension',
phone = '$phone',
Shouldn't that be l_name = '$l_name',
extension = '$extension',
phone = '$phone',
I would think you'd get an error back from the prepare call, but then, I've been wrong about databases doing obvious things before :)
| [reply]
[d/l]
[select] |
|
|
Phew. Now that is definatly a problem. Thank you
| [reply] |
(ichimunki) Re: PostgreSQL UPDATE
by ichimunki (Priest) on Jul 18, 2001 at 21:50 UTC
|
Can you show us the Do_SQL() subroutine? This is a key to your problem..
Other things I would suggest working on: not using $ENV{QUERY_STRING} at all if you can help it, putting a content-type header on your HTML output, using strict, and avoiding globals. | [reply] |
Re: PostgreSQL UPDATE
by TheoPetersen (Priest) on Jul 18, 2001 at 22:05 UTC
|
| [reply] |
|
|
What would that look like?
| [reply] |
Re: PostgreSQL UPDATE
by thraxil (Prior) on Jul 18, 2001 at 22:08 UTC
|
have you tried running the SQL by hand in pgsql?
i've seen postgresql have problems with silently dropping inserts after i had inadvertantly shut it down improperly. the problem went away after i shut it down nicely and restarted it.
i'd also strongly recommend using DBI's prepared statements with placeholders instead of trying to escape the input yourself. keeping track of nested quotes, backslashes, and misc. characters is trickier than it would seem at first and is best left to DBI. if your '&filter' function isn't handling something correctly, it may be munging $old_email into something that doesn't match any rows in the database. that would certainly cause it to not update anything and not print an error message either.
anders pearson
| [reply] |
Re: PostgreSQL UPDATE
by lestrrat (Deacon) on Jul 18, 2001 at 22:17 UTC
|
I think we need to see Create_DB_Connection() and
Do_SQL()...
From my experience, these problems tend to occur
due to some implicit behavior that the user is unaware
of -- so we need to know how you created the $dbh
variable, and how you talk to the DB
| [reply] |
Re: PostgreSQL UPDATE
by nlafferty (Scribe) on Jul 18, 2001 at 22:40 UTC
|
I can't believe the response time in this place. I love it.
BTW, My insert statment works fine so i did not include that script. I tried to compare the two but nothing seemed wrong there.
##########################################
## Create a connection to the database. ##
##########################################
sub Create_DB_Connection{
use DBI;
use DBD::Pg;
$DSN = "DBI:Pg:dbname=blah";
$user = "blah";
$pw = "blah";
$dbh = DBI->connect($DSN,$user,$pw)
|| die "Cannot connect: $DBI::errstr\n" unless $dbh;
return;
} # End of Create_DB_Connection subroutine.
##########################################
##########################################
## Executes the SQL command and then ##
## returns to the calling area of the ##
## program. ##
##########################################
sub Do_SQL{
eval{
$sth = $dbh->prepare($SQL);
}; # End of eval
# Check for errors.
if($@){
$dbh->disconnect;
print "Content-type: text/html\n\n";
print "An ERROR occurred! $@\n<P>";
exit;
} else {
$sth->execute;
} # End of if..else
return ($sth);
} # End of Do_SQL subroutine
#################################################################
| [reply]
[d/l] |
|
|
Your eval won't catch anything unless you set the RaiseError attribute on your database handle:
$dbh = DBI->connect($DSN,$user,$pw, { RaiseError => 1 })
|| die "Cannot connect: $DBI::errstr\n" unless $dbh;
Otherwise, check the results of all of your $dbh calls for undef and do something with $DBI::errstr yourself. | [reply]
[d/l] |
|
|
| [reply] |
|
|
Forgot the filter code. All three of these are contained in common.sub
####################################
### Filter - Gets rid of ###
### characters that screw up the ###
### program. ###
####################################
sub filter{
$_[0]=~s/\'/\\\'/g;
return $_[0];
} # End of filter subroutine
#################################################################
1; # Required or won't work!
| [reply]
[d/l] |
