Hi Misi and team, We have dumped production db to our development server, since then while creating Incidents we are getting the below error.
*The value(s) for this entry violate a unique index that has been defined for this form (ARERR 382)* If I update the ar.conf with below as recommended above will it solve my issue! Next-ID-Commit:F Next-ID-Block-Size:1 Thanks Pavan On Tue, Nov 4, 2014 at 2:05 PM, Misi Mladoniczky <m...@rrr.se> wrote: > Hi, > > To get a continous series you have to set two parameters in version 7.6.04 > and > forward: > # ar.cfg/conf > Next-ID-Commit:F > Next-ID-Block-Size:1 > > Luckily, you can set Next-ID-Block-Size on each form. So you can have it > set > to 50 in general, but 1 for the forms where you need to keep your series > intact. > > Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) > > Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): > * 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. > > > Agreed - you can do it, but it doesn't really make sense to do it. > > > > Many times people doing data analysis will assume that the order of the > > entries in the system indicates the order they were created in. This is > > mostly true on single server systems. You'll still get some gaps unless > your > > NEXT-ID-BLOCK-SIZE is set to 1. > > > > It's completely different if you have a server group and multiple > servers. > > The Next ID block size is almost always set to a higher number like 50 > and > > it's very possible for server "A" to grab 50 ID's (e.g. 1-50) and then > server > > "B" grabs 51-100. And then for whatever reason the users on server "B" > work > > fast and create use up their 50 well before the users on server "A". So > even > > though their requests are all newer they have a higher ID. > > > > You probably know all of that, but I said all of that so I can say this: > I > > always tell users/managers/etc that the Request ID signifies only one > thing - > > a unique number. You cannot draw any other conclusions from it, and > missing > > requests are the norm and should be ignored. > > > > William Rentfrow > > wrentf...@stratacominc.com > > Office: 715-204-3061 or 701-232-5697x25 > > Cell: 715-498-5056 > > > > From: Action Request System discussion list(ARSList) > > [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook > > Sent: Monday, November 03, 2014 10:13 AM > > To: arslist@ARSLIST.ORG > > Subject: Re: Request ID Numbering recovery > > > > ** > > Technically, yes, you can. You can go into the DB and reset the NextID > > variable for that form. However, if it's a form that's being used for > entry > > (vs a config form), there's a good chance that numbers already exist that > > exceed 7002. If so, you'll get a Unique Index error when the next > incremented > > Entry ID see that a record already has that number. > > > > I would ask what you would gain from such an exercise vs. the effort it > would > > take you to gain it. Decide which is worth more to you. > > > > Rick Cook > > > > On Mon, Nov 3, 2014 at 7:59 AM, Sinclair, Keith > > <ksincl...@shoppertrak.com<mailto:ksincl...@shoppertrak.com>> wrote: > > ** > > Okay, have an unusual request. > > > > If there’s a missing block of Request ID numbers, can these be recovered? > > Example, a request started at 6001. Then someone uploaded a CSV and then > > deleted the records – not me, but someone in another department did > this. So > > the next legitimate request ID is 7002 or something like that. > > > > Can the numbers that were deleted, 6002 – 7001, be reused? When I first > > started out on Remedy, the answer was not really. Not sure if anything > has > > changed in the years/versions since then. > > > > Specs: > > ARS 8.1 > > Oracel12b DB > > > > Keith Sinclair > > Remedy Development > > ShopperTrak Chicago USA > > O: 312.676.8289<tel:312.676.8289> | M: 630.946.4744<tel:630.946.4744> > > ksincl...@shoppertrak.com<mailto:ksincl...@shoppertrak.com> | > @shoppertrak > > www.shoppertrak.com<http://www.shoppertrak.com/> > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > ________________________________ > > No virus found in this message. > > Checked by AVG - www.avg.com<http://www.avg.com> > > Version: 2014.0.4765 / Virus Database: 4040/8433 - Release Date: 10/22/14 > > Internal Virus Database is out of date. > > > > > _______________________________________________________________________________ > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > > "Where the Answers Are, and have been for 20 years" > > > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
