.josh

if(ALL_LOWERCASE){ $_POST['user'] = strtolower($_POST['user']); } What are you expecting this to do? It reads: if the constant ALL_LOWERCASE exists, make that variable lowercase.

Or maybe microsoft altered their own hotmail code to break if it detects chrome, in an attempt to give them a bad name? Or maybe they aren't that malevolent. Maybe they alter their code to cater to different browsers, as lots of sites do, and they just can't seem to get it right. I mean, what do you expect from a company that makes a browser that fails to adhere to standards so hacks constantly have to be made to cater to it? I mean, that's like when people around here were bitching that phpfreaks.com breaks in something less than IE7. I heard people blaming the site for not catering to the browser, not the other way around. Seems like a double standard...

Let's break it down... QueryA update table set column = 1 where column = 2 wherever column equals 2, set it to 1 Simple enough, right? Okay let's add on the IN(...) QueryB update table set column = 1 where column in(1,2) wherever column equals 1 or 2, set it to 1 Using IN(...) is the same as doing two QueryA's... update table set column = 1 where column = 1 update table set column = 1 where column = 2 Well that obviously won't work all by itself. First query is just pointless, and the 2nd query only switches one number. We need to somehow make column = 2 in the first query. So let's throw the case into the mix: update table set column = case column when 1 then 2 when 2 then 1 end where column in (1,2) CASE column WHEN 1 THEN 2 WHEN 2 THEN 1 END If column equals one, then set it to two. If it's two, then set it to one. So that's (kind of) the same as doing this: update table set column = 1 where column = 2 update table set column = 2 where column = 1 Only you can't write it in two queries like that, because if you have for instance this: Column 1 2 When you run the first query, you get this: Column 1 1 Then when you run the second query, you end up with this: Column 2 2 Which is not what we wanted at all. That's where the magic trick comes in with combining the two queries into one query, using a combination of a case...end and in(..). We exploit the database's affinity for making temporary variables to keep stuff sorted out. When the "first query" is executed (the query will run once for each variable in the in(...) ): update table set column = 1 where column = 2 we do indeed turn Column 1 2 into Column 1 1 But since the query isn't done yet, it created temporary vars (possibly a whole temporary table. You never can tell for sure what goes on inside the black hat...). So when it gets to the second number in the in(...), it is still basing the "second query": update table set column = 2 where column = 1 off of the original, unaltered data (the temp vars/table/rabbit keeping track of stuff on his fingers), so we wind up going from Column 1 1 (what we got from first iteration) to Column 2 1 for that 2nd iteration. Understand that the actual table is being altered, each time the query is executed (for each value in the IN(...) ); it's just using this temp vars/table as a reference, to keep track of stuff. That's why if you index the column as something like auto_increment or primary_key or something that demands unique row data, it will scream at you about having duplicate data.

I just assumed he was closing out his php tag to put some html inside the loop or something. You know what they say about assuming...

No, there's nothing you can really do to change that. There's no way to put your form, validation, and a 'logged in' message in the same script, without experiencing this session 'jet lag'. You would have to at the very least split up your validation portion into a separate script and redirect back to this original script upon success.

<?php if ($_GET['cat'] && $_GET['location']) { $cat = (int) $_GET['cat']; $loc = (int) $_GET['location']; $sql="select * from `inputinfo` where category='$cat' and location = '$loc' order by rank asc"; } else { $sql="select * from `inputinfo` order by rank asc"; } $rez=mysql_query($sql,$dblnk); while($row=mysql_fetch_array($rez)){ $id=$row['id']; ?>

use $_SESSION['Username'] in your query

so..you didn't write that code, and you can't even tell me where or how you used ob_start? Did you read the manual entry for ob_start?

Show your code that makes that message appear.

You don't assign anything to your session vars unless they aren't set AND the login info is posted and vars verified through db. So when you first submit the form, first condition that checks for session var still evaluates false, because your script hasn't verified the posted info and assigned anything to them yet. When you post the vars and it checks out and assigns session vars, they will exist the next time around (refresh).

maybe you didn't use ob_xxx right. It's not in your code, so there's no way to tell.

<OT> $x = "one"; $string = "the number $x"; // output: the number one $string = "the number '$x'"; // output: the number 'one' $string = 'the number $x'; // output: the number $x $string = 'the number "$x"'; // output: the number "$x" </OT> nothing came out when i debugged it..i get no errors but the inventory doesnt show the item in my users_items table Okay so you are telling me that when you do this: $otherusername = "SELECT item FROM users_items WHERE username='".$Username."'"; echo $otherusername; Nothing echoes out?

well you were supposed to echo it and post what it printed, for debugging purposes. Putting it inside your while loop is not the most ideal place to do this, though it would serve the purpose.

And how exactly does that work better? There was nothing wrong with the way it was before. Variables are parsed when they are put inside double quotes.

echo $otherusername

As someone who officially represents the Wikipedia organization, I can tell you with great authority that the reason it is...wait, did you say Wikipedia? Oh, I thought you said Dickipedia. Wikipedia is that way:------------->

I don't see anywhere in that code where you are assigning anything to $Username

Umm are you sure? The whole point of ob_start is to not have output echo until you use ob_end_clean type function to paste it to the screen. no, the whole point of ob_start is to keep the output in a buffer, so that if you have for instance, headers added to the output later on in your script, it will send it in the correct order, so you will not get headers already sent errors. Unfortunately, people use ob_start as a bandaid to fix those errors, instead of doing the logical thing: reordering their code to begin with. <?php ob_start(); echo "blah blah blah"; ?>

Couldn't hurt, but IMO a strong portfolio outweighs it any day.

Like I said, put at the top of your output a regular html header that specifies cache control: no-cache. That might work.

Refreshing automatically resends previously posted data. That's why it's entering more stuff into db. You can check if it's set or != '' and everything else and it will still evaluate true.

..or maybe you aren't using it correctly?

not with php. script is parsed server side and sent to client after script is done executing.

That's a clientside thing. Possibly sending a no-cache header might work.