Sounds like maybe that is it. In my case the qualification is fixed. The table is just pulling in data from a configuration form and taking the appropriate actions depending on what matches are found (it is actually setting a zTmp field with a number pre-configured qualifications from the config form and evaluating them). It does make sense in your example that if a field is referenced in a loop and it changes it's value that something would need to refresh the SQL statement in the loop. Just curious, what versions are you using?
Jason On 3/29/07, David Sanders <[EMAIL PROTECTED]> wrote:
** Hi Jason Hmmm. I have a situation where I am setting a value to a field in filters, say a Group Name, and walking a table field with a filter guide to concatenate contact addresses for a notification (actually, a notification by phone using text to speech). If I do not have Refresh on Entry Change selected I get no results, but if it is checked I get the expected behavior. Actually, this might happen several times in the same transaction with different Group Names being set to the field used by the table field qualification, so the table field needs to refresh on the server each time this happens. Perhaps the difference here to what you're seeing is that fact that the field with the Group Name is initially blank when the transaction starts and needs to change one or more times. Is the table qualification you are using fixed? YMMV David Sanders Remedy Solution Architect *Enterprise** Service Suite @ Work* ========================== *ARS List Award Winner 2005* *Best 3rd party Remedy Application* tel +44 1494 468980 mobile +44 7710 377761 email [EMAIL PROTECTED] web http://www.westoverconsulting.co.uk ------------------------------ *From:* Action Request System discussion list(ARSList) [mailto: [EMAIL PROTECTED] *On Behalf Of *Jason Miller *Sent:* Thursday, March 29, 2007 4:22 PM *To:* [email protected] *Subject:* Re: Table Fields Is that true that you have to set a table to Refresh on Entry Change in order to used it in a filter? I just checked some tables that I use in filters and I don't have RoEC checked. Table fields are used a bit differently in filter guides then in a UI situation. It seems that the table fields was an easy object to "abuse" to add the filter looping functionality since they performed similar functions (<select X, Y, Z, from Txxxxx where Z = 'xxxxx' order be Y desc>. Kind of like how Tree fields have been added to a table fields in v7). From what I can gather the table field used by a filter more or less sets up the SQL statement but really doesn't care much about any of the more visual/UI type properties (makes sense since it is only used server side). Jason *From:* Action Request System discussion list(ARSList) [mailto: [EMAIL PROTECTED] *On Behalf Of *David Sanders *Sent:* Thursday, March 29, 2007 4:18 AM *To:* [email protected] *Subject:* Re: Table Fields ** Hi Warren The key point here is that the tables would be accessed by filters. Does this mean that you would not need to display these table fields to users – in other words could the tables be removed from the user-accessible views? If so, I believe that the potential problems that others have pointed out, such as def size and caching, might be avoided. You can select one view containing these table fields as the master view for server-side processing (filter guides). But, and here's the rub, to be able to use the tables in filters you will need to have them set to refresh on entry change. I've never had enough table fields accessed by filter workflow to know how much of a performance hit this might be, but after doing what you propose, you might be able to supply the answer. Good luck David Sanders Remedy Solution Architect *Enterprise** Service Suite @ Work* ========================== *ARS List Award Winner 2005* *Best 3rd party Remedy Application* tel +44 1494 468980 mobile +44 7710 377761 email [EMAIL PROTECTED] web http://www.westoverconsulting.co.uk ------------------------------ *From:* Action Request System discussion list(ARSList) [mailto: [EMAIL PROTECTED] *On Behalf Of *Warren Baltimore *Sent:* Wednesday, March 28, 2007 5:08 PM *To:* [email protected] *Subject:* Table Fields ** ARS 7.0.1 SQL 2000 OK my friends, just for "kicks", here's a fun little question..... What are the limitations (both real and theroetical) to putting LOTS and LOTS of Tables on a form. What would be the limitation (performance certainly being the big one). Is there a real limit? If the tables are only accessed via filter operations, would that make it better? I can't give any concrete information regarding the tables other than they would probably be accessing seperate tables (for the most part) and would probably only have a few fields in them. -- Warren R. Baltimore II Remedy Developer UW Medicine IT Services School of Medicine University of Washington Box 358220 1325 Fourth Ave, Suite 2000 Seattle, WA 98101 The opinions expressed in this e-mail are in no way those of the University of Washington, or the State of Washington. They are my own. __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
