fenway

Just UPPER() each part of the replace.

Yes, I know that... I mean if you want to "get it back" on another page you need to create continuity -- which means storing something you can use to get it back.

Yiesk... why are you corrupting those dates? Leave them as proper YYYY-MM-DD and you life will be easier.

Also, take a look at the rules/TOS -- marking threads as "urgent" isn't going to help.

You might want to TRIM() that, too.

1 open/close per page should do it.

FYI, that's only guaranteed to work for single-table update statements.

Perhaps you should read though the stickies first....

One datadir = one drive. You can't "span" drives with the datadir options. Why not use LVM?

You need to properly store your dates using MySQL's DATE column type. You can use STR_TO_DATE() to fix this with a single update statement, and also use this function to format your form input (though a proper date picker won't have this issue whatsoever).

It's barely 2 minutes... I'm sure there's something else on the interweb that can entertain you for this long.

Oh, there are plenty of ways to workaround this... they're just all bad ideas.

Yes, you really DO -- that's exactly how this should be represented in the database.

I don't know what you mean... somehow you have to store the newly created news_id somewhere.

Which mysql version?

What does "not work" mean? Error? Unexpected output? Please clarify.

You can specify a datadir for each instance of the server, but I'm fairly certain you can't do this on a DB level.

SHOW GRANTS should work in the older version, too.

This is also collation-specific.

I think you're asking about LAST_INSERT_ID().

You can also use "NOW() - INTERVAL 5 HOUR"..

(2) is much less error-prone than (1). And to answer your 2nd question, it's simply easier to handle downstream

What do you expect us to do with that?

You need to keep track of the news_id in your session.

If you're talking about duplicating a field, then "no".