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 suggested I upgrade to 7.0.1 patch 8 which is where it was fixed. That was not a possibility. Since my production environment was at patch 16 and not experiencing the problem, they suggested I copy the arserverd file from production to development to see if that solved the problem. It did. After I hung up, I did a little experimenting. I discovered that it broke in Patch 18 of 6.3. It's documented by SW00293344 which as usual has no real information attached to it. So, just to let everyone know. You should always be able to search a join using the extended Join Request ID. If you get ARERR 101, you need to patch. Thanks to everyone who gave me their thoughts and ideas. It's always a pleasure to deal with this group! Warren On Tue, Jun 5, 2012 at 12:24 PM, Warren R. Baltimore II < [email protected]> wrote: > The field lengths are all standard join lengths. The only difference > between the 2 is the patch level. Production (which works) is at patch 16 > but development (which doesn't work) is at patch 23. > > Warren > > On Tue, Jun 5, 2012 at 11:39 AM, Ben Chernys < > [email protected]> wrote: > >> Well, something must be different on the two servers… (patch level, >> form def, …)**** >> >> ** ** >> >> BMC always makes the join’s ‘1’ 254 never to the exact right spec. If >> your problem is on prod, you may be out of luck. **** >> >> ** ** >> >> On dev you can easily increase the size to 254 and try the query again. >> Remember that the size is not relevant on a join anyhow. Just for the >> search perhaps and the value that will be displayed.**** >> >> ** ** >> >> I am curious because 1) 47 is pretty exact and doesn’t leave a lot of >> space. I am assuming that each of the normal forms has ‘1’ of 15. What is >> the size of ‘1’ on the inner join**** >> >> ** ** >> >> ie**** >> >> ** ** >> >> 3-level join ‘1’ length = 47**** >> >> 2-level join ‘1’ length = ??**** >> >> ** ** >> >> 6.3 is not supported so how are you raising tickets? I agree with the >> hassles of support. I only us them when I am told to by my customer. For >> me, it is a service to identify software bugs and I am loath to do it for >> free.**** >> >> ** ** >> >> I would definitely make both of the joins above (2, 3 level) have 254 for >> field ‘1’**** >> >> ** ** >> >> Cheers**** >> >> Ben**** >> >> ** ** >> >> *From:* Warren R. Baltimore II [mailto:[email protected]] >> *Sent:* June-05-12 17:12 >> >> *To:* Ben Chernys >> *Subject:* Re: I am unable to search against the Request ID of a 3 form >> join.**** >> >> ** ** >> >> Nope! 47 characters..... *sigh***** >> >> **** >> >> And it works this way on EVERY join on this server.**** >> >> On Tue, Jun 5, 2012 at 11:05 AM, Ben Chernys < >> [email protected]> wrote:**** >> >> I just saw your other messages. Make sure YOUR join’s ‘1’ is 254 >> long! (Field length on the triple join)**** >> >> Cheers**** >> >> Ben**** >> >> **** >> >> *From:* Warren R. Baltimore II [mailto:[email protected]] >> *Sent:* June-05-12 16:46 **** >> >> >> *To:* Ben Chernys >> *Subject:* Re: I am unable to search against the Request ID of a 3 form >> join.**** >> >> **** >> >> Not really a solution when you have workflow trying to push information >> to joins!**** >> >> **** >> >> **** >> >> On Tue, Jun 5, 2012 at 10:35 AM, Ben Chernys < >> [email protected]> wrote:**** >> >> Easiest solution,**** >> >> **** >> >> Pick up your join in the user tool, select all records, print a report >> with all fields as a CSV and look in there.**** >> >> **** >> >> This has always worked. Even in 6.3 J**** >> >> **** >> >> Cheers**** >> >> Ben**** >> >> **** >> >> *From:* Warren R. Baltimore II [mailto:[email protected]] >> *Sent:* June-05-12 16:23 >> *To:* Ben Chernys **** >> >> >> *Subject:* Re: I am unable to search against the Request ID of a 3 form >> join.**** >> >> **** >> >> Thanks Ben!**** >> >> **** >> >> I was concerned I was somehow swapping request id's around, so I did a >> search for a specific ticket, copied the Request ID and then searched >> against that copied id.... Same problem! **** >> >> **** >> >> I also tried removing the AP:Signature id, same issue.**** >> >> **** >> >> I thought maybe it was just joins that I had created or 3 level joins, so >> I tried searching Join Forms that are part of ITSM and Join Forms that are >> just 2 children. Same result.**** >> >> **** >> >> I do it on my other server, it works just fine. I am positive this is a >> bug, and I can't be the first person to run into it (my server combination >> is very vanilla). **** >> >> **** >> >> I just wish I wasn't operating on such an old version. I know that in >> the end, they won't really look at the issue.**** >> >> **** >> >> Warren**** >> >> On Tue, Jun 5, 2012 at 10:02 AM, Ben Chernys < >> [email protected]> wrote:**** >> >> **** >> >> I also search joins like that at times. **** >> >> **** >> >> Make sure that the order of the ids is right J**** >> >> **** >> >> **** >> >> So, try eliminating the AP:Signature Id**** >> >> **** >> >> ‘1’ like “%00001|00001%”**** >> >> **** >> >> Where 00001|000001 is the join id**** >> >> **** >> >> The order should be in the order you defined your join**** >> >> Ap:sig**** >> >> Other join (or 2 normal forms, j1, j2)**** >> >> **** >> >> Would be: sig|j1|j2**** >> >> **** >> >> vs the other way round:**** >> >> j1|j2|sig**** >> >> **** >> >> **** >> >> Cheers**** >> >> Ben**** >> >> **** >> >> Ben Chernys >> Senior Software Architect >> **** >> >> Canada / Deutschland >> Mobile: +49 171 380 2329 GMT + 1 + [ DST ] >> Email: [email protected] >> Web: www.softwaretoolhouse.com >> >> Check out Software Tool House's free Diary Editor and out Freebies**** >> >> Section for an ITSM 7.6.04 Forms and Fields spreadsheet. >> >> *Meta-Update**,* our premium ARS Data tool, lets you automate >> your imports, migrations, *in no time at all*, without programming, >> without staging forms, without merge workflow. >> http://www.softwaretoolhouse.com/ **** >> >> **** >> >> **** >> >> **** >> >> **** >> >> **** >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> [email protected]] *On Behalf Of *Warren R. Baltimore II >> *Sent:* June-05-12 14:46 >> *To:* [email protected] >> *Subject:* Re: I am unable to search against the Request ID of a 3 form >> join.**** >> >> **** >> >> ** **** >> >> 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 at 8:37 AM, Misi Mladoniczky <[email protected]> wrote:**** >> >> 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, that should work across versions and clients, seems >> to be to expose all three core request id field, and do a search in these >> instead: >> ('Request ID1' = "000000000000931" AND >> 'Request ID2' = "000000000002548" AND >> 'Request ID3' = "000000000001520") >> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) >> >> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): >> * RRR|License - Not enough Remedy licenses? Save money by optimizing. >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. >> Find these products, and many free tools and utilities, at http://rrr.se. >> **** >> >> >> > 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 are >> > getting >> > anyway. >> > If you were to look at the data of your new join form, via say >> > ARUtilities' >> > SQL function (which I just love now) maybe you would see what the field >> > data looks like. >> > >> > use a SQL like this (if your database is MS SQL Server) >> > >> > SELECT Request_ID,someotherfield, another_field FROM My_Join_Form >> > >> > and see what it looks like. I'm not online right now so I can't test it >> > on >> > a join form for you. plus I'm not on the same version... >> > Hope this helps anyway. :) >> > >> > >> > On Mon, Jun 4, 2012 at 5:53 PM, Warren R. Baltimore II < >> > [email protected]> wrote: >> > >> >> ** >> >> 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' = "000000000000931|000000000002548|000000000001520" >> >> I get no matching requests >> >> >> >> If I try searching directly in the field, I get: "ARERR [101] Entry ID >> >> parameter value is longer than the maximum allowed length" >> >> >> >> I've submitted a ticket to BMC, but I thought I'd see who was faster! >> >> >> >> Any help would be most appreciated. >> >> >> >> -- >> >> Warren R. Baltimore II >> >> Remedy Developer >> >> 410-533-5367 >> >> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ >> > >> > >> > >> > >> > --**** >> >> > *Nancy Tietz***** >> >> > Application Systems Analyst Programmer >> > AIS - FIN / ITSM >> > Information Technology Services >> > University of Michigan >> > x30515 >> >**** >> >> > >> _______________________________________________________________________________ >> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" >> > >> >> >> _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"**** >> >> >> >> >> -- >> Warren R. Baltimore II >> Remedy Developer >> 410-533-5367 >> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ **** >> >> >> >> >> -- >> Warren R. Baltimore II >> Remedy Developer >> 410-533-5367**** >> >> >> >> >> -- >> Warren R. Baltimore II >> Remedy Developer >> 410-533-5367**** >> >> >> >> >> -- >> Warren R. Baltimore II >> Remedy Developer >> 410-533-5367**** >> >> > > > -- > Warren R. Baltimore II > Remedy Developer > 410-533-5367 > -- Warren R. Baltimore II Remedy Developer 410-533-5367 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
