Les, Kelly, Matt and Gary are on the mark for OTB ITSM apps where the request is created on opening of a 'New' incident or problem or change or solution form from the application interface.
On custom applications however, it can happen if there is a push field action that creates records on your main tickets underlying supporting data. If at any point after the push if an error occurs lets say if there is another push field action to another form from the main form after the ticket is created, then there is a rollback and the nextid that was used remains used though the record is not created. So for example if form A is the main data form where the record is created, but at the time the record is created if there is another form B where some information is pushed but if there is an error when pushing information to form B, then the record that was created in form A is rolled back, but the nextid from form A is not rolled back. It isn't rolled back to avoid duplication of the Request ID. So it is as designed. Hence the gap.. Hope this helps... Joe -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Matthew Kunkel Sent: Wednesday, August 29, 2007 2:33 PM To: arslist@ARSLIST.ORG Subject: Re: Gaps in Request ID sequence Additional C1 gaps can occur in version 6.3-7.x if you have the parameter "Next-ID-Commit: T" set in your conf file. This causes a database commit to occur after selecting and updating nextid in arschema (before creating the actual record). Thus if the actual record creation rolls back, the arschema transaction doesn't and you miss an ID. -Matt Kunkel -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Opela, Gary L Contr OC-ALC/ITMA Sent: Wednesday, August 29, 2007 1:26 PM To: arslist@ARSLIST.ORG Subject: Re: Gaps in Request ID sequence It is true with ITSM VII that remedy does set a field whenever you open the ticket, before saving it. It is not the column 1 record id field, it is a different field. If you close a ticket without saving it, then there is a gap created in this. As for the C1 core request id, you can get gaps by at least two methods. Method 1: Delete tickets. Method 2: Like Kelly states below, set the IDs in Blocks. If you experience a crash with remedy, then you lose tickets. If you shut down remedy normally, then you do not lose tickets. Thanks, Gary Opela, Jr Sr. Remedy Developer Leader Communications, Inc. 405 736 3211 -----Original Message----- From: Action Request System discussion list(ARSList)[mailto:[EMAIL PROTECTED] On Behalf Of Gatewood Kelly Sent: Wednesday, August 29, 2007 1:19 PM To: arslist@ARSLIST.ORG Subject: Re: Gaps in Request ID sequence Lee, If you happen to have the next ID block size set, then gaps can occur no matter which version of ARS or ITSM applications you are using. If you using the ITSM 7.0 applications and above, I believe that the application now requests the request ID when the request is initially opened and then if the record is not saved it is "lost" thanks Kelly -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, August 29, 2007 13:06 To: arslist@ARSLIST.ORG Subject: Gaps in Request ID sequence Hello, Has anyone got a good explanation of why gaps may appear in the Request ID sequence? I performed a minor rollout on Monday evening, with only a couple changes to workflow on the form in question. I can't think of anything that I could have done that would cause the gaps to appear. Note that these gaps are random, and seem to only have been happening since Monday. I know this can happen if records within the gap are deleted, or if an import was performed with higher Request IDs. I know there was no import. I really don't believe anyone has deleted any records as there are footprints in several other forms where the missing IDs could have been found. I am at ARS 7.0.01 If anyone else has seen this sort of thing, and has any info, I would be very greatful. Thanks Les Ganton No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.484 / Virus Database: 269.12.10/977 - Release Date: 8/28/2007 4:29 PM _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
