fenway

With a for loop, and a string containing 26 letters.

If you're trying to restrict the results, then yes, what you have will work... just recognize that you shouldn't be including columns that aren't being searched.

Do you mean AND or OR?

Which is why I suggested an UPDATE to patch everything You should be doing that before writing it to the database table

Well, you can specify a column list to match the # and type... but in your case, it sounds like you want them all? If so, you might have to get the "super-ordering" first just with id, table and date, and then feed that back... rather ugly.

( first query ) UNION ( second query ) ORDER BY .... Make sure you have similar numbers of columns, and all the types match up.

You don't want to join the tables in the mysql sense... you can to combine the result, with UNION.

phpmyadmin does have some backup functionality, AFAIK.

You get query failed? What does mysql_error() say?

No, I dont' get it.

Perhaps because DISTINCT isn't a function?

REPLACE won't do anything without any unique/primary index.

No... you'll have to run sql commands (SELECT INTO OUTFILE) or mysqldump.

You may also want to have a look at this... I'll probably add this to the stickies at some point.

This generally has to be done at the application level, where you build your where clause .. but in this case, it should evaluate to %% if blank, which although slow, shouldn't "fail".

Ha... can't up your post count ;-) I've seen other versions with HAVING, etc.... but this is the cleanest, IMHO.

But REPLACE changes the UID, and issues an implicit DELETE... not good.

INSERT INTO... ON DUPLICATE KEY UPDATE....

There are a variety of ways to do this... all of them require you to find the uid of the po record with the lowest price *first*, and then join them back. SELECT p.*, po.cheapest FROM product AS p LEFT JOIN ( SELECT product, MIN(price) AS cheapest FROM product_options GROUP BY product ) AS po ON ( po.product = p.id )

Be careful with this... if it's for a web app, you generally can use a single mysql user.

If you're necessarily going to be iterating through all of them anyway, then a single db call is often more efficient.

We appreciate your efforts... but many of the mods have addressed issues of a similar vein the past, hence the tone.

Did you wrap your first code snippet in parens? Sounds like an order of precedence issue. BTW, that means it's a PHP issue, not mysql related.

You should have these as proper DATETIME fields in the database! You can easily add another column, issue the relevant update statements using the format string you've created above, and then you never need to do this again. It will be much faster. As for the second question, you can use DATE() to trim the time part.

The intential of the lock is not to ignore the suggestion... but simply to indicate that the suggestion is no longer relevant for discussion, since it has been rejected, for lack of a better term. Most of the time, it's because the same suggestion has been raised time & time again... our answers are simply not going to change. New suggestions are, of course, always welcome.