RE: Timestamp field

[Joel Fritz <JFritz@xxxxxxxxxxxxxxxx>]

I think Buck has a point.  The time opcode's precision is to the nearest
millisecond.  TFM says about the time opcode and timestamps (V4r3):

"If the Result field is a Timestamp field, the last 3 digits in the
microseconds part is always 000."

I learned this one when playing with the random number API trying to use the
microsecond portion of a timestamp as a seed.

Don't know about the SQL timestamp.

-------------------------------------------
A mind is a terrible thing to use.

Joel Fritz 

> -----Original Message-----
> From: Nelson C. Smith [mailto:ncsmith@gate.net]
> Sent: Thursday, January 20, 2000 2:03 PM
> To: RPG400-L@midrange.com
> Subject: Re: Timestamp field
> 
> 
> I have way too much respect for you to dispute what you are 
> saying, Buck,
> but I was just wondering....  Why would the SQL timestamp 
> function be any
> more accurate than the RPG TIME opcode?   In the past, I've 
> had just the
> exact opposite problem.  The RPG opcode would give a good, completely
> accurate timestamp and SQL would not.
> 
> All my audit files use the timestamp as the final unique key 
> (in addition to
> whatever key the masterfile used), and we've never had a 
> duplicate key on
> any of our machines (up to a 4-way), except when *LOVAL was 
> being written
> (in error).  Of course, I don't know of any applications that write or
> update the very same record over and over again quick enough 
> to cause such a
> problem, so I suppose it's possible we just haven't hit one 
> yet.  We have
> had quite a lot of problems, however, using SQL to write 
> records with a
> timestamp in the key.
> 
> -----Original Message-----
> From: Buck Calabro <buck.calabro@aptissoftware.com>
> To: RPG400-L@midrange.com <RPG400-L@midrange.com>
> Date: Thursday, January 20, 2000 4:12 PM
> Subject: RE: Timestamp field
> 
> 
> >Marc,
> >I would not depend on using the timestamp as a unique key.  
> As you have
> >found out, on a sufficiently fast enough machine you can get 
> duplicates.
> >The upshot of this is that even if it works today, when the 
> next generation
> >of CPUs come out it might fail.
> >
> >I would suggest adding another field (sequence number) if 
> you have a need
> to
> >discriminate between each record.  If you really truly need 
> the extra three
> >digits, consider using SQL to do your insert, as in:
> >insert into xxx (field, timstp) values(:field, CURRENT TIMESTAMP)
> >
> >Buck Calabro
> >Aptis; Albany, NY
> 
> 
> +---
> | 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
> +---
> 
+---
| 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
+---