[snip] The issue with timestamp is this: You can only have one timestamp with a default of the current date.
My app has two fields in one table Created_date datetime default now() Last_update datetime default now() This doesn't work with timestamp because timestamp doesn't support two columns with default current_timestamp. Additionally, it looks like if you default to current_timestamp then any time the record is modified, that value is changed. [/snip] Well, George, you never mentioned that this was your problem. And you would run into the same problem, given your definition above, regardless of database (unless the database product has a hack to account for it, I am not aware of any). But it is simply fixed. When creating the row you include as your value for Created_date, NOW().... INSERT INTO tblFoo (Created_date) VALUES (NOW()) ...and then you never modify the Created_date again. The column with the timestamp will continue to update properly when the record is UPDATED. [snip] While tinker-toys were wildly popular (I had them), they are wholly unsuited for large scale building projects. [/snip] I disagree. As shown by this link, a computer desk has been made from tinker toys. http://www.charm.net/~jriley/tinkertoy.html :) As far as MySQL is concerned it has been documented that there are more than several large scale database application being utilized today, including projects at Fortune 500 companies. I personally manage several MySQL databases containing 100's of millions of records on OpenBSD and Linux systems. I have seen examples of MySQL databases larger than the ones I am intimately familiar with. There are several folks on this list who operate MySQL databases for large scale projects. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
