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]
__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"
