fenway

I don't understand.

What you need to do is get the max entry_id for each "set", then join this back to the original table.

The only way to make the table name dynamic is to use a stored procedure.

I'm confused... mysql grant table easily handle wildcard IPs.

Not sure... those don't look like mysql errors.

Why do this in the db?

Open that .sql file and look at line 1.

There's a whole sticky dedicated to this topic on this forum.

VARCHAR is 65K in mysql5.0.3+ -- much better choice than TEXT. Aside: the 5.1 refman page is still wrong on the mysql docs.

I think I understand now... if you have a unique index on your destination table, then an INSERT INTO... ON DUPLICATE KEY UPDATE... will allow you "overwrite" all the entires. Of course, you'll have to use a derived table to get the most recent first.

Well, MySQL doesn't know that... so you'll have no choice but to do this in PHP.

Why?

Perhaps you should look at InnoDB ACID transactions.

Other than the missing column list for TABLE_B, not really... could you post some sample data & table structures?

Sorry, I entirely missed that when I read the query... my bad. When there are const join conditions, my brain has issues. Generally, I write those as follows to make my brain hurt less: SELECT a.fvalue as fname, b.fvalue as lname, c.fvalue as empID FROM user2 AS a JOIN user2 AS b ON (b.uid = a.uid AND b.fid = 2 ) JOIN user2 AS c ON (c.uid = a.uid AND c.fid = 3 ) WHERE a.fid = 1 AND a.uid = 2

To each his own... but if I'm not using an ON clause, then I like to be explicit so that I don't think it's a mistake.

I never used "JOIN" as a bareword... it's always INNER, LEFT, or CROSS. The first two require (or should, IMHO) an ON clause -- so I expect to see one right away. The last one doesn't -- I use it when trying to find multiple matches in a many-to-many table -- so I use CROSS JOIN to indicate that the specified value will be in the where clause. Basically, my rule is like this: if the "join" compares two DB fields, it goes in an ON clause; otherwise, it goes in a WHERE clause while referencing a constant (e.g. for CROSS JOIN). Obviously, LEFT JOIN is sometimes an exception. Besides, why not stick to standard SQL whenever possible?

Using CROSS JOIN makes the purpose of the JOIN explicit....

MySQL handles them quite differently... and VARCHAR acts like CHAR in many temporary operations, so space does matter for performance. That being said, if you need to store large amounts reguarly, use VARCHAR(65k).

I'm very confused.. .you're using GROUP BY (again, no point for DISTINCT) -- so what do you think it's going do? Import all the data first, then aggregate it!

Did you try using mysqli_multi_query()? I'd read this PHP bug report too.

I will say again -- a few lines of php to check the current time both on display of the page and on POST will solve your problem.

Don't use LONGTEXT... VARCHAR in MYSQL5 can store up to 65K, which is usually sufficient.

Huh?

If you have old data stored in another collation, then yes, you have to fix that.