I have a form on a system I am maintaining that works fine most of the time, but sporadically spits out an error. Users hit the back button, only to find that the data they had filled in is no longer in the form (but sometimes it stays).
The system is using latest RH9 apache2, perl, msql2.
Other forms on the system work fine.
Some details:
Here is the most common error on screen (in the browser) that I can reproduce:
parse error at line 1 near ", ,"::S1000
However, according to error_log for httpd, the error is on line 130 of the cgi:
$sth->execute;
The $sth is executing an insert query to insert all of the values from the form into the msql database. I *think* the parse error is referring to this query. So there's something wrong at the time of the query.
The query lists its values in this manner:
,\'$form{pub_title}\', # so a hash ref
but some are referenced directly as variables
,$num_pages,
which were given the value of the $form{num_pages} earlier, and then checked with eval().
if ($num_pages){
$num_pages = eval($num_pages);
}
But if I comment out these eval lines it does not change the behavior of the page. Seems like old debugging cruft from a previous coder.
I don't see this doubled comma from the parse error anywhere in the code, and the query syntax seems kosher, so I guess maybe it's getting into one of the variables somehow? I'm definitely not putting it into the form.
To summarize my questions:
--Where can I read the code for a good example of such a cgi page? (I am already studying what the oreilly books have to offer)
--Could this be caused by a variable being null?, hence , , instead of , value ,?
--Any debugging advice for forms? i.e. best way to check/correct form data as it submits, so that the db on the receiving end will be happy?
Thanks
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
