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___ 

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"

Reply via email to