fenway

Easiest way is to convert this into a select with proper join syntax first, then convert to either of the valid delete syntaxes.

Just run a query, get MAX(score), GROUP BY user_id, ORDER BY score DESC LIMIT 10.

Not to mention that there's no column called 'f_id'. And expecting a solution in 2 hours in unreasonable.

Other than the trailing semicolon in the query that shouldn't be there, this is clearly a DB class. How do you know you're getting any rows back?

NULL options? You mean rows or fields?

Agreed... I believe this may have been spawned by my post to another thread.

In 5.0, you can roll your own text parser and use it for fulltext searching. Otherwise, it's tricky.

Drop the where clause -- switch to count(*). Assuming you get back non-zero, start adding it back piece by piece.

See here -- sounds like to have to fix the FK issue first.

You have the wrong password. Or you're connecting from a new/different host.

It's much better to use JOIN -- no issues with comma precedence changes, no missing join conditions, clear where clauses for filtering only, etc. Also, makes it trivial to switch join type (inner vs left) in a second.

Sure... don't use integers, or prefix them with underscores.

The details of the attack aren't relevant... suffice it to say that it took some very skilled admins a while to figure out.

MySQL can do wildcard searches... but it's not appropriate here.

That's quirky because you're using integers as hash keys... associative array in JS are funny.

MySQL doesn't have "lists". Yes, that too....

"Implicitly" is precisely the problem: SELECT * FROM Saved_product AS sp INNER JOIN profiles AS p ON ( p.email = sp.email ) INNER JOIN ordered_products AS op ON ( sp.ProductID = op.ProductID ) WHERE sp.ProductID = 1111002 This will keep you out of trouble.

Include ones with those lastnames?

I assume you meant count(*) in your code snippet.

No problem... keep watching that EXPLAIN. There are a few stickies on this issue that I've posted.

What's wrong with "delete"?

I see lots of NULLs for key usage! No indexes... Add an index to items.realid and completed.userid

IN() works with comma delimited strings.

Could we see the EXPLAIN too?

A derived table IS NOT a subquery in the traditional sense, since it's uncorrelated.