fenway

Why 2 forms? Why not one big form?

define cancel.

You could always try the host the PHPFreaks uses... ;-)

The table doesn't "look" like anything. Query it however you desire for your output. And I have no idea what kind of relation there is between these fields.

Excellent -- good work. So let's look at the messages you got originally: You can see from this: UNIQUE KEY `topic` (`ID_TOPIC`,`ID_MSG`), UNIQUE KEY `ID_BOARD` (`ID_BOARD`,`ID_MSG`), UNIQUE KEY `ID_MEMBER` (`ID_MEMBER`,`ID_MSG`), KEY `ipIndex` (`posterIP`(15),`ID_TOPIC`), KEY `participation` (`ID_MEMBER`,`ID_TOPIC`), KEY `showPosts` (`ID_MEMBER`,`ID_BOARD`), KEY `ID_TOPIC` (`ID_TOPIC`) That the `ID_TOPIC` key is already contained in the `topic` key -- hence it's redundant. As for the id_member field it's complaining about, all the keys are different two-column indexes, so that's fine; and is the cause of the 3rd and final message. Personally, since it's third-party software, I'd contact them, and do nothing about it. But if you really want, you can drop the last key.

Because a float isn't an exact number.

Probably.. try clicking on that table from the list on the left. I never use phpmyadmin, that's why I have no idea.

1) WHERE description LIKE '%Peace% 2) Use a full-text index on this column.

We don't *mail* things on a forum, we post them in the original thread! As for the OP, I would guess it a precendence issue... try this: WHERE ( hc.follow_up_date BETWEEN CURDATE() - INTERVAL 7 DAY AND CURDATE() + INTERVAL 7 DAY ) AND ( hm.follow_up_date BETWEEN CURDATE() - INTERVAL 7 DAY AND CURDATE() + INTERVAL 7 DAY ) AND ( ip.follow_up_date BETWEEN CURDATE() - INTERVAL 7 DAY AND CURDATE() + INTERVAL 7 DAY ) AND ( vc.follow_up_date BETWEEN CURDATE() - INTERVAL 7 DAY AND CURDATE() + INTERVAL 7 DAY ) Of course, you should be using a sql string, not curdate() so that the query cache is utilized.

No, you're not clear.

You wrapped it in PHP, not code. MySQL has an SHA1() function too, so a simple update statement will work:

See that little sql button on the top-left? Run the command from there.

If you run a SHOW CREATE TABLE LIKE `smf_messages`, you'll see the duplicates -- since UNIQUE is just a special case of INDEX, there's no need to have them both. You can simply drop the exra ones. Post the output and I'll tell you what to do.

Precisely.

The "index problems" you speak of would just represent a slight performance hit... while I'm surprised that these indexes are duplicated, it shouldn't cause the error you describe.

And you should be charging based on how much it's worth.

The robust way to do this is as follows (untested): SELECT n.tag, n.order FROM nav_directory AS n JOIN ( SELECT MAX(order) as MAXorder FROM nav_directory ) AS sub ON ( sub.MAXorder = n.order ) Of course, you could add as many conditions as you wanted. Don't forget about the boundary case; you may want an order by, too.

You can insert anything you want every N characters... no conditions.

I'd prefer to see: select t1.tag ,t1.title ,t2.team ,t1.order from table1 t1 join table2 t2 on t1.teamID=t2.id

These are mysql commands -- you can run them from anywhere.

I don't think you do.

It may be "solved", but the issue was joining the same table twice with an alias on different conditions.

You can lose a connection to a remote server at any time.

Move the SET after the last join before WHERE.

Your examples aren't equivalent.