Well, this has been an interesting issue!
After my little hissy fit, I was immediately sent to backline support. As
always, once I got to an engineer, things went smoothly.
Vishal and Khushal worked with me and did a fine job. They quickly
discovered that what I was seeing was a bug. They
Hi. Wouldn't you use the 'LIKE' instead of '=' in this case? Seems like
Equal is not the correct operator if there are multiple Request ID's within
the field.
And why would there be multiple values within the Request ID anyway? It
seems to be an incorrect assumption given the error message you
Hi,
I do not think that you can search directly in a Join-request-id like
that. Some clients might be able to decipher the entered string though.
If you look at the API, you can retrieve records, and in this case you
supply an array of the three ids in the correct order.
The simplest option,
You are able to search a join request ID in that fashion. In fact, I do it
all the time! It works on my production server (which is at a lower patch
level (6.3 patch 16).
There are work arounds, and I suspect that I will have to utilize them.
Thanks for the quick replies!
On Tue, Jun 5, 2012
Warren,
I know you should know this but whisper are the permissions set correctly for
each form and Request-id field?/whisper
Can you see the record you want by using a different search field?
Thank you,
---
John J. Reiser
Remedy Developer/Administrator
Senior Software Development Analyst
They are the same as the form it is based on that works on my production
server. It really seems to be a server issue. The error is the
following: ARERR [101] Entry ID parameter value is longer than the maximum
allowed length
It feels like Remedy is interpreting the 47 character Request ID as
ARS 6.3 patch 23 running on Solaris (SunOS 5.1)
I have a join form that joins another join to AP:Signature.
When I try to search against the Request ID using the following search:
'Request ID' = 931|0002548|0001520
I get no matching requests
If I try searching
7 matches
Mail list logo
