At a previous employer, we used a single file similar to what Jeff suggests, and it was a very neat and tidy little file. The only problem we ran into was when we started getting larger sites, and had trouble with throughput. It turned out that with 20 or so next-item counters in one frame, the lock table became a bottleneck. We had to radically over-size the file to spread the items into more groups so that group update locks didn't hamper performance. So our neat and tidy modulo 7 or 11 file went to a modulo of around 101. Still relatively small with a separation of 1. With disk as cheap as it is these days, it's a very easy solution, once you know.
Richard Lewis On Tue, Jan 25, 2011 at 10:49 AM, Allen Egerton <aeger...@pobox.com> wrote: > Jeff, > > That's a nice simple solution, I'd just add don't forget to right > justify the @ID Dict item in the file that's being selected by.dsnd ;) > > Allen > > > On 1/25/2011 11:37 AM, Jeff Schasny wrote: > > 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- > >>> boun...@listserver.u2ug.org] 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: k...@walstan.com > >>>> > >>>> On 25 January 2011 03:53, David A. Green<dgr...@dagconsulting.com> > >>>> > >>> 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 > >>> U2-Users@listserver.u2ug.org > >>> http://listserver.u2ug.org/mailman/listinfo/u2-users > >>> > >> _______________________________________________ > >> U2-Users mailing list > >> U2-Users@listserver.u2ug.org > >> http://listserver.u2ug.org/mailman/listinfo/u2-users > >> > >> > > > > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users > _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
