The ar.conf settings will not solve your error. You need to find which form you are getting the error against (and which field since the error may not be because of the Request_ID field)
This is where the SQL logs are very useful Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Nagidi Pavan Sent: Tuesday, November 04, 2014 1:31 PM To: arslist@ARSLIST.ORG Subject: Re: Request ID Numbering recovery ** 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 -----Original Message----- On Tue, Nov 4, 2014 at 2:05 PM, Misi Mladoniczky 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 > -----Original Message----- > 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 > -----Original Message----- > 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/> _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
