fenway

I guess the question I have is why you care if it updates "nothing".

Oh... I see what you're doing. You're trying to merge the logic for create & update. That's less than ideal in the long term.

That's because you're mixing comma and JOIN operators -- and now you're using mysql 5. The precedence of the operators has changed. Easiest way to hack this for now is to wrap all of the tables "joined" with a comma in parentheses; long term, you should properly rewrite the query..

If that table doesn't have a lot of rows (i.e. 50% match), FULLTEXT doesn't work well.

Then use LOCATE().

It's sounds like you're asking how to write a php script.

Top-right?

Well, if you're doing a dumb string match, then sure, you can see if substring matches are true or false for each column.

Seriously?

You're talking about locking -- there are optimistic and pessimistic versions.

That's a PHP error.

Yikes... hard to follow that... I'd re-write in proper ansi-join format (using INNER JOIN and ON clauses).

Sorry, now I'm really confused -- you're setting the old values to the new values, and they're exactly the same, so of course nothing has changed.

Define "twice" -- are you sure there is a many-to-one relationship/

ENUMs work too.

Not enough information -- and don't ask for "urgent" help, it's against the rules -- consider this a warning.

That's because it's an inner join -- you want UNION.

Match how?

PKs should usually be integers.

I don't see a call to mysql_select_db().

Confirm that command-line interaction with mysql is ok.

Can't you just see if the column value changed?

Write them as though they were sub-selects.

And then you could still initialize the user variable in the query as I suggested earlier.

OK, here's the issue -- the GROUP BY clause. The counter makes no sense this way. You have duplicate rows for the same user value -- why?