Since we deal with complicated contracts and HIPPA regulated information, I am very cautious about what information I provide, but there are a few things that we are working with presently that we just have not been able to solve.
On to the issues...
The Details
Our ARS (7.0.01 patch 003) also runs Mid-Tier 7.0.01 (patch 010). Recently, we began tracking of users logging into our system upon loading of the default form (one of two customized forms that is set as default by the system administrators) and we have set a Temp field which contains a list of the groups (by ID number - eg: "101, 210, 6027" and not "Help Desk, Software Support, and AS400 Development" - this runs a search of our "notification records" form, not of the default BMC Remedy User form's "Groups." This is set so we can list just the support groups, and none of the permissions. We also now don't run into accidental over-flow of information, for example users who are a member of the "Help Desk Triage" group cannot see tickets for the "Help Desk" group in the "Tickets assigned to your other groups" table on our primary default form (the original cause of this problem was the command
$GROUPS$ LIKE "something%", which is enough of a wild-card to cause these issues, but not something that we can really process in a way that is significantly different.Not long after these two new concepts were deployed, we began getting the following message from using logging into the Mid Tier: "ARWARN 66 - The query matched more than the maximum number of entries specified for retrieval." and in most situations, the error message will display twice.
The Conditions
The only time this message occurs is when a user has logged into the Mid Tier (web-version of Remedy) and is a non-Administrator user. The message only occurs on one of the default forms (as far as we have been able to detect). It affects users system-wide, regardless of if they are logging in via the web locally or remotely, it even occurs in Firefox, IE, and doesn't seem to be cross-platform (Windows, Mac, Linux) sensitive. The warning message does not occur on the Windows User Tool (WUT) which most users have installed 7.0.01 patch 10, nor does it occur in our Citrix implementation of Remedy (which are also based off of patch 10).
One of our active links has required us to use the special run-if qualification:
$CLIENT-TYPE$ != 9 (or whatever it is for the Mid-Tier) allowing us to write a second active link for $CLIENT-TYPE$ = 9. The workflow is associated with the support group listing detailed above.The default form that loads has several tabs, most of which contains between 1 and 4 tables worth of data that runs some type of query. When right clicking on the table and selecting "Refresh" the error does not occur. Only when loading the form itself. NOTE: There are several hidden tables which are inaccessible to regular users (including my test ID) which I cannot refresh with our current implementation.
Troubleshooting
Note: Only our PRODUCTION system currently connects to the Mid Tier. All testing has been preformed on our production system, with the specialized workflow limited down to execute only for our test user.
We have tried setting and clearing the limits in the form AR System User Preferences. No change
We have attempted to modify the active links and filters that are associated with the two bits of code above which would "deflect" my test user logon from executing any of the recently implemented code that seems to generate the error.
We have tested the limitations of the server by running high-result searches, which up to 10,000 entries have returned successfully (albeit a little slowly).
And for those ARS Admins concerned about the MT's Cache, we are flushing it after implementing new test code and before logging into the MT again.
We have checked arerror.log and found nothing major in there.
We have ran Active Link and Filter logging from both the WUT and the MT. We have also ran Filter logging on the server. Nothing shows "ARWARN 66" but the last bit of code that executes in all three situations before the ARWARN displays is the code for tracking users logging into the system.
FWIW: We are running in a Windows Server 2003 environment with MS SQL 2005. Some of our code was pushed out from ARS Admin Tool 7.0.01 patch 10 into our patch 3 server. We have resaved the primary default form from a downgraded (patch 3) version of the Admin tool. We have not changed the code on any of the tables.
Situation Analysis
After working with one of our vendors, we are working toward upgrading the server itself from 7.0.01 patch 003 to patch 010 due to a BMC ARS Software bug that causes ARWARN 66 when a filter has executed with an "Create New Request" or "Modify first result" action in it. Unfortunately, due to scheduling conflicts, we keep having to push this off.
However, we have somewhere around two-thousand filters in our system, none of which have caused this issue in the past. Many of which execute only on other forms, but upon loading of those other forms, even now, we still do not get this warning.
I am curious to find out if anyone else has had the ARWARN 66 mysteriously pop-up on their ARS Servers and what you have done to fix it or what troubleshooting steps you took to pin-down the issue.
