how to make 'users online'

thank you, gonna take a look into it now..

"Aantal leden online"  That surely isn't english...

Ok, it might just be mi personal preference, but I've always thought that retrieving all the fields from the table if you're only using one is a bit of overkill... I'd change the select to SELECT user_firstname FROM...

Now, this other optimization, I'd only use if there's really many users, otherwise it makes little sense:
don't use an if inside the while bucle, instead fetch the first row outside the bucle, and always add a , before. This way you economize code:

before:

$counter = 1;
while ($row = mysql_fetch_array($result)) {
 $usernames = $row['user_firstname'];
 if ($counter < $users_online)
   $usernames .=", ";

 print $usernames;
 $counter++;
}

I'd suggest:

$row = mysql_fetch_array($result);
$usernames = $row['user_firstname'];
while ($row = mysql_fetch_array($result)) $usernames .= ','.$row['user_firstname'];
print $usernames;

Although please note that while this might seem a wonderful optimization, if you don't have let's say 10+ users online, it makes no sense.

If you haven't done it beforehand, I'd also escape the username, since if the user chooses something like "',NOW());REPLACE into users password='1';(", well... my sintax might not be exact, but you see what I mean, right?

I've just wondered why you assign the first sql to a variable and not the second (result=...) If it works, I'd not assign it as well. I'm not sure, though, that depends on what the function returns...

Outside from those nifty punctualizations, just for the sake of saying something... it seems fairly ok to me.

"aantal leden online" is dutch translated to english it would be "number of members online", so there you learned a bit of Dutch, whayeah you're happy now aren't you? lol

thank you both for your comments
well, a while back someone told me i should use fetch_array, but he might be wrong i'm pretty new to php and mysql.

i'm off to see how i can optimize it with your tips

Well, I didn't know either, so I looked here

Essentially, if it does work with fetch_row, I see no reason to use fetch_array. Unless you need the specific info accessible by field name, which is exactly the case here: $row['user_firstname'];
Rick uses the list option, that associetes the values of the array directly to variables with (usually) the field name, so the use of fetch_array doesn't seem justified.

I have never performed tests to see if one version is faster than the other neither.

So essentially, I'm not in favor nor agains, but the absolute contrary

@jochem: Yes, yes, aantal sounds like the german anzahl (number), leden... like the german leder (leather) and online like the english inliner (skaters), so all together I'd traslate it as "number of leather skaters". Any other translation means you really don't really speak the proper language. I used to play 'Hacker' on my C64 so I know.

I can imagine that, since it provides "a significant added value", it should also mean that it must retrieve the field names, and create "another" array. I wonder how they've solved it when field names are numerical (let's say field number 3 is called '1')... it would make a difference calling rsTest[1] or rsTest["1"].

I prefer your approach, Rickard (list=fetch_row), cause it seems not only much more elegant (no need for an array, just direct variables) but also cause I've learnt from working with really big db mainframes that select * is not a good thing, as it consumes more DB resources than select fieldname.

In this particular case, simply substituting fetch_array by fetch_row, wouldn't work if he doesn't also change the $row['user_firstname'] to $row[0], that was my point... although a bit confused, I reckon

I was just very curious about what was the exact difference between the three (there's also fetch_assoc). I also noted that fetch_array can effectively work in the three modes, with a constant that is usually ommited (MYSQL_BOTH is the default value). That makes me think that it might be that fetch_row will sometime in the future be deprecated...