Hi Rick, You can choose to leave the old ids as they are. The system will still work. If you want to pad the old ids, you can do that in a number of ways. I would definitely use a supported way, and that is to use the API (as opposed to direct SQL).
We have published a well tested and free tool called RRR|Chive that can do the job for you: https://www.rrr.se/cgi/rrrchive/main This config would change all 5-digit IDs to 10 digits (without a prefix): > source_server = xxx > source_user = Demo > source_password = > source_form = parentform > target_server = xxx > target_form = parentform > target_disablemergefltr = YES > source_disabledeletefltr = YES > qual = '1' LIKE "_____" > # change to an optional prefix followed by the preferred number of zeros > entryidmode = 0000000000 > transfertype = MOVE > verifydata = YES > verifyattachments = YES > logfile = rrrchive.log > loglevel = INFO > progressbar = YES As Joe DeSouza pointed out, you will also need to understand relationships with your current form. More specifically you need to understand where your entry-ID field is used as Foreign Key in other forms. I have an unpublished utility called RRR|ConvKey that can reconnect these related records. You have to specify the form-names and the key in each form though. Let me know if you are interested in this as well. Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. * RRR|Translator - Manage and automate your language translations. Find these products, and many free tools and utilities, at http://rrr.se. > 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] > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" > > -- > This message was scanned by ESVA and is believed to be clean. > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
