fenway

Try this: $sql = "Select name, task From 'table' where DATE(created)= CURDATE()";

What are you trying to update? The same record? Related records? Summary tables?

NO! Do not do it that way. In fact, you should NEVER be storing unix timestamps, that's evil. Change them to DATETIME fields if you can ASAP. However, since you already this problem, you should convert it to a date, then use proper date math: select count(*) from events where from_unixtime(event_date) > CURDATE() - INTERVAL 35 DAY When you switch to the right field type, you can drop the conversion function, and then benefit from an index on this column. I'll be more than happy to explain.

Actually, you should NEVER specify the UID that like with NULL... drop references both to the column and it's faked value.

There's also mysql_real_escape_string, which is the better function to use for your input values.

Post your table structure, some same data, and the query you are using.

I have no idea what you're describing... what kind of table is that?

Hi marcus.. the situation you described, while technically possible, isn't really how dbs were designed to work. The best way to do this is to have two tables: one for the issues themselves. It will have a UID field -- will will be the "issuenum" later -- as well as details about the issue (e.g. name, description, date, etc.). The other table will "issue_responses", or something like that. It will have a UID, a FK to the issue table, and a time field (or preferably, a start/end datetime field -- makes it more generic). And possibly a textual description. You simply insert a new record into this table every time someone works on an issue. There's no "hierarchy" to speak of here. There's no need to store totals in the db -- you can always calculate this whenever you need to. So, to mirror your example -- create these tables, and then you'd run the following statements: CREATE TABLE issue ( issue_uid bigint(20) unsigned NOT NULL auto_increment, created_on datetime default NULL, description varchar(250), PRIMARY KEY ( issue_uid ) ) ENGINE=MyISAM; CREATE TABLE issue_response ( issue_response_uid bigint(20) unsigned NOT NULL auto_increment, issue_uid bigint(20) unsigned NOT NULL, response_start datetime NOT NULL, response_end datetime NOT NULL, details varchar(250), PRIMARY KEY ( issue_response_uid ), KEY ( issue_uid ) ) ENGINE=MyISAM; # you wouldn't normally specify the uid here, but I want it to match what you describe -- you'd simply insert and use LAST_INSERT_ID() to get the newly created work order number INSERT INTO issue ( issue_uid, created_on, description ) VALUES( 23, NOW(), 'issue 23' ); INSERT INTO issue_response ( issue_uid, response_start, response_end, details ) VALUES ( 23, NOW(), NOW() + INTERVAL 4 MINUTE, 'still not resolved' ); INSERT INTO issue_response ( issue_uid, response_start, response_end, details ) VALUES ( 23, NOW() + INTERVAL 20 MINUTE, NOW() + INTERVAL 26 MINUTE, 'finally fixed' ); And so and so forth. I'm sure this is all very different than what you imagined, so let me know what doesn't really make sense and we'll take it from there.

I've talked about the value of NULL a few times over the years... maybe I should sticky a detailed discussion of this...

If you mean multiple categories per record, then the answer is "no" -- what you need to do is have 3 tables -- one of items, one of categories, and a 3rd relational table that links the two IDs in unique pairs. This way, each item can have multiple categories.

If that's the case -- and you want top 5 unique players -- you'll have to write an inner query to select the players (why are you grouping by name and not by uid?), and then join it back to the count query.

Doesn't the ftp program have an command log?

Or, don't get firefox, have an ondrag event handler write to a large TEXTAREA form input on the screen, and write out clientTop and clientLeft. Easy as 3.141459.

Nope... well, not with a db framework; if you knew all the column in advance, it would be trivial.

That's the structure -- two FK fields and probably a UID. You "link" them by insert a record that ties the two existing table records together.

You need a third table with ( pd_id, cat_id ) records.

OK... but fyi, it doesn't sound like you have a normalized db design, which may affect you in the long run.

well the shoutbox uses ajax and has tons of messages posted every hour i figured doing that might speed it up a little You can always archive it daily, weekly... but don't start having unnecessary write operations for table that's meant to be read all the time

You'd have to check each one and return a boolean of sorts: IF( field1 = 'abc', 'field1', IF( field2 = 'abc', 'field2' ) )...etc.. Assuming it can never be in two fields at one. I still don't understand why you have such a table.

I have no idea why you've chosen column names like that -- sounds like you're missing a table. But AFAIK, you can't make column names dynamic -- and for good reason.

Why would you do that?

Why would you not know where a value was?

You can't use DISTINCT with multiple columns... especially with IDs... it doesn't make any sense. As for the output, I don't really know what you mean -- you'll get the article category and summary for each one.

Yeesh... where's the rest of the query?

The rollback in mysql is not atomic across user activity, but rather across statements... so you wouldn't be able to unflag it days later... which is probably desirable.