JR,
Well... Support should check the docs. The special process is listed
in "BasicGuide-630.2006.05.09.pdf" on page 619. So if it truly "does
not work" then you need a bug ID and a patch to make it work. (And
being forced to upgrade _from a currently supported version_ to get a
bug fix should never be acceptable. You pay money for bug fixes... you
should get them in the version that you are using.)
Now... on to the possible issue here....
You may be seeing one of two things. (kind of hard to know without
seeing exactly what your doing....)
A) Before you use the Application-Copy-Field-Value $PROCESS$ command
are you moving the values from the Table Columns into Display only
fields? ( I have seen bugs that prevent latter loops of the guide from
seeing any records other than the first record in the table field that
is being looped over. Maybe you are suffering from that ARS problem?)
B) Are you checking/stomping on the wrong field?
The $PROCESS$ should be set to a 'Temp' field and not a "target
field". So there are five fields involved.
'source_fieldID_Column' (A column in the table of audit fields)
'target_fieldID_Column' (A column in the table of audit fields)
'Source_fieldID' (the field with data that you want to copy to
another field)
'Target_fieldID' (the field where you want the copied data to land)
'Temp' ( The field that the $PROCESS$ returns results too after
it does the Application-Copy-Field-Value er... function?)
So your set fields action should have the field set as 'Temp' with a value of
$PROCESS$ Application-Copy-Field-Value $Target_fieldID$ $Source_fieldID$
After the set field action happens the 'Temp' field should have a
value of 0 or 1 based on the docs to indicated this:
Ref: "BasicGuide-630.2006.05.09.pdf" on page 619
"
1—Indicates that the assignment occurred.
0—Indicates that the assignment failed.
"
It might be that the return value is not always set properly... (maybe
a bug in v6.x)
It might be that the return value is "stomping" on the copied field
value. ( As I would assume the copy process would have to totally
complete before the return code would be known. So if the 'Temp' field
was also the $Target_fieldID$ field then I can see how some confusion
could happen. However that explanation does not seem to work for the
"if 1 field is audited" conditions.)
My bet is that the "Problem A" is what your are seeing as the issue.
(But I can see how "Problem B" might be some peoples possible problems
too, so I mentioned it too.)
HTH.
Wow.. Dec 2005.. that idea is really that old hun? :)
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
On Nov 7, 2007 12:37 PM, JR Wyer <[EMAIL PROTECTED]> wrote:
> I know this is very old, but I'm trying to accomplish the very same
> thing and only recently found this thread.
>
> Unfortunately, my version of this functionality doesn't seem to be
> cooperating. It works fine if 1 field is audited, but any subsequent
> fields from the audit table pass the process's exit value (1 or 0) instead
> of the target field's transaction value.
>
> Remedy Support has told me that the 'Application-Copy-Field-Value' doesn't
> work in 6.3 and I'll need to upgrade to 7.x to utilize it. Yet, I see
> you've accomplished this very thing.
>
> I'd be happy to add more details if someone is willing to assist in
> figuring out where I went wrong.
>
> Thank you,
> JR Wyer
>
> L3 Communications
> Senior Engineer | CRM RAC
> Network Services
> Titan Group
> Navy Global DMS Consolidated Help Desk (DCHD)
> 757 443 9275
> [EMAIL PROTECTED] | [EMAIL PROTECTED]
> ______________________________________________________
>
>
>
> On Sat, 24 Dec 2005 08:48:20 -0500, Carey Matthew Black
> <[EMAIL PROTECTED]> wrote:
<snip>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
