Hi,
Yes, but I am talking about the original default setting of the server:
Next-ID-Commit:F
Next-ID-Block-Size:1
In this setting, it should not be possible to get a gap.
Best Regards - Misi, RRR AB, http://rrr.se
> If you're using next id blocks any unallocated ones are lost when the
> server restarts. Consider a form with block size set to 10. On the first
> CreateEntry call to this form the server will read the nextId for the
> schema from the arschema table and increment it by 10. This transaction
> is commited to the database regardless of Next-ID-Commit setting.
> Subsequent CreateEntry calls will use a request id from the block in
> memory until they are exhausted at which point the arschema value is
> bumped up another 10. Now, if the server is restarted and only 5 of the
> 10 ids in memory have been used, the remainder are lost. When the server
> starts again it will allocate the next 10 ids above the current nextId
> value in the arschema table for the form. This situation is compounded in
> a server group where each server would take 10 ids so, at a maximum, you
> could get a gap of B x S ids where B is the block size and S the number of
> servers in the group.
>
> Mark
>
> ________________________________________
> From: Action Request System discussion list(ARSList) [[email protected]]
> On Behalf Of Misi Mladoniczky [[email protected]]
> Sent: 12 October 2011 16:04
> To: [email protected]
> Subject: Re: Next Request ID Block Size - Info required
>
> Hi,
>
> Hm... I do not think so...
>
> If the database has received the COMMIT, everything should be in the
> database. If not, the database would roll back, right???
>
> Best Regards - Misi, RRR AB, http://rrr.se
>
>> You will also get gaps on a server restart, unless the Next-ID-Commit
>> covers
>> that as well.
>>
>> For those whose records are subject to oversight, will missing records,
>> or
>> records whose IDs were not create chronologically, create any audit
>> issues?
>>
>> Rick
>>
>> On Wed, Oct 12, 2011 at 7:08 AM, Grooms, Frederick W <
>> [email protected]> wrote:
>>
>>> Misi,
>>>
>>> I can think of a case where a gap will occur. If I have a form that
>>> on
>>> submit fires a filter that does a push to a 2nd (or 3rd, 4th, ...) form
>>> and
>>> that push fails then the 1st form's record will be backed out. With
>>> multiple users on the system a second user could create a record in the
>>> 1st
>>> form during the time that the 1st user is doing the push to the child
>>> forms
>>> (especially if the push to child forms is conditional on data submitted
>>> in
>>> the 1st form). This would leave a hole in the sequence of ID on the
>>> 1st
>>> form.
>>>
>>> Fred
>>>
>>> -----Original Message-----
>>> From: Action Request System discussion list(ARSList) [mailto:
>>> [email protected]] On Behalf Of Misi Mladoniczky
>>> Sent: Wednesday, October 12, 2011 4:10 AM
>>> To: [email protected]
>>> Subject: Re: Next Request ID Block Size - Info required
>>>
>>> Hi,
>>>
>>> A failed submit has never left a gap in the id range until the
>>> Next-ID-Commit:T was introduced.
>>>
>>> I have depended on this since version 2.0 of the AR System.
>>>
>>> There are many cases when it is useful, or required, to have an
>>> unbroken
>>> serial number.
>>>
>>> You can build your own workflow to try to accomplish this, but it is
>>> not
>>> that easy to make it right, and it involves meddling with the filter
>>> phasing and database commits...
>>>
>>> Historically, the next-id-generation has been a dependable counter!
>>>
>>> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
>>> 2011)
>>>
>>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
>>> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
>>> logs.
>>> Find these products, and many free tools and utilities, at
>>> http://rrr.se.
>>>
>>> > -----Original Message-----
>>> > Sorry, nothing on that one.
>>> >
>>> > I must admit I've never really understood the requirement to have
>>> linear
>>> > request ids. That's not to say there's not a good reason you might
>>> want
>>> > to do this but I don't see the need. There has never been a
>>> guarantee
>>> > that there would be no gaps in the sequence - a failed submit may
>>> leave a
>>> > gap for example - and this has always been the case.
>>> >
>>> > The Next-ID-Commit was introduced as a performance tweak to reduce
>>> > contention on the arschema table when the nextId was being
>>> incremented.
>>> > If you're using next id blocks it is redundant as the call to
>>> increment
>>> > the nextId is only made when the server has used all the ids in the
>>> block
>>> > and needs to get the next chunk, not on every record submit.
>>> >
>>> > Mark
>>> >
>>> > -----Original Message-----
>>> > From: Action Request System discussion list(ARSList)
>>> > [mailto:[email protected]] On Behalf Of Misi Mladoniczky
>>> > Sent: 12 October 2011 08:29
>>> > To: [email protected]
>>> > Subject: Re: Next Request ID Block Size - Info required
>>> >
>>> > Hi,
>>> >
>>> > You learn something new every day, right :-)
>>> >
>>> > What about the Next-ID-Commit on a per-form-basis? That would be
>>> equally
>>> > important if you want your IDs in a straight line.
>>> >
>>> > Best Regards - Misi, RRR AB, http://rrr.se
>>> >
>>> >> Next-ID-Block-Size can be set per form - it's an option that can be
>>> >> enabled under Form, Properties.
>>> >>
>>> >> Mark
>>> >>
>>> >> -----Original Message-----
>>> >> From: Action Request System discussion list(ARSList)
>>> >> [mailto:[email protected]] On Behalf Of Misi Mladoniczky
>>> >> Sent: 12 October 2011 07:30
>>> >> To: [email protected]
>>> >> Subject: Re: Next Request ID Block Size - Info required
>>> >>
>>> >> Hi,
>>> >>
>>> >> What happens is that each thread will reserve 10 numbers at a time.
>>> >>
>>> >> This means that thread "1" will create something like number 15-24,
>>> >> and that the next thread will get 25-34 etc.
>>> >>
>>> >> This also means that the creation time of record 25 may be prior to
>>> >> lets say 18.
>>> >>
>>> >> In pre 7.6.04, the default value was 1, but it is now 25, which is a
>>> >> big change.
>>> >>
>>> >> Another important thing is the Next-ID-Commit setting, that will
>>> make
>>> >> sure that a number is not used until the record hits the database.
>>> >>
>>> >> New default settings from ar.cfg/conf in 7.6.04:
>>> >> Next-ID-Commit:T
>>> >> Next-ID-Block-Size:25
>>> >>
>>> >> Default values frn earlier version:
>>> >> Next-ID-Commit:F
>>> >> Next-ID-Block-Size:1
>>> >>
>>> >> It would be very nice if you could set this on a per form basis. I
>>> >> know many instances where you want to keep your request ids both
>>> >> straight and strict...
>>> >>
>>> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
>>> >> 2011)
>>> >>
>>> >> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
>>> >> * RRR|License - Not enough Remedy licenses? Save money by
>>> optimizing.
>>> >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
>>> >> logs.
>>> >> Find these products, and many free tools and utilities, at
>>> >> http://rrr.se.
>>> >>
>>> >>> -----Original Message-----
>>> >>> Hi All,
>>> >>>
>>> >>> I need your help to understand the form property "Next Request ID
>>> >>> Block Size". What I understood if I enable this property and set it
>>> >>> to as say 10. I would get request id as 2,12, 22,32 on the
>>> subsequent
>>> >>> created request on that form. But it did not happen that way.
>>> >>>
>>> >>> Could any expert please throw a little light on this form property
>>> >>> and use of it.
>>> >>>
>>> >>> PS: We also have similar setting on Server Information form, I
>>> guess
>>> >>> that is for setting globally for all forms and can be overwritten
>>> for
>>> >>> a particular form using form property.
>>> >>>
>>> >>> Please correct me if I am wrong
>>> >>>
>>> >>> Ashutosh
>>>
>>>
>>>
>>>
>>> _______________________________________________________________________________
>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>>>
>>
>> _______________________________________________________________________________
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
