Being no iAnywhere staff member, obviously I can't claim whether this is intended behaviour or not.

That being said, I suggest that the current behaviour should be documented, as changing rows by ALTERing the table seems quite similar to changing rows by updates. Therefore I guess my question is not too uncommon.

However, I bet in most cases DEFAULT TIMESTAMP is used to track changes by ordinary DML statements - in the sense of "when was that row modified at last". It's usually meant for changes by users / application programs.

When doing clean-up or other administrative tasks in such tables, I often want the particular DEFAULT TIMESTAMP column to stay unchanged to "hide" my adminstrative changes. That's easily done with an UPDATE statement that sets the DEFAULT TIMESTAMP column to its current value. And as usually, if the UPDATE statement specifies a value for this column, the default value isn't applied.

So, with UPDATE, I'm quite free to choose whether I want DEFAULT TIMESTAMP to be updated or not.

However, if ALTER TABLE would change the DEFAULT TIMESTAMP, there wouldn't be a way to prevent this change (at least without an enhanced syntax). Therefore the current behaviour seems reasonable as

1. table alterations (as truly administrative tasks) might usually not be meant to change the timestamp and

2. in case the timestamp should be changed, one can still achieve this by adding an according UPDATE STATEMENT afterwards.

3. Furthermore an ALTER TABLE with impact on DEFAULT TIMESTAMP could raise problems in replication/synchronization setups: In such setups, ALTER TABLE is usually done at different times at different locations for the same (distributed) rows, and that would lead to multiple changes of the timestamp column for the same row. That might be difficult to handle. At least, such a behaviour doesn't seem senseful to me.