RE: time/date as key fields

True enough but my answer is based on my experience that almost no one is
exactly using integers for this type of thing (unless they are new apps
then maybe...) most transaction ID, order number type of fields are either
packed decimal or zoned numeric because those files/tables are so far
embedded into existing apps written 20+ years ago (or with the same
methodology) that you will eventually run into that problem.

Thanks,
Tommy Holden



From: "Christen, Duane" <Duane.Christen@xxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 11/19/2010 08:36 AM
Subject: RE: time/date as key fields
Sent by: midrange-l-bounces@xxxxxxxxxxxx



If you think you will over flow an INT use a BIG INT. If you can over flow
a BIG INT, good luck to you.

Duane Christen

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx
Sent: Friday, November 19, 2010 7:48 AM
To: Midrange Systems Technical Discussion
Subject: Re: time/date as key fields

IMO the date/time field approach will likely be more accurate just from my

experiences. What happens if the transaction numbers "roll over" and
start at 1 for example? Your applications may need changed to prevent
data loss. Just seems like extra unnecessary work to me..

Thanks,
Tommy Holden



From: David FOXWELL <David.FOXWELL@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 11/19/2010 03:30 AM
Subject: time/date as key fields
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Is there anything wrong in using date and time of creation fields already
existing in a transaction table to keep track of transaction history or
would it be advisable to add a separate field transaction_number? The
latter means a lot more program changes.

Thanks