Actually Strataframe has the option of using a rowversion int for table built into the business object's collision handling and I've taken to using that.

>>>>Because the server is where the data is and is the only constant. Workstations may have different times either because their clocks aren't synced with the server or because they are located in different time zones. But server time means something to the database itself and will not depend on who generated the timestamp.
>
>>>That I understand and agree with. What I was questioning was why every table should include a last-updated column.
>
>>Collision detection? Why shouldn't it? It is a timestamp, no? Based on datetime but not actually a datetime.
>
>Here I disagree on the method - reason is my guesstimate of the "stability" of the abovebolded. For collision detection / update / backup needs I prefer a lastWriteCount column based on 8byte integer for the whole table. IMHO are the dangers of corruption of the "constant sources" smaller on a system table counting the writes to each table and the minmal danger of count roll over (you would have to write A LOT of times to the rows involved) and possibly needed fixes compared to a server getting a wrong time set - that is for most biz apps, not speaking of rollover tables used in automatic high speed measurements. It is a hit on possible write speed, but most apps I am involved with are not problematic in the write-area. Both methods have their drawbacks...
>
>Changetime and ChangeUser are most of the times useful and should be implemented just as a precaution against future needs and consistent table design if not needed already IMHO. CreateTime and CreateUser I implement either for all or none of the tables as well: sometimes there is no biz value in such fields.
>
>my 0.02 EUR
>
>thomas