I have to modify my statement about searches not working, I had some bad information. The search problem is that when searching for a five digit Request ID number like 94567 the system returns no records found even though the field is set to QBE match anywhere. (I didn't set up the field but I probably will change it to Exact at some point). The only way to find a record by request ID is to use an advanced search string such as 'Case ID' LIKE "%94567" which is not an acceptable user experience. I have a feeling that since the older cases just have a null in that first character position the only way around it is to pad them with a leading zero so I may be on a faster track to do that than I previously thought. Since BMC Support won't have any idea about our custom forms & workflow I am not going to bother with a support case at this time since searching on other fields doesn't seem to be affected after all. -Rick
________________________________ From: Rick Westbrock Sent: Wednesday, February 18, 2009 2:34 PM To: '[email protected]' Subject: RE: Adding leading zeroes to Request ID Thanks for all the replies. I will plan to take longer to plan this out after reading John's point that I have plenty of time now to figure that out (it took more like 7-8 years to reach 100,000 tickets actually). However I've run into another issue since that change to the Request ID field was made and I can't believe that it's coincidence. Any search other than an empty qualification returns no rows found as of this morning. I think this must be related to increasing the Request ID size from 5 characters to 6 but I can't seem to figure out what would cause that. This was just brought to my attention so my next stop is SupportWeb but I thought I'd throw it out to the group anyway. -Rick ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of John Sent: Wednesday, February 18, 2009 11:01 AM To: [email protected] Subject: Re: Adding leading zeroes to Request ID ** I would leave the system as is. Also - by adding one digit -- you have just made the system have 9X (roughly) the amount of time left relative to the previously time to fill up. So -- if it took you 5 years to get where you are -- you are now set for the next 45 years. (I suggest delay the decision to go to 15 chars) Also - you may want to ask BMC to provide a patch to convert the Request ID to use Hex vs Decimal -- then you will really be cooking with gas. Heck -- I think BMC should have an option to say make request_id a GUID -- from 0-9A-Z -- since the Request ID is not supposed to be intelligent anyway. (ps -- no # or % please) By switching to a GUID -- you could eliminate the whole locking of records for insert problem (effectively improving performance). Also - you would eliminate those occasional ARSList emails asking how to reset the request_id. Have fun!!! -John -- John David Sundberg 235 East 6th Street, Suite 400B St. Paul, MN 55101 (651) 556-0930-work (651) 247-6766-cell (651) 695-8577-fax [email protected] On Feb 18, 2009, at 10:05 AM, Rick Westbrock wrote: ** I ran into a problem today on a form where some previous admin had set the Request ID field (1) to only five digits so after case number 99999 was created the NextID value in the arschema table incremented to 100000 but the form obviously couldn't create a case with that number so the agents were seeing error messages. My backup admin bumped the field length up to six digits so that agents could immediately start logging tickets again but I plan to increase the field length up to 10 or 15 digits. My question for everyone is what is the best practice to go back and zero-pad all of the existing tickets with five-digit Request ID numbers? It's not strictly necessary for operations but when search results come up defaulting to sort by Request ID these new six-digit request ID cases come up at the top of the list which is not intuitive at all for end users. I do have a dev server on which I will test whatever method I decide upon first and I can delete records if needed as part of testing. -Rick Single Remedy application server: Windows Server 2003 SP 2 IIS 6.0 ARS 7.0.1 patch 6 E-mail Engine 7.0.1 p6 Mid-Tier 7.0.1 p6 Tomcat 5.5 Remote Database Server: Windows Server 2003 SP 2 SQL Server 2000 (8.0.76 SP 3 Standard Edition) _________________________________ Rick Westbrock PETCO Telecom Engineer [email protected] <mailto:[email protected]> __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
