Correct. 12346 was allocated, but was then discarded before it became a viewable Incident.
Rick On Wed, Mar 5, 2008 at 10:32 AM, Ganga Prasad <[EMAIL PROTECTED]> wrote: > ** Neel > Let me be bit more clearer. Lets say I have last request ID > 000000000012345.I am going ahead with a new ticket. I don't save the > ticket and cancel it. > Next I am creating a ticket and saving it then my new request ID will be > 000000000012347 instead of 000000000012346. > > My understanding behind this in above scenario is I tried to create a > instance of the ticket and the Next Reqest ID is incremented by 1 and when > i again tried to create a ticket again the Next Reqest ID incremented by 1 > and it gave me the number 000000000012347. > > Is this the way it work ? > > -- > Thanks and Regards, > Ganga Prasad Pattnaik, > ( Remedy Skilled Professional ) > > > On Wed, Mar 5, 2008 at 10:36 PM, Rick Cook <[EMAIL PROTECTED]> wrote: > > > ** I agree with Neel, whose reasons are sound. The Interface_Create > > form does not always create an Incident, which is why there are gaps. > > > > Rick > > > > > > On Wed, Mar 5, 2008 at 8:57 AM, Neel Guatam <[EMAIL PROTECTED]> > > wrote: > > > > > Ganga, > > > > > > When you say 'requestID generated are not in sequence' - are you > > > referring to; for example; all the incidents created? If so, that's > > > how > > > it works as when you open a new incident and select a customer, it > > > generated an incident ID and increment the nextID for that module. > > > However, when user cancels out and doesn't save that incident, the > > > next > > > incident created will not be in sequence and have a gap of one. If > > > many > > > users in production do that then you'll see the broken sequence and > > > it's > > > normal. IF this is the case then I don't think you should be messing > > > with it. > > > > > > Just my $0.02 > > > > > > Neel Gautam > > > Accenture - Chicago Delivery Centre > > > Core Values: Stewardship * Best People * > > > Client Value Creation * One Global Network * > > > Respect > > > for the Individual * Integrity > > > > > > -----Original Message----- > > > From: Action Request System discussion list(ARSList) > > > [mailto:[EMAIL PROTECTED] On Behalf Of Ganga Prasad > > > Sent: Wednesday, March 05, 2008 10:50 AM > > > To: arslist@ARSLIST.ORG > > > Subject: Re: Control over Request ID > > > > > > ** > > > Thanks Rick > > > In fact issue with me is that the request ID generated are not in > > > sequence. So can we make the is possible to break the sequence or if > > > broken then make it in order ? > > > > > > Thanks and Regards, > > > Ganga Prasad Pattnaik, > > > ( Remedy Skilled Professional ) > > > > > > > > > On Wed, Mar 5, 2008 at 10:10 PM, Rick Cook <[EMAIL PROTECTED]> > > > wrote: > > > > > > > > > ** You can, but should do so carefully. The nextId column in > > > the arschema table contains the number of the next Request ID for the > > > specified form. Manipulating that manually is done by resetting the > > > value via SQL command, which should only be done under specific > > > controlled conditions, which are listed in the Remedy documentation. > > > Failure to think through the process carefully may result in the form > > > being unable to accept further entries until the problem is fixed. > > > > > > If you want to present a different type of number to customers, > > > or exercise more control over it, I would recommend that you create > > > and > > > use a different field. > > > > > > Rick > > > > > > > > > On Wed, Mar 5, 2008 at 8:19 AM, Ganga Prasad > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > ** > > > > > > Hi All > > > > > > Do we have any control over the sequence of Request ID > > > ? > > > My understanding is that this number us generated automatically. Can > > > we > > > control the way it is getting generated ? > > > > > > > > > > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. If you have > > > received it in error, please notify the sender immediately and delete the > > > original. Any other use of the email by you is prohibited. > > > > > > > > > _______________________________________________________________________________ > > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > > > Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > > > > > > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > > html___ > > > > > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
