|
Hi Dieter,
The row change timestamp is a TIMESTAMP(6) type, and is not guaranteed to
be unique. That is from the SQL reference:
"For an identity column or row change timestamp column, the database
manager inserts or updates a specified value but does not verify that it is
a unique value for the column unless the identity column or row change
timestamp column has a unique constraint or a unique index that solely
specifies the identity column or row change timestamp column."
Regards,
-Arco
2017-12-28 16:14 GMT+01:00 D*B <dieter.bender@xxxxxxxxxxxx>:
... interesting debate, if I understand the FM correctly, the ROW change
token might change, without the current row has changed, so I would not
recommend to use it. regarding the row change timestamps, I don't find the
finite information, wether it is documented unique, or maybe most likely
(that would not be enough to me). The problem I have with both variants is,
that both possibilities are tied to the physical layer of the database and
doing some normalisation or denormalisation could break rules. A specific
(user programmed) solution could be based on the view layer and would be
better (IMHO)
D*B
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.