Before trying to do a reload of ARS I would either do a stop/start of the AR System or run the arsignal command to recache the definitions arsignal -g hostname[:port]
For ARS 6.3 the -g option causes the server to reload group and data dictionary information from the database. For ARS 7.1 use the -r option for the definitions from the database (-g is Group Information only). Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Bill Bookers Sent: Wednesday, November 19, 2008 9:55 AM To: arslist@ARSLIST.ORG Subject: Problem with view forms ** Greetings, I'm having a problem with view forms, more specifically I believe it's a problem with the mechanism wheby the view forms "talk" to their respective external tables. First, the setup: ARS 6.3 patch 22 Remedy Help Desk 6.0 MS-SQL server 2005 (9.0.2047) Windows 2003 server A couple of days ago, an escalation got away from us and our CPU usage was 95 or 100 percent until we took care of the escalation. Tbrought the CPU usage back down. At the time we didn't think there was any damage and everything had remained operable (if a bit slower) in the meantime. Yesterday, we noticed a problem with our two view forms. The view forms correspond to respective SQL tables outside of the ARSystem database (but within the same MS-SQL server). We have an escalation that pushes data from HPD:Helpdesk to one of the view forms, and another escalation that pushes from the second view form back to HPD:Helpdesk. The first escalation is working, the second does not (or occasionally, at best). There are about 11,000 rows in each of the view forms. If I try and view these records via the view form in the User Client, I can't see those where the RequestID is higher than 9999, e.g. 10000, 10001, 10002 etc. simply pull up as "1000" and it just shows row 1000 over and over. If I look at these tables directly in SQL the data (and the numbering) is fine. Coincidentally (or not?) when this number rolled over to 10,000, it was around the same time (maybe a little while before) our CPU pegged high. I did notice that the column for the key field had a lenght of 4 bytes. It's an integer which would allow some number up in the billions (I think), but if it was treating this as text then 10000 would exceed 4 bytes, so maybe that's why it truncates 10000 and higher to "1000". (This is the same setup as in our development and test platforms, where it all works OK.) I looked at the view forms in the Admin Client. When the form opens, it immediately warns me that it can't find the external table: "Requested database table not found. Please check the spelling (table name is case-sensitive) (ARERR 481)." If I look at the view information, it shows the table name as "???????????????????n?1?" instead of the real name (and the number of "?" characters does not correspond to the number of characters in the table name). The table name looks OK in SQL (and again, all the data is intact). Moreover if I go into the view form in SQL (ARSystem > Views > dbo.real_table_name) the data and numbering are OK there, too. I went into ARSystem > Tables > dbo.schema_view and it lists my external tables, with the correct tableName and keyField. I tried creating a new table in a new database, and creating a Remedy view form based on that. I added the fields and before I saved the form, I checked the view information and again it had replaced the table name with a bunch of question marks. Another thing I tried was to import the same view form(s) from a definition file and overwrite those currently on the server. This didn't work, it seemed to think I was changing the existing form to another kind of form: "Invalid compound form structure change: (ARERR 274)" My own assessment: Since the external table data is OK and ARS is otherwise working, this leads me to believe there's a problem with the mechanism whereby ARS reads data from the tables into the view form (a write to the view form is OK, which would explain why the first of the 2 escalations still works). Any ideas on what happened and/or how I might safely go about fixing this? My inclination is that something became corrupted during the high CPU activity, and to re-install ARS 6.3 patch 22 using "upgrade." Thanks in advance, Bill Bookers __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
