RE: Timestamps

Ron,

Glad to hear you got your problem fixed.  I still don't understand the design 
but it 
sounds like you are comfortable with the solution.  Most of the time when I 
have seen 
a timestamp being used as a unique key it was for convenience and did not 
accurately 
model the underlying business process.  You mentioned that you are using an API 
and in another post you mention that initializing the timestamp to *loval 
(which should 
be the default) caused the milliseconds to be written out.  Was this all six 
positions?  
If it was all six positions, could you elaborate? It sounds like thoroughly 
undocumented 
feature.

David Morris

>>> ron.klein@brctsg.com 11/21/00 01:05PM >>>
David,
The reason for the accuracy is for duplicate records.  If a maintenance
program tries to update multiples records at one time and the timestamp is
our key field, we get a duplicate key message.  And yes adding one to a
counter certainly would work, but we are using an API to get our timestamp
and therefore we would have to track if the call to the API was initiated
from this commit cycle or it is a new cycle.  I just thought that using
milli seconds we might have a easier time.

Ron


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---