× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 16-Apr-2015 16:56 -0500, broehmer wrote:
On 16-Apr-2015 16:48 -0500, Alan Campin wrote:
On 16-Apr-2015 16:16 -0500, broehmer wrote:
All right. I'm going to ask one of those "stupid" questions.

Why does the time stamp only use the first 3 positions of the
millisecond? We just tried to find unique records for a file
based on time stamp and got several results returned all with the
last 3 positions 0. In fact, all our files are like that.

Is this by design? Are we doing something wrong when we write
them out?

Depends what release you are. The more current releases have more
precision. Why are you using a timestamp for a unique value. Why
not use an identity key?

We're on 6.1 hopefully moving to 7.1 before end of summer.

To answer your question....it's an old file that is more or less for
historical purposes. Not a real problem yet but we were trying to
solve a "last record" for a group problem and ran into duplicates
using SQL.
Not a show stopper but close.


If the values of a column of the file storing the values [as TIMESTAMP or otherwise] were supposed to be maintained as unique, then probably there should be a PRIMARY KEY or UNIQUE constraint [or Unique Keyed Access Path of the non-SQL variety] to enforce that requirement. Any recipient of a duplicate key exception need only drop into a retry-until-success loop [with an optional escape for a "something must be seriously wrong" condition and\or delays to prevent a /hard-loop/].?

Just to reiterate, the topic origin was apparently /RPG timestamp/ values, but a clarification was made by someone that the DB2 for i TIMESTAMP data type defaults to a larger precision; yet those too can exhibit duplicate values, so even with more precision the constraint is a general requirement to ensure uniqueness, especially per newer\faster hardware being more likely to generate duplicates with [or even without] concurrency. While the SQL Special Register CURRENT_TIMESTAMP does not ensure uniqueness of values, the TIMESTAMP value from the SQL scalar GENERATE_UUID() ensures uniqueness of values; I do not know if the newer ROW CHANGE TIMESTAMP feature might, or not.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.