Re: Table fields displaying 1 hour difference from searched date.
So it seems like the table itself may not be the issue, though i'm not
entirely sure. What I setup was a display form with two date/time fields
for input, a character field for the EXTERNAL(query), and the table field
pointed to one of our most populated forms.
What I found out was this:
I created workflow that takes the two date fields and puts them into the
character field so the resulting string looks like this:
'Create Date' = 8/3/2010 8:00:00 AM AND 'Create Date' = 8/5/2010
11:00:00 AM
In my table qualification I have: EXTERNAL('Character Field')
When I refresh the table, the table searches and displays results as if the
following query is ran:
'Create Date' = 8/3/2010 9:00:00 AM AND 'Create Date' = 8/5/2010
12:00:00 PM -- Notice the one hour difference
Now I replaced the qualification for the table: EXTERNAL('Character Field'),
with the actual qualification I'm trying to run:
'Create Date' = 8/3/2010 8:00:00 AM AND 'Create Date' = 8/5/2010
11:00:00 AM
When I refresh the table field, the values now accurately display from
8/3/2010 8:00:00 AM to 8/5/2010 11:00:00 AM. Hmm, I think to myself,
There must be an issue with searching with dates using the EXTERNAL
function.
I now replace the qualification string for the table with:
('Create Date' = $Date/Time Field$) AND ('Create Date' = $Date/Time
Field2$)
Therein by taking EXTERNAL() completely out of the loop. I enter 8/3/2010
8:00:00 AM into $Date/Time Field$ and 8/5/2010 12:00:00 PM into
$Date/Time Field2$ and refresh the table.
The results show correct!! The date/time span return match the search
criteria accurately. So there seems to be an issue when searching table
fields with date ranges using the EXTERNAL() function.
Not sure if this was mentioned before on the list, sorry if it was, this bug
has been running me and my QA team around in loops.
Just thought I would share. Thanks for listening :D
On Thu, Aug 5, 2010 at 3:35 PM, Robert Halstead badbee...@gmail.com wrote:
Hey all,
We're seeing a discrepancy when displaying data in a table field. If the
table field is searching a date range of tickets, the table field seems to
display tickets that are an hour ahead. It seems the client takes the
date/time in the date/time fields and applies +1 hour to them and then
returns the result of that search.
Searching the same date range on the form itself returns the proper
listing.
This behavior doesn't exist with the mid-tier. Performing the same actions
in the mid-tier, the results are what is expect with both the table and the
form displaying the same search results. Only in the client does it seem to
differ.
This seems to be an issue with the timezone and table fields. I was
wondering if anyone else has been incurring this as well?
AR Server 7.5 Patch 004
Mid-Tier 7.5 Patch 004
WUT 7.5 Patch 004
Let me know if more information is needed. I thought I'd hit up the list
before I created a ticket with BMC.
--
A fool acts, regardless; knowing well that he is wrong. The ignoramus acts
on only what he knows, but all that he knows.
The ignoramus may be saved, but the fool knows that he is doomed.
Bob Halstead
--
A fool acts, regardless; knowing well that he is wrong. The ignoramus acts
on only what he knows, but all that he knows.
The ignoramus may be saved, but the fool knows that he is doomed.
Bob Halstead
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: Table Fields
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:* arslist@ARSLIST.ORG *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 Tx where Z = 'x' 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:* arslist@ARSLIST.ORG *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:* arslist@ARSLIST.ORG *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
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 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: arslist@ARSLIST.ORG 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___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
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 Tx where Z = 'x' 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: arslist@ARSLIST.ORG 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 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: arslist@ARSLIST.ORG 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___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Table Fields
Talk to Ed White at OSUMC He'll attest to the fact that in my early years, I built some ungodly forms (one I believe has hit the limitation to the no. of fields that Remedy will allow! I want to thank you and everyone else for the great responses! Not only did it give me some real information to which I could intelligently answer the question, but it had me ROLLING on the floor laughing Thanks again to everyone who took the time! Warren On 3/28/07, Carey Matthew Black [EMAIL PROTECTED] wrote: Warren, If I can come up with an answer will you build the form? :) Well... theoretically The field ID space is as large as the positive range of a regular integer. :) 2,147,483,647 ( I think) So if each table field had only 1 column then you need two field ID's per table field. So the limit might be about 754305817. ( Maybe as high as 1022740773 if you break a few more rules, but likely is practically limited at that number. However if you break even more rules you could get an extra 500 table fields if the special field ID's do not product unexpected function of the tables.) So when can I expect that form with 754305867 two column table fields? (Note: I picked the most conservative number from the above. I am trying to be nice. :) I wonder how big that form definition would be. :) Here is how I got that answer: ( for the interested. :) You have a few core fields to account for... 9 by my count (1,2,3,4,5,6,7,8,15[15 for Status History]) and one VUI ID value for the default view. I do not think ARS will let you create a field ID with the same value as the VUI ID. (Just tested this on v6.3 and you can NOT have a field ID the same as any VUI ID value.) Although I think you could avoid 9 of those core fields by using a Display only form too. :) Then you would only have one field ID that you must use for the VUI ID. :) But for this example I will assume a Regular form. :) But there are also the reserved ranges (which you might want to avoid, but could partially violate if you decided too. :) basically 1-536870912 [ including the 10 specific ones above] So...(because we do want to be good) 2,147,483,647 - 536870912= 1610612735 total field ID's for use by a customer on a form. Yes some other ranges exist for special reasons and could add some limitations too: 1-99 : Core fields (-100) 6-60999 : Dynamic groups ( -1000) 100–199 : Global fields ( -100) 300–399 : Window Scoped Global fields ( -100) So (because we do want to be good) that brings the number down to: 1610612735 - 100 - 1000 - 200 = 1508611635 ( You might actually be able to use 200 of those fieldID's, but I would avoid the Dynamic Groups fields. The behavior would likely be very strange if you used those.) So.. if each table field takes 2 field IDs then that leaves you with... INT(1508611635/2) = 754305817 total one column table fields you could put on a single ARS form. ( Again... theoretically. And good luck getting that form to render on the Mid-Tier. :) If you want to be bad and use the reserved range then you have an additional: 536870912 - 100 = 536870812 field IDs And that would be INT((1508611735+536870812)/2) = 1022741273 Total Table fields if you ignore all special ranges And as many as: INT((1508611735+536870812-1000)/2) =1022740773 Total Table fields if you only honor the dynamic groups special range And I think that is you true final answer for how many table fields you could add to a Regular form. (+5 more if it is a display only form. :) How you would show that many table fields... well that is your problem. :) I guess you might want to subtract two more field ID's from that set (or one table field) and keep them for a button to give the user a dialog to pick from a list of tables to show in a table field on the dialog. :) The dialog would need to return a value that other active links could do hide/show actions on to show the right table field on the local form. HTH. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 3/28/07, Warren Baltimore [EMAIL PROTECTED] wrote: ** 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
Re: Table Fields
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 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: arslist@ARSLIST.ORG 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 Tx where Z = 'x' 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: arslist@ARSLIST.ORG 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 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: arslist@ARSLIST.ORG 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___
Re: Table Fields
Warren, At the risk of saying what you alreaady know knowing your experience with the system, I would definitely look for the following: 1) INDEXES on fields that are used in the qualification that qualify for indexes on tables that are called by these table fields. 2) Write the queries in the format where the 'Field Name' is to the left side of the $Field Name$ so the indexes defined on them would be used. 3) Chunk as many of these table fields as you can if you would not be using the $LASTCOUNT$ or similar keywords on ur workflow that counts entries on the table field in question. 4) Refresh only the necessary table fields on Window Open, Display, Undisplay, Window Loaded.. 5) And for your own good and the good of other developers who might have to take a look at your table sometime in the near future, have a naming conventions for the columns of the table and don't leave it as a default Column 1, Column 2.. etc.. 10 minutes after building the table when creating workflow for these tables you are harldy likely to know what Column 345 is if you do not have a good naming convention.. I thought the last one is the most useful tip for you in your situation.. The naming convention I follow is.. lets say I am having a table field on a Trouble Ticket Form.. I call this table field Tbl_TroubleTicketForm. The Request ID column for eg in that table field will be named Col_TTF_RequestID. TTF stands for TroubleTicketForm.. This way I have all the columns of a table field one after another in a sequence. I have similar conventions for Field ID's too that I use for stuff like table fields etc.. but you could come up with your own.. its not a hard and fast thing.. Just stuff that I came up with over the time I have worked with the AR System.. I have found these methods very useful.. Hope you find these tips of some use... Cheers Joe D'Souza Remedy Developer / Consultant, BearingPoint Inc., New Jersey. - Original Message From: Warren Baltimore [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Wednesday, March 28, 2007 5:07:30 PM 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 Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Table Fields
Warren, Wouldn't the only answer to this be It depends? How many tables? Lots? okay I don't know of an upper limit on table fields but I'm sure there would be a point of diminishing returns. How many columns? A few times Lots of tables? Still okay . Now, How many rows? A few for each table? Again, it's probably okay. I guess I am lost on the filter operations part. Table fields will always be connected and activated by some client side event. Click to refresh or some PERFORM-ACTION-TABLE-xxx AL or Run Process. Keep it to a manageable number, don't refresh them all at once and you should only hobble your system, not cripple it. Seriously, it really all depends on the scope of the underlying forms. The more complex the retrieval method the more overhead. Does the EXTERNAL keyword cause an extra layer of traffic or does it help short circuit the query? What about Loading a temp table (form) and pulling that into one table with mixed columns. Like the Helpdesk Control panel ( Sorry, I don't know the real name of the conglomerate table for Incidents, Problems Service requests et al.) mid week musings John J. Reiser Software Development Analyst Remedy Administrator/Developer Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Warren Baltimore Sent: Wednesday, March 28, 2007 5:08 PM To: arslist@ARSLIST.ORG 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___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Table Fields
To add to my previous post, theoretically there should be no effect of the number of table fields you create on a form as a creation of a table field does not create a column in the T or H or B tables so even the underlying database restrictions of max number of columns a table can have won't come into play.. You however wouldn't want your forms to be so thickly populated with table fields that opening up your form on the client would create 10 terabytes of cache.. each table field will create a separate cache file on a client when a form is opened and you dont want loads of that stuff to happen.. it will severely hamper performance.. Joe - Original Message From: Warren Baltimore [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Wednesday, March 28, 2007 5:07:30 PM 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 Don't get soaked. Take a quick peek at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Table Fields
Warren, I think you hit it with performance. There are some many if's that can come in to play. Number of records returned in each table, the tables referencing join forms, indexes on the forms, etc. I've created a display only form that has 4 table fields. Workflow runs a Active Link Guide looping over the primary table of between 2 to 3 thousand records. The guide drives table refreshes on the other 3 tables. I couldn't figure out how to refresh the tables using filters so I used active links. Others probably have more complicated processes with more tables. Dave -- [EMAIL PROTECTED] (Wireless) - Original Message - From: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG To: arslist@ARSLIST.ORG arslist@ARSLIST.ORG Sent: Wed Mar 28 17:07:30 2007 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___
Re: Table Fields
Warren, If I can come up with an answer will you build the form? :) Well... theoretically The field ID space is as large as the positive range of a regular integer. :) 2,147,483,647 ( I think) So if each table field had only 1 column then you need two field ID's per table field. So the limit might be about 754305817. ( Maybe as high as 1022740773 if you break a few more rules, but likely is practically limited at that number. However if you break even more rules you could get an extra 500 table fields if the special field ID's do not product unexpected function of the tables.) So when can I expect that form with 754305867 two column table fields? (Note: I picked the most conservative number from the above. I am trying to be nice. :) I wonder how big that form definition would be. :) Here is how I got that answer: ( for the interested. :) You have a few core fields to account for... 9 by my count (1,2,3,4,5,6,7,8,15[15 for Status History]) and one VUI ID value for the default view. I do not think ARS will let you create a field ID with the same value as the VUI ID. (Just tested this on v6.3 and you can NOT have a field ID the same as any VUI ID value.) Although I think you could avoid 9 of those core fields by using a Display only form too. :) Then you would only have one field ID that you must use for the VUI ID. :) But for this example I will assume a Regular form. :) But there are also the reserved ranges (which you might want to avoid, but could partially violate if you decided too. :) basically 1-536870912 [ including the 10 specific ones above] So...(because we do want to be good) 2,147,483,647 - 536870912= 1610612735 total field ID's for use by a customer on a form. Yes some other ranges exist for special reasons and could add some limitations too: 1-99 : Core fields (-100) 6-60999 : Dynamic groups ( -1000) 100–199 : Global fields ( -100) 300–399 : Window Scoped Global fields ( -100) So (because we do want to be good) that brings the number down to: 1610612735 - 100 - 1000 - 200 = 1508611635 ( You might actually be able to use 200 of those fieldID's, but I would avoid the Dynamic Groups fields. The behavior would likely be very strange if you used those.) So.. if each table field takes 2 field IDs then that leaves you with... INT(1508611635/2) = 754305817 total one column table fields you could put on a single ARS form. ( Again... theoretically. And good luck getting that form to render on the Mid-Tier. :) If you want to be bad and use the reserved range then you have an additional: 536870912 - 100 = 536870812 field IDs And that would be INT((1508611735+536870812)/2) = 1022741273 Total Table fields if you ignore all special ranges And as many as: INT((1508611735+536870812-1000)/2) =1022740773 Total Table fields if you only honor the dynamic groups special range And I think that is you true final answer for how many table fields you could add to a Regular form. (+5 more if it is a display only form. :) How you would show that many table fields... well that is your problem. :) I guess you might want to subtract two more field ID's from that set (or one table field) and keep them for a button to give the user a dialog to pick from a list of tables to show in a table field on the dialog. :) The dialog would need to return a value that other active links could do hide/show actions on to show the right table field on the local form. HTH. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 3/28/07, Warren Baltimore [EMAIL PROTECTED] wrote: ** 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___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Slightly OT: Re: Table Fields
Ok I know we are talking assumptions out here considering you can create about 754305817 - theoretically... So lets assume that on the client, the client is fast enough to process about 100 cache files per second.. as it would need to process (either create or read) approximately 754305817 cache files.. So that would mean (I just calculated this for fun) the client would take about 87 days and a third of the 88th day to open that form.. Even if a client was 10 times faster and was able to process 1000 files at a time it would still mean it would take about 8 and a half days.. :-) I wonder how many days it would take to create a such a form assuming it might take about 5 minutes to create each table field... and then X amount of undeterminable time to save a form with that many objects in it :-) We might be on ARS version 10 or so by then.. Joe - Original Message From: Carey Matthew Black [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Wednesday, March 28, 2007 6:50:38 PM Subject: Re: Table Fields Warren, If I can come up with an answer will you build the form? :) Well... theoretically The field ID space is as large as the positive range of a regular integer. :) 2,147,483,647 ( I think) So if each table field had only 1 column then you need two field ID's per table field. So the limit might be about 754305817. ( Maybe as high as 1022740773 if you break a few more rules, but likely is practically limited at that number. However if you break even more rules you could get an extra 500 table fields if the special field ID's do not product unexpected function of the tables.) So when can I expect that form with 754305867 two column table fields? (Note: I picked the most conservative number from the above. I am trying to be nice. :) I wonder how big that form definition would be. :) Here is how I got that answer: ( for the interested. :) You have a few core fields to account for... 9 by my count (1,2,3,4,5,6,7,8,15[15 for Status History]) and one VUI ID value for the default view. I do not think ARS will let you create a field ID with the same value as the VUI ID. (Just tested this on v6.3 and you can NOT have a field ID the same as any VUI ID value.) Although I think you could avoid 9 of those core fields by using a Display only form too. :) Then you would only have one field ID that you must use for the VUI ID. :) But for this example I will assume a Regular form. :) But there are also the reserved ranges (which you might want to avoid, but could partially violate if you decided too. :) basically 1-536870912 [ including the 10 specific ones above] So...(because we do want to be good) 2,147,483,647 - 536870912= 1610612735 total field ID's for use by a customer on a form. Yes some other ranges exist for special reasons and could add some limitations too: 1-99 : Core fields (-100) 6-60999 : Dynamic groups ( -1000) 100–199 : Global fields ( -100) 300–399 : Window Scoped Global fields ( -100) So (because we do want to be good) that brings the number down to: 1610612735 - 100 - 1000 - 200 = 1508611635 ( You might actually be able to use 200 of those fieldID's, but I would avoid the Dynamic Groups fields. The behavior would likely be very strange if you used those.) So.. if each table field takes 2 field IDs then that leaves you with... INT(1508611635/2) = 754305817 total one column table fields you could put on a single ARS form. ( Again... theoretically. And good luck getting that form to render on the Mid-Tier. :) If you want to be bad and use the reserved range then you have an additional: 536870912 - 100 = 536870812 field IDs And that would be INT((1508611735+536870812)/2) = 1022741273 Total Table fields if you ignore all special ranges And as many as: INT((1508611735+536870812-1000)/2) =1022740773 Total Table fields if you only honor the dynamic groups special range And I think that is you true final answer for how many table fields you could add to a Regular form. (+5 more if it is a display only form. :) How you would show that many table fields... well that is your problem. :) I guess you might want to subtract two more field ID's from that set (or one table field) and keep them for a button to give the user a dialog to pick from a list of tables to show in a table field on the dialog. :) The dialog would need to return a value that other active links could do hide/show actions on to show the right table field on the local form. HTH. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 3/28/07, Warren Baltimore [EMAIL PROTECTED] wrote: ** 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
Re: Table Fields
Or doing set field with a colcount. -- Jarl On 12/19/06, Aaron Keller [EMAIL PROTECTED] wrote: ** first refresh the table, and then look to see if $LASTCOUNT$ = 0 -Aaron * Email: [EMAIL PROTECTED] From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kemes, Lisa Sent: Tuesday, December 19, 2006 2:59 PM To: arslist@ARSLIST.ORG Subject: Table Fields Hello Listers! How can you test to see if there is nothing in a Table Field? I tried 'Table Field' = $NULL$, but nothing happens. I want to create workflow if a Table Field is NULL (no rows) Let me know if anyone has the answer! Thanks! Lisa SunCom is the wireless company that's committed to doing things differently. Things we want you to know. This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication may contain material protected by the attorney-client privilege. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. __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
Re: Table Fields
Yes, I see. I had Refresh Row Selection set to Retain Selection, fire Workflow. Correctly detected null before refresh. Correctly detected non-null after refresh - for which there were matching requests. Incorrectly detected non-null after refresh for which there were no matching requests (value = 0). Sorry; I'm back with you now. $COLCOUNT$ would likely be the most reliable, but you'd need to make sure you have a fully-populated column, like Request ID. It seems to me that $LASTCOUNT$ could be risky; other workflow could execute a search, disturbing your count from a TF refresh before you test it. Manageable, but you'd need to be extra careful. Mike White Office: 813-978-2192 E-mail: [EMAIL PROTECTED] Joe DeSouza [EMAIL PROTECTED]To: arslist@ARSLIST.ORG .COMcc: Sent by: Action Subject: Re: Table Fields Request System discussion list(ARSList) [EMAIL PROTECTED] ORG 12/19/2006 16:52 Please respond to arslist ** Mike, for that to work you have to make sure that your table field is refreshed and the table field has the right options in its advanced display such as retain selection or select first request etc.. with no selection you would get a null return. When you have retain your selection on refresh, if the selection that was previously chosen has been deleted or removed due to change on that entry, then there will be no selection causing a null return again.. Joe - Original Message From: Mike White [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Tuesday, December 19, 2006 3:35:45 PM Subject: Re: Table Fields I missed something. What's wrong with 'Table Field' = $NULL$? I'm not sure how you're using it, though. I just added a table field and button to a test form, and a new AL, triggered by the button, with a Run If 'Table Field' = $NULL$. If action displays a message It's null and Else action displays a message It's not null, instead it's value is $Table Field$ I tested both scenarios and it worked fine. I'm running ARS 6.0.1, patch 1497. The value of 'Table Field (the name of your table field) is the current row number. It's null if there are no rows in the table field. It's 0 if there are rows, but none has been selected. It's 0 if a row is selected. You'll want to make sure that you refreshed the table field before testing it, and that no other workflow or user action cleared the table field. Mike White Office: 813-978-2192 E-mail: [EMAIL PROTECTED] Kemes, Lisa [EMAIL PROTECTED]To: arslist@ARSLIST.ORG RONICS.COM cc: Sent by: Action Subject: Re: Table Fields Request System discussion list(ARSList) arslist@ARSLIST.ORG nbs p; 12/19/2006 15:19 Please respond to arslist n bsp; n bsp
Re: Table Fields
There are several approaches to this concern. A) Do two actions in one active link. Change Field -- refresh table Set Field -- stuff $LASTCOUNT$ into a temp field. Or... B) Do two active links separated by one execution order: AL1 : Execution order 10 Change Field -- refresh table AL2 : Execution order 11 Run IF: Test based on $LASTCOUNT$ OR Set Field -- stuff $LASTCOUNT$ into a temp field. Or... (for the real paranoid) C) Use an Active Link guide to make sure no one accidentally slips in another active link at the second execution order or mucks with the temp field value. (Can be used in combination with either of the above design patterns.) -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 12/20/06, Mike White [EMAIL PROTECTED] wrote: snip It seems to me that $LASTCOUNT$ could be risky; other workflow could execute a search, disturbing your count from a TF refresh before you test it. Manageable, but you'd need to be extra careful. Mike White Office: 813-978-2192 E-mail: [EMAIL PROTECTED] ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Table Fields
Pick a column that will have a value and test against that. I usually have a column of the Request ID (can be hidden) in the table that I test against Fred From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kemes, Lisa Sent: Tuesday, December 19, 2006 1:59 PM To: arslist@ARSLIST.ORG Subject: Table Fields ** Hello Listers! How can you test to see if there is nothing in a Table Field? I tried 'Table Field' = $NULL$, but nothing happens. I want to create workflow if a Table Field is NULL (no rows) Let me know if anyone has the answer! Thanks! Lisa ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Table Fields
Can you use $LASTCOUNT$ on a table field? Or is it just to see how many rows were returned when doing a search on a form. I have ARS 6.3 and Remedy user 6.3. From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Keller Sent: Tuesday, December 19, 2006 3:05 PM To: arslist@ARSLIST.ORG Subject: Re: Table Fields ** first refresh the table, and then look to see if $LASTCOUNT$ = 0 -Aaron * Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kemes, Lisa Sent: Tuesday, December 19, 2006 2:59 PM To: arslist@ARSLIST.ORG Subject: Table Fields Hello Listers! How can you test to see if there is nothing in a Table Field? I tried 'Table Field' = $NULL$, but nothing happens. I want to create workflow if a Table Field is NULL (no rows) Let me know if anyone has the answer! Thanks! Lisa SunCom is the wireless company that's committed to doing things differently. Things we want you to know. This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication may contain material protected by the attorney-client privilege. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. __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
Re: Table Fields
It's very strange, this works just fine if I don't refresh anything, but once I do (and the table is null) then it does not work. What I'm doing is refreshing this table from the info of another table. -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Mike White Sent: Tuesday, December 19, 2006 3:36 PM To: arslist@ARSLIST.ORG Subject: Re: Table Fields I missed something. What's wrong with 'Table Field' = $NULL$? I'm not sure how you're using it, though. I just added a table field and button to a test form, and a new AL, triggered by the button, with a Run If 'Table Field' = $NULL$. If action displays a message It's null and Else action displays a message It's not null, instead it's value is $Table Field$ I tested both scenarios and it worked fine. I'm running ARS 6.0.1, patch 1497. The value of 'Table Field (the name of your table field) is the current row number. It's null if there are no rows in the table field. It's 0 if there are rows, but none has been selected. It's 0 if a row is selected. You'll want to make sure that you refreshed the table field before testing it, and that no other workflow or user action cleared the table field. Mike White Office: 813-978-2192 E-mail: [EMAIL PROTECTED] Kemes, Lisa [EMAIL PROTECTED]To: arslist@ARSLIST.ORG RONICS.COM cc: Sent by: Action Subject: Re: Table Fields Request System discussion list(ARSList) arslist@ARSLIST.ORG 12/19/2006 15:19 Please respond to arslist ** Can you use $LASTCOUNT$ on a table field? Or is it just to see how many rows were returned when doing a search on a form. I have ARS 6.3 and Remedy user 6.3. From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Keller Sent: Tuesday, December 19, 2006 3:05 PM To: arslist@ARSLIST.ORG Subject: Re: Table Fields ** first refresh the table, and then look to see if $LASTCOUNT$ = 0 -Aaron * Email: [EMAIL PROTECTED] From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kemes, Lisa Sent: Tuesday, December 19, 2006 2:59 PM To: arslist@ARSLIST.ORG Subject: Table Fields Hello Listers! How can you test to see if there is nothing in a Table Field? I tried 'Table Field' = $NULL$, but nothing happens. I want to create workflow if a Table Field is NULL (no rows) Let me know if anyone has the answer! Thanks! Lisa SunCom is the wireless company that's committed to doing things differently. Things we want you to know. This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication may contain material protected by the attorney-client privilege. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. __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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Table Fields
It could be that the table is set to not select a row and do not fire workflow of the table is not being refreshed when the form with the table come up. *Rocky* Rocky Rockwell eMA Team – Remedy Developer [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Ph#1: 214-567-8874 Ph#2: 325-884-1263 Kemes, Lisa wrote: ** Hello Listers! How can you test to see if there is nothing in a Table Field? I tried 'Table Field' = $NULL$, but nothing happens. I want to create workflow if a Table Field is NULL (no rows) Let me know if anyone has the answer! Thanks! Lisa __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Table Fields
Lisa, If you have table chunking enabled to the best of my knowledge $LASTCOUNT$ would return the number of rows in the current chunk up to a max of the limit your chunk is set at. You might be better off using a direct sql to return the count of the query you are running on the table field to get the real count in this case. And yes to answer your question $LASTCOUNT$ would return the integer that contains the count of table field in your current chunk. Rgds Joe - Original Message From: Kemes, Lisa [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Tuesday, December 19, 2006 3:19:23 PM Subject: Re: Table Fields ** Can you use $LASTCOUNT$ on a table field? Or is it just to see how many rows were returned when doing a search on a form. I have ARS 6.3 and Remedy user 6.3. From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Keller Sent: Tuesday, December 19, 2006 3:05 PM To: arslist@ARSLIST.ORG Subject: Re: Table Fields ** first refresh the table, and then look to see if $LASTCOUNT$ = 0 -Aaron * Email: [EMAIL PROTECTED] From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kemes, Lisa Sent: Tuesday, December 19, 2006 2:59 PM To: arslist@ARSLIST.ORG Subject: Table Fields Hello Listers! How can you test to see if there is nothing in a Table Field? I tried 'Table Field' = $NULL$, but nothing happens. I want to create workflow if a Table Field is NULL (no rows) Let me know if anyone has the answer! Thanks! Lisa SunCom is the wireless company that's committed to doing things differently. Things we want you to know. This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication may contain material protected by the attorney-client privilege. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. __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___ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Table Fields
From the docs: $LASTCOUNT$ The number of requests returned from the most recent search. You can use this keyword with any search, including one run from the search window, a search menu, a Set Fields operation, a macro, a table refresh, and so on. Note: The $LASTCOUNT$ keyword is not expanded when default values are set. This allows the value to be set to at the time the form is submitted rather than the time the form is opened. This also means that the literal keyword is displayed in the field before the request is submitted. -Aaron * Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kemes, Lisa Sent: Tuesday, December 19, 2006 3:19 PM To: arslist@ARSLIST.ORG Subject: Re: Table Fields Can you use $LASTCOUNT$ on a table field? Or is it just to see how many rows were returned when doing a search on a form. I have ARS 6.3 and Remedy user 6.3. From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Keller Sent: Tuesday, December 19, 2006 3:05 PM To: arslist@ARSLIST.ORG Subject: Re: Table Fields ** first refresh the table, and then look to see if $LASTCOUNT$ = 0 -Aaron * Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kemes, Lisa Sent: Tuesday, December 19, 2006 2:59 PM To: arslist@ARSLIST.ORG Subject: Table Fields Hello Listers! How can you test to see if there is nothing in a Table Field? I tried 'Table Field' = $NULL$, but nothing happens. I want to create workflow if a Table Field is NULL (no rows) Let me know if anyone has the answer! Thanks! Lisa SunCom is the wireless company that's committed to doing things differently. Things we want you to know. This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication may contain material protected by the attorney-client privilege. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. __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
Re: Table Fields
Mike, for that to work you have to make sure that your table field is refreshed and the table field has the right options in its advanced display such as retain selection or select first request etc.. with no selection you would get a null return. When you have retain your selection on refresh, if the selection that was previously chosen has been deleted or removed due to change on that entry, then there will be no selection causing a null return again.. Joe - Original Message From: Mike White [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Tuesday, December 19, 2006 3:35:45 PM Subject: Re: Table Fields I missed something. What's wrong with 'Table Field' = $NULL$? I'm not sure how you're using it, though. I just added a table field and button to a test form, and a new AL, triggered by the button, with a Run If 'Table Field' = $NULL$. If action displays a message It's null and Else action displays a message It's not null, instead it's value is $Table Field$ I tested both scenarios and it worked fine. I'm running ARS 6.0.1, patch 1497. The value of 'Table Field (the name of your table field) is the current row number. It's null if there are no rows in the table field. It's 0 if there are rows, but none has been selected. It's 0 if a row is selected. You'll want to make sure that you refreshed the table field before testing it, and that no other workflow or user action cleared the table field. Mike White Office: 813-978-2192 E-mail: [EMAIL PROTECTED] Kemes, Lisa [EMAIL PROTECTED]To: arslist@ARSLIST.ORG RONICS.COM cc: Sent by: Action Subject: Re: Table Fields Request System discussion list(ARSList) arslist@ARSLIST.ORG 12/19/2006 15:19 Please respond to arslist ** Can you use $LASTCOUNT$ on a table field? Or is it just to see how many rows were returned when doing a search on a form. I have ARS 6.3 and Remedy user 6.3. From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Keller Sent: Tuesday, December 19, 2006 3:05 PM To: arslist@ARSLIST.ORG Subject: Re: Table Fields ** first refresh the table, and then look to see if $LASTCOUNT$ = 0 -Aaron * Email: [EMAIL PROTECTED] From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kemes, Lisa Sent: Tuesday, December 19, 2006 2:59 PM To: arslist@ARSLIST.ORG Subject: Table Fields Hello Listers! How can you test to see if there is nothing in a Table Field? I tried 'Table Field' = $NULL$, but nothing happens. I want to create workflow if a Table Field is NULL (no rows) Let me know if anyone has the answer! Thanks! Lisa SunCom is the wireless company that's committed to doing things differently. Things we want you to know. This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication may contain material protected by the attorney-client privilege. If you are not the intended recipient or the person responsible for delivering the e-mail
Re: Table Fields
'Table Field' stores a value of the row number which is selected. If none is selected, It will return 0 doesn't matter if there are any rows in table or not So I think, You need to refresh and use Last Count to see if there are any records in the table or not -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe DeSouza Sent: Tuesday, December 19, 2006 3:53 PM To: arslist@ARSLIST.ORG Subject: Re: Table Fields ** Mike, for that to work you have to make sure that your table field is refreshed and the table field has the right options in its advanced display such as retain selection or select first request etc.. with no selection you would get a null return. When you have retain your selection on refresh, if the selection that was previously chosen has been deleted or removed due to change on that entry, then there will be no selection causing a null return again.. Joe - Original Message From: Mike White [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Tuesday, December 19, 2006 3:35:45 PM Subject: Re: Table Fields I missed something. What's wrong with 'Table Field' = $NULL$? I'm not sure how you're using it, though. I just added a table field and button to a test form, and a new AL, triggered by the button, with a Run If 'Table Field' = $NULL$. If action displays a message It's null and Else action displays a message It's not null, instead it's value is $Table Field$ I tested both scenarios and it worked fine. I'm running ARS 6.0.1, patch 1497. The value of 'Table Field (the name of your table field) is the current row number. It's null if there are no rows in the table field. It's 0 if there are rows, but none has been selected. It's 0 if a row is selected. You'll want to make sure that you refreshed the table field before testing it, and that no other workflow or user action cleared the table field. Mike White Office: 813-978-2192 E-mail: [EMAIL PROTECTED] Kemes, Lisa [EMAIL PROTECTED]To: arslist@ARSLIST.ORG RONICS.COM cc: Sent by: Action Subject: Re: Table Fields Request System discussion list(ARSList) arslist@ARSLIST.ORG nbs p; 12/19/2006 15:19 Please respond to arslist n bsp; n bsp; ** Can you use $LASTCOUNT$ on a table field? Or is it just to see how many rows were returned when doing a search on a form. I have ARS 6.3 and Remedy user 6.3. From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Keller Sent: Tuesday, December 19, 2006 3:05 PM To: arslist@ARSLIST.ORG Subject: Re: Table Fields ** first refresh the table, and then look to see if $LASTCOUNT$ = 0 -Aaron * Email: [EMAIL PROTECTED] From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kemes, Lisa Sent: Tuesday, December 19, 2006 2:59 PM To: arslist@ARSLIST.ORG Subject: Table Fields Hello Listers! How can you test to see if there is nothing in a Table Field? I tried 'Table Field' = $NULL$, but nothing happens. I want to create workflow if a Table Field is NULL (no rows) Let me know if anyone has the answer! Thanks! Lisa SunCom is the wireless company that's committed to doing things differently. Things we want you to know. This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication may contain material protected by the attorney-client privilege. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. __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 http://www.arslist.org/ ARSlist:Where the Answers Are __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __20060125___This posting was submitted with HTML in it___
