new quandary

[Gilead]

I'm attempting to have the last_login field updated with the date and time when an admin logs in. Not quite sure what is wrong.

$date = time();
// inbetween here, I'm deleting the number of attempts, which seems to work. I added 2 in manually via cpanel and ran the script and checked. The attempts were gone.
$sql = "UPDATE $admin_table SET last_login = '$date' WHERE username = '$myusername'";
$result = @mysql_query($sql) or die(mysql_error());

echoing $date works 1322590641
echoing $result yields 1
echoing $sql looks like it's right, it just isn't entering the info for some reason.

The mysql field last_login is set for timedate type.
Any thoughts?
Thanks!

[edited by: Gilead at 6:22 pm (utc) on Nov 29, 2011]

[httpwebwitch]

I don't see anything obvious

drop the "@" before your mysql_query(). That's not the bug, but it's a bad habit to put "@" before things for no reason.

basic debugging technique:

echo $sql; // put this right after the line where you build the query.

it'll show the query. Then you'll see if there's something obviously wrong with it.

And by losing the "@", you might see the error output by mysql_error(). That will be helpful for sure.

maybe you're putting a time() into a database column that isn't the right type?


another thing... once you have the query working... do you know what will happen when a username is "seamus_o'malley" - with a single quote/apostrophe in it? Try it. ;)

[Gilead]

No difference when removing the @. That's what I wondered about too- if the type was correct, so after some research, I used time() which is supposed to be a direct mysql timestamp.
echoing $sql came out just fine, it just isn't doing it for some reason.

in this case, since it wasn't in the admin database, it went to the wrong user name section.

[Habtom]

What is the field type?


Change this:

$sql = "UPDATE $admin_table SET last_login = '$date' WHERE username = '$myusername'";

To this:

$sql = "UPDATE ". $admin_table ." SET last_login = '". $date ."' WHERE username = '". $myusername."'";

[Gilead]

field type for the database is datetime

Still no joy. It did not update the field. Should I just change it to text?

[httpwebwitch]

oh, then you probably want this instead.

$sql = "UPDATE ". $admin_table ." SET last_login = '". date("Y-m-d H:i:s") ."' WHERE username = '". $myusername."'";

[Gilead]

YES! That is exactly what I wanted. Thank you!

Why all the 'escaping?' I see it's needed on the date command because of the quotes, but I'm confused why elsewhere.
Thanks!

[httpwebwitch]

lesson: a "datetime" field in mysql expects to get a date formatted like "2011-11-29 13:58:00", as a string. time() returns a number (unix timestamp)

the 'escaping' is just a style thing. when gluing together a long string, some people like to chop it up and use the dot operator

$a . " plus " . $b

and some people are happier using substitution in double-quotes

"$a plus $b"

Personally I almost always chop strings up and stick them together with dots. That's my way. Habit.

[Gilead]

:-) Thanks again!

[rocknbil]

$result = @mysql_query($sql) or die(mysql_error());
....
echoing $result yields 1

Do you know what @ does? It suppresses errors. There is no *real* reason to ever use it in mysql queries and makes them harder to debug. You **could** use it anywhere

$var = @file_get_contents($path);

When you execute a mysql select query, $result will hold a resource (try doing a var_dump on one - it won't be what you expect.) When you do anything else - insert, delete, update, create . . . it returns only true or false (1 or 0). So printing 1 only means "we were able to execute." It doesn't mean it actually did anything when it passes to the database layer (as you saw,) just that it executed successfully.

So, you only need to store $result on select queries.

mysql_query($sql) or die(mysql_error());