Determine what you are using the fields to capture and then remember that if you are going to need to do reports with these fields how you will get the data into the report. I have learned that by creating a copy of the view you added the new fields to with its unique name upgrades can be handled more easily since this view will not be updated. Ypu can also copy HPD:Helpdesk to a new form again this will not be updated.
-----Original Message----- From: Ravi <[EMAIL PROTECTED]> To: [email protected] Sent: Mon, 10 Sep 2007 8:18 pm Subject: HPD_HELP_DESK performance impact of adding fields Hi: I am in a environment with a fairly new Remedy 7.x implementation. Everytime we have a request for a new field, we end up adding the field in the main HPD_HELP_DESK form. What are the best practices around adding new fields. Specifically I am trying to address the following concerns? ? 1. if we keep adding fields, would my life get complicated when I want to upgrade Remedy to new versions in future?? 2. Is there a better way to approach this particular task of adding fields. For example, I have been told I should add the new/custom fields in another form and access them HPD_HELP_DESK with read only fields. This will keep the number of fields in HPD_HELP_DESK to a limited number, but will result in fields in another form. Will this help in not impacting the performance of the HPD_HELP_DESK form?? ? Looking for ideas/suggestions how others in this community handle such a task.? ? Thanks? Ravi? ? _______________________________________________________________________________? UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"? ________________________________________________________________________ Email and AIM finally together. You've gotta check out free AOL Mail! - http://mail.aol.com _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
