What I us for unique transaction numbers is empoyeeID + datetime, it generates a long number but cannot be repeated
Tom Hart ________________________________ zzak Memon t<[email protected]> To: RBASE-L Mailing List <[email protected]> Sent: Thu, October 18, 2012 12:07:05 PM Subject: [RBASE-L] - Re: DateTime tutorial At 09:36 AM 10/18/2012, Stephen Markson wrote: > Quick story illustrating why you should never use DATETIME for a unique >identifier: > We hired an experienced, reputable firm to create a web commerce app for us. >They > used a 12-digit order number. We asked them to reduce it to 9 digits so we >could use > (R:Base) integers in our application. At that time, I noticed that the order >number > was incrementing proportionally to the time, at a rate of 1 per 60 >microseconds. I > pointed out that decreasing the order # to 9 digits would increase the >probability > of a duplicate order # by a factor of 1,000. They said they'd get back to me. > A >few > weeks later we got two orders with identical order numbers. To say the least, > I >was > surprised that they had no primary key based on order #! Stephen, Very interesting story ... Did you know that R:BASE eXtreme 9.5 (64) include BIGNUM and GUID data types to handle such circumstances? In addition to so many cool features/enhancements, Globally Unique Identifier (GUID) data type in R:BASE eXtreme 9.5 (64) can also be used for a unique Row Identifier. For complete details ... http://www.rbase.com/rbg95 http://www.rbase.com/rbg95/compare.php Very Best R:egards, Razzak. www.rbase.com www.facebook.com/rbase
