Hi Kirk, What you say makes sense, but the record number as key field is so integral to the way the program works, it would be a nightmare to try and change it :) If I was starting a project from scratch, that would be a different story. Pat
On Sat, 25 Aug 2018 at 16:20, Kirk Brooks via 4D_Tech <[email protected]> wrote: > Pat, > A couple of thoughts since it sounds like you're refactoring your code (all > pseudo code, v17): > 1) don't use this number as a key field. > > 2) The counter record: > > [COUNTER] > > ID > > name - optional but a good idea > > _data - object field: { nextNumber: 0, returned: []} > > 3) Counter_get_next(text) -> long > > $1 is name of counter series > > Put [COUNTER] in read/write > > Query for record > > Wait until record is unlocked > > `---- > > if(COUNTER._data.returned.length>0)` use the first one here > > $0:= > COUNTER._data.returned. > shift > () > > else > > $0:= > COUNTER._data.nextNumber > > COUNTER._data.nextNumber:= > COUNTER._data.nextNumber > +1 > > end if > > SAVE RECORD > > UNLOAD RECORD > > > 4) Counter_save_unused (text; long) > > Same idea except you just push $2 onto 'returned'. You could add a sort > command to make sure the smallest returned value is on top if that's an > issue. > > > Several years ago I stopped using invoice or PO numbers (or phone numbers > or SSNs or any data value) as key fields. This greatly simplifies the issue > you may have had about the 'unused' numbers that come up when data entry is > canceled. If you're not using that number as a key field you don't need to > assign it until the transaction completes. But if you've got some other > situations that result in 'returned' numbers it's not big deal. > > This approach let's 4D handle the record locking and request que and as > long as you don't call it within a transaction just blissfully works. > > > > On Sat, Aug 25, 2018 at 7:11 AM Pat Bensky via 4D_Tech < > [email protected]> > wrote: > > > Using v17 ... > > > > I'm looking at ways to update our ancient record numbering system, and I > > think I should be able to do it efficiently with CALL WORKER, but having > a > > bit of trouble getting my head around it. > > > > The record numbers are like invoice numbers: each must be unique, and we > > don't want to have any gaps in the numbering sequence. So we need to keep > > track of any record numbers that are created and then abandoned (eg if a > > user creates a new record and then cancels it). > > -- > Kirk Brooks > San Francisco, CA > ======================= > > *We go vote - they go home* > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:[email protected] > ********************************************************************** -- ************************************************* CatBase - Top Dog in Data Publishing tel: +44 (0) 207 118 7889 w: http://www.catbase.com skype: pat.bensky ************************************************* ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
