Re: Request ID Numbering recovery
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.commailto: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.8289tel:312.676.8289 | M: 630.946.4744tel:630.946.4744 ksincl...@shoppertrak.commailto:ksincl...@shoppertrak.com | @shoppertrak www.shoppertrak.comhttp://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.comhttp://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
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 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.commailto: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.8289tel:312.676.8289 | M: 630.946.4744tel:630.946.4744 ksincl...@shoppertrak.commailto:ksincl...@shoppertrak.com | @shoppertrak www.shoppertrak.comhttp://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.comhttp://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
Re: Request ID Numbering recovery
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.commailto: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.8289tel:312.676.8289 | M: 630.946.4744tel:630.946.4744 ksincl...@shoppertrak.commailto:ksincl...@shoppertrak.com | @shoppertrak www.shoppertrak.comhttp://www.shoppertrak.com/ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Request ID Numbering recovery
Thanks Fred, I will capture the SQL logs and check if I can find something which will be helpful. That work should have been done by now On Wed, Nov 5, 2014 at 1:09 AM, Grooms, Frederick W frederick.w.gro...@xo.com wrote: 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.commailto: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.8289tel:312.676.8289 | M: 630.946.4744tel:630.946.4744 ksincl...@shoppertrak.commailto:ksincl...@shoppertrak.com | @shoppertrak www.shoppertrak.comhttp://www.shoppertrak.com/ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where
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 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 | M: 630.946.4744 *ksincl...@shoppertrak.com ksincl...@shoppertrak.com* | @shoppertrak www.shoppertrak.com _ARSlist: 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
Re: Request ID Numbering recovery
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.commailto: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.8289tel:312.676.8289 | M: 630.946.4744tel:630.946.4744 ksincl...@shoppertrak.commailto:ksincl...@shoppertrak.com | @shoppertrak www.shoppertrak.comhttp://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.comhttp://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
Re: Request ID Numbering recovery
Luckily, I don’t have a server group set up here in this environment. I have worked with them before in my previous life. So, to answer the question as to why in all that’s un/holy do I want to do this, it’s because the previous Admin used the request ID to generate a unique customer number. Problem is that the systems that integrate into Remedy that take advantage of the customer number can only take a number that is only 4 digits long. So, when someone who doesn’t understand Remedy uses these number and subsequently deletes, we lose that range of unique numbers. So what am I gaining? Really just buying time for the other systems teams to work out a new solution of handling customer’s and their equipment before we hit that wall. Like sticking my finger in the dam whilst waiting for the heavy moving equipment that’s already on its way to get here before the levee breaks. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of William Rentfrow Sent: Monday, November 03, 2014 10:24 AM To: arslist@ARSLIST.ORG Subject: Re: Request ID Numbering recovery ** 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.commailto: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.ORGmailto: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.commailto: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.8289tel:312.676.8289 | M: 630.946.4744tel:630.946.4744 ksincl...@shoppertrak.commailto:ksincl...@shoppertrak.com | @shoppertrak www.shoppertrak.comhttp://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.comhttp://www.avg.com Version: 2014.0.4765 / Virus Database: 4040/8433 - Release Date: 10/22/14 Internal Virus Database is out of date. _ARSlist: 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
Re: Request ID Numbering recovery
, 2014 at 8:39 AM, Sinclair, Keith ksincl...@shoppertrak.com wrote: ** Luckily, I don’t have a server group set up here in this environment. I have worked with them before in my previous life. So, to answer the question as to why in all that’s un/holy do I want to do this, it’s because the previous Admin used the request ID to generate a unique customer number. Problem is that the systems that integrate into Remedy that take advantage of the customer number can only take a number that is only 4 digits long. So, when someone who doesn’t understand Remedy uses these number and subsequently deletes, we lose that range of unique numbers. So what am I gaining? Really just buying time for the other systems teams to work out a new solution of handling customer’s and their equipment before we hit that wall. Like sticking my finger in the dam whilst waiting for the heavy moving equipment that’s already on its way to get here before the levee breaks. *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *William Rentfrow *Sent:* Monday, November 03, 2014 10:24 AM *To:* arslist@ARSLIST.ORG *Subject:* Re: Request ID Numbering recovery ** 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 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 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 | M: 630.946.4744 *ksincl...@shoppertrak.com ksincl...@shoppertrak.com* | @shoppertrak 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 Version: 2014.0.4765 / Virus Database: 4040/8433 - Release Date: 10/22/14 Internal Virus Database is out of date. _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: 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
