Tommmy is correct. We have found that the date/time he best way to go. Makes it eay to search, etc. If you have room thank about adding user and/or workstation id.
William Moore
California Fine Wire
805-489-5144
wjmoore@xxxxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx
Sent: Friday, November 19, 2010 6:46 AM
To: midrange-l@xxxxxxxxxxxx
Subject: 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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
