Rüdiger Mähl wrote: > > > "Flemming Frandsen" wrote: > > > > That has exactly the same problem as the first case, except: > > The timestamp is the time the change took place. > > vs. The id is the counter value when the change took place. > > > > The counter is simply an irregular timer in this case. > > > > You would have exactly the same problem with earlier > changes showing up > > after the later changes, so you would be in trouble anyway. > > ACK. > > Ok, the only thing I can currently think of is changing the > trigger into application logic. The client (or logic) inserts > into table changelog when having committed its work and uses a > timestamp (or STAMP) from the database server to keep > the correct sequence.
But then the client has to remember all changes done during the last transaction to insert them into changelog.... Usually applications are not able to do so. Elke SAP Labs Berlin
