in reply to Re^3: Premature end of script headers issue
in thread Premature end of script headers issue
I still don't know what it means but the real question is why this could have worked yesterday and NOW it has this problem (whatever it is). It worked, then it stopped working for a day and no one knew what happened. Then it worked for a few days and now it's back to the same problem (I assume it's the same problem).fetch() without execute() at login.cgi line 98.
What is the error asking for now?
Thanks very much for your help.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^5: Premature end of script headers issue
by CountZero (Bishop) on Jan 10, 2005 at 21:35 UTC | |
Change the following to It is a more secure way of doing things (protects against arbitrary SQL code injection attacks -- has nothing to do with your present problem) The only reason I can see why your script sometimes runs and sometimes doesn't run is in a combination of inputs which skips the execute code. Are you sure all the if ... then ... else ...-logic is OK? CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law | [reply] [d/l] [select] |
by Anonymous Monk on Jan 10, 2005 at 21:48 UTC | |
I rewrote the order of the script and I changed the if/else thinking that might be catching (or not catching) if the case may be. Now I'm certain everything is loading in the order it should but it still hangs up when it hits the test print #4. The code really isn't that long or complex and I've been working on getting this to work since about 10am this morning. The entire script is posted below incase you or anyone else can come up with any other suggestions. Thank you for your help.
| [reply] [d/l] |
by CountZero (Bishop) on Jan 10, 2005 at 22:18 UTC | |
I do have some trouble with the $sth->rows To get the number of records returned of a select statement one should not rely on the rows function. For one it is not guaranteed to work on all databases and for second its use should be restricted to non-select statements. From the DBI-docs: rows Running a SELECT count(*) ... will work and is very fast. Anyhow, if I understand your code correctly, you only expect one record anyhow (or none if the log-in failed). So why don't you check if the result of the SELECT count(*) ... is 1, in which case you retrieve the data to set the cookies, or in all other cases (no records or mulltiple records) you raise an error. CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law | [reply] [d/l] [select] |