In Java, you have the same problem. The UID is only unique for the machine, so the common trick is to take the IP address of the local machine and use it as a prefix (should be unique within your network anyways).
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of David Wolverton Sent: Wednesday, January 26, 2011 6:55 AM To: 'U2 Users List' Subject: Re: [U2] Data in Dict I'm curious what your logic is to generate the Unique ID -- can you share that without giving away a trade secret?? It's too bad it's not a database function call in UniData/UniVerse - we can do that in D3/Pick - it's a derivation of system Date/Time with AlphaSequencing if more than 1 hit in a given clock cycle - but it would only be unique on the 'machine' since another system could generate the same ID. So I am interested in the idea of generating a TRULY unique ID. DW -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Steve Romanow Sent: Tuesday, January 25, 2011 7:24 PM To: U2 Users List Subject: Re: [U2] Data in Dict In some cases I am becoming a fan of UUIDs for db table keys. A UUID type one uses the mac address of the host along with the current time as salt so you don't have to worry about key collisions between accounts (I.e. TEST and PROD). Generating the next key is fast because there is no readu, update, write. They should hash pretty well since they are long and random. On 1/25/11, Bill Haskett <[email protected]> wrote: > Jeff: > > I have a single file named (CTRLNOS) with the item ID equal to the > file name using the sequence#. Field#1 is the last seq# used while > field# 2 is the maximum seq# allowed before the seq# is reset to 0. > Each item has documentation in it to describe what it's for and any > unusual pieces of data allowed (e.g. maximum length of data allowed in a text > box). > > The get-next-sequence code looks like: > > READ{U} SEQREC FROM SEQFILE, FILENAME ELSE > SEQREC = 0:@AM:99999:@AM:@AM:@AM > SEQREC := "** Item created on ":TIMEDATE():"." > END > SEQ = SEQREC<1> + 0 > MAX.SEQ = SEQREC<2> + 0 > OSW = 0 > LOOP > SEQ += 1 > IF SEQ > MAX.SEQ THEN > IF NOT(OSW) THEN OSW = 1 ; SEQ = 1 > END > READV{U} DoesExist FROM FILENAME.FV, SEQ, 0 ELSE DoesExist = 0 > UNTIL NOT(DoesExist) DO REPEAT > > If a file goes bad then I know which item to fiddle with. Just a thought. > > Bill > > ---------------------------------------------------------------------- > -- Jeff Schasny said the following on 1/25/2011 8:37 AM: >> My preference is to have a data file specifically for next key >> records with the item id being the filename and field 1 being the >> next available key. As far as restoring it should it become corrupted >> a fairly simple Uvbasic program which is fed a list of filenames, >> selects each file BY.DSND @ID, readnext, add 1 to the first key, >> write that as the next key for the file, next filename should be able >> to restore your next key file in a couple minutes if not less. >> >> George Gallen wrote: >>> The one down side I can think of to not keeping 'next' values in the >>> DICT and in a separate file, is if you have to restore the file, you >>> will also have to restore the NEXT-FILE as well. It's not one neat >>> package. >>> >>> But I have to admit, when I was setting up a MySQL structure and >>> needed to implement a 'next' value, I went with a separate file and >>> each row had two values, key and value, where the key was the >>> filename and the value being the next value, and used this one file >>> for all my 'next' placeholders, instead of writing it to the DICT, I >>> used the filename as the key. >>> >>> Although, keeping all your nexts in one basket could be a problem if >>> that file ever was corrupted, it would be difficult to reset them >>> all to the correct values. Other than that, seems a bit of overhead >>> to have a separate "next" file for each file you want to keep one on >>> to avoid losing all your keys with one file issue. >>> >>> What other methods are people using to track next ID? >>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:u2-users- >>>> [email protected]] On Behalf Of Bill Haskett >>>> Sent: Monday, January 24, 2011 7:55 PM >>>> To: U2 Users List >>>> Subject: Re: [U2] Data in Dict >>>> >>>> Kate: >>>> >>>> It seems to me that this is very tidy! :-) >>>> >>>> Bill >>>> >>>> ------------------------------------------------------------------- >>>> ---- >>>> - >>>> Kate Stanton said the following on 1/24/2011 1:27 PM: >>>>> Hi David, >>>>> >>>>> The reason we use dictionaries for data entry, reports, queries >>>>> and forms is so we can use the same dictionary item for all >>>>> activities, thus using the dictionary as designed with a little more. >>>>> >>>>> So, if part ID is changed at a site to be 6 numbers, then changing >>>> the >>>>> dict item in a file once means the same change applies to all >>>>> other activities. >>>>> >>>>> We think this is very tidy, and the unused portion of dictionaries >>>>> have been used like this for a long, long time (over 30 years to >>>>> our knowledge). >>>>> >>>>> Cheers, Kate >>>>> >>>>> Kate Stanton >>>>> Walstan Systems Ltd, >>>>> 4 Kelmarna Ave, Herne Bay, Auckland 1011, New Zealand >>>>> Phone: +64 9 360 5310 mobile: + 64 21 400 486 fax: + 64 9 367 >>>>> 0750 >>>>> Email: [email protected] >>>>> >>>>> On 25 January 2011 03:53, David A. Green<[email protected]> >>>> wrote: >>>>>> All this talk about using the Dictionary item to store extra data >>>> has >>>>>> prompted this post. >>>>>> >>>>>> I realize in the past when the limit to the number of Opened >>>>>> Files >>>> in a >>>>>> Basic program was a programming challenge, that doing creative >>>>>> data >>>> storage >>>>>> might have been an necessity. But I would like to suggest we >>>>>> leave >>>> the >>>>>> Dictionary alone, let the database use it the way it wants to and >>>> let us >>>>>> create our own storage device for dictionary related data. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> David A. Green >>>>>> (480) 813-1725 >>>>>> DAG Consulting >>>> _______________________________________________ >>>> U2-Users mailing list >>>> [email protected] >>>> http://listserver.u2ug.org/mailman/listinfo/u2-users >>> _______________________________________________ >>> U2-Users mailing list >>> [email protected] >>> http://listserver.u2ug.org/mailman/listinfo/u2-users >>> >> > _______________________________________________ > U2-Users mailing list > [email protected] > http://listserver.u2ug.org/mailman/listinfo/u2-users > -- Sent from my mobile device _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
