Rick, the attachments are stored in the database. In your case in table B97C611111115. And this one you forgot to update. The path you're seeing in B97 is the original file location. HTH Kind Regards Conny
________________________________ Von: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] Im Auftrag von Rick Westbrock Gesendet: Mittwoch, 11. März 2009 20:41 An: arslist@ARSLIST.ORG Betreff: Re: Adding leading zeroes to Request ID ** Thanks for the tip about the B table Conny; due to multiple form dependencies I ended up using the direct SQL method rather than rrrChive to update a total of six tables. I did run into a small issue with attachments (luckily there are only 18 records out of 100,000 that have an attachment). The attachments show up in the pool when the record is displayed, including the correct icon for the file type (e.g. Adobe icon for PDF files). However when I click to save or view an attachment I get an "ARERR [556] Missing data in the SQL database: (B97C611111115)" error. I checked the DB and that field appears to be the full path plus file name at the time the file was attached to the record. For record number 097957 here's what the DB showed in the B97 table after updating the C1 column (and the request ID on the form) and which threw the error: 097957 \\emcdm2\groups\mis\remedy\Licensing and Maintenance\2009 Maintenance\SupportQuote186492-Basic.pdf 14355 8976 In the WUT I deleted the attached file and then added it back in and saved the request. Now I can display the attachment with no problem and this is what that same record in the B97 table: 097957 \\emcdm2\groups\MIS\Remedy\Licensing and Maintenance\2009 Maintenance\SupportQuote186492-Basic.pdf 14355 8976 The only difference is that one of the sub-directories is all lower-case before and all upper-case afterwards. Does anyone have an explanation of why that would cause a problem since I'm on MS SQL which is supposed to be case-insensitive. I was under the impression that attachments were stored in the database but the info above leads me to believe that it's actually just storing a pointer to the real location of the files; that would be a problem since most of the other attachments show a path on a D: drive. -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 ri...@petco.com <mailto:ri...@petco.com> ________________________________ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Conny Martin Sent: Wednesday, February 18, 2009 10:44 AM To: arslist@ARSLIST.ORG Subject: AW: Adding leading zeroes to Request ID ** ** If there are attachment fields on your form don't forget to update the B tables. Kind Regards Conny ________________________________ Von: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] Im Auftrag von Joe DeSouza Gesendet: Mittwoch, 18. Februar 2009 19:42 An: arslist@ARSLIST.ORG Betreff: Re: Adding leading zeroes to Request ID ** The key is you will need to know your system well. If you want to do what you want to, you will need to know the different relationships that form might have with other forms (such as association tables if you are using the OTB applications etc), where the Request ID is used in the relationships.. Off course you also will need to modify the corresponding entries in the H tables as well. It would be possible to write a SQL script to achieve what you want so long as you know your system well.. Joe ________________________________ From: Rick Westbrock <ri...@petco.com> To: arslist@ARSLIST.ORG Sent: Wednesday, February 18, 2009 11:05:26 AM Subject: Adding leading zeroes to Request ID ** 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 ri...@petco.com <mailto:ri...@petco.com> __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ __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"
