Hi Carey,
Thanks for the troubleshooting suggestions. I'll let you
know what I discover. I appreciate your time.
Larry
On Mar 19, 2008, at 9:22 AM, Carey Matthew Black wrote:
Larry,
Thanks for the details on what your doing. It does help me to
understand what could be going on and to provide a few ideas on how to
troubleshoot this. As far as I know the idea of a "global" (or window
local) field is all in the client layer. I do not believe the server
does anything special with these values between transactions from the
client.
Your statement of "Depending upon which combination" makes me think
you might be fighting more than one logic problem. So, first, let us
break this task down a bit. The beginning looks like "Get Entry" to
me. So let us start there...
I would suggest that you add a filter (on "Get Entry") at execution
order 999 and simply do a set field action that sets every field in
the transaction to it's current value. This will let you log what the
field's values are at that point in the process in your filter logs.
Then I would add enough debug output from your ARSPerl client to also
log all the values (for every field ID) that it gets from the server.
If you detect differences at this point, then we can clearly blame
ARSPerl or the v4 C API. (But I would not expect any differences.)
Now the next thing that is happening is that the ARSPerl client is
"doing something" that either results in a Submit or Modify back to
the AR Server. So again... I would add enough debug output from your
ARSPerl client to also log all the values (for every field ID) that it
sends to the server. ( My guess is that some values are not being
treated as "Global" in the ARSPerl client because it is not keeping
state right, or some other client based issue. Another possibility is
that the v4 idea of "NULL" is not what your sending to the server for
that field. Are you using the perl undef keyword or sending an empty
string("")? But as you say... "Depending upon which combination" of
details, different things might be happening.) Tracking the values
through the client functionality should help you to identify that the
client is doing what you think it should be doing.
Lastly.... I would take that "Get Entry" filter and copy it to a new
filter and make it fire on Submit/Modify at Execution order zero (0).
So that you can check the values that the Client sends to the ARS
server. Again, if you detect differences at this point, then we can
clearly blame ARSPerl or the v4 C API. (But I would not expect any
differences.)
HTH.
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
