Table Fields in Smart IT
Hi All I am sure everyone on the list has at some point added a table field either to an OTB or custom form and know the power of being able to collect and provide access to the information our end users need. One of the current shortcomings in Smart IT is the inability to create add table fields. This makes for a huge challenge for me and if it does for you too, I ask that you vote up the idea listed below. https://communities.bmc.com/ideas/19715 Mark Mark Brittain | Senior System Engineer | O 315-634-9337 125 Elwood Davis Road | Syracuse 13212 [NavisiteSm_Logo] -- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
Re: Unable to select rows in table fields from mobile devices 8.1
Thanks all. We did look at SmartIT, however we had to scrap that idea because it does not allow the removal of fields that we aren't using (the one we have built is VERY minimal by request). Has anyone solved the issue of row selection from a mobile device? On Tue, May 12, 2015 at 5:01 PM, Adams, Peter peter_ad...@bmc.com wrote: ** Lyndsay, have you looked at the Smart IT native mobile apps for iOS and Android? These give you a very flexible, easy to use Ticket Console showing incident data from your Remedy ITSM 8.1 system, and it does support certain bulk actions. Users can also actively view and updates incidents from those mobile apps. Smart IT is covered by your standard Remedy Service Desk / Suite user licenses, so no extra purchase needed. You can download a sample version from app stores, if you want to try it out. Peter Adams *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Lyndsay Reese *Sent:* Tuesday, May 12, 2015 9:22 AM *To:* arslist@ARSLIST.ORG *Subject:* Unable to select rows in table fields from mobile devices 8.1 ** Hello ARSListers, We have been asked to create a simple view of the Incident Management Console that our users can access from their mobile devices and perform a limited number of functions. I've created the view and it displays correctly, however, we are unable to select any rows in the table fields from touch screen devices. I opened a ticket with BMC and they advised that this would require customization, but were unable to explain what would be needed (other than to recommend BMC Professional Services). We cannot buy any additional products or services to accomplish this task and I am happy to do the work myself, if I know what needs to be done. Has anyone else tackled such a request without the help of 3rd party applications? If so, what is the best way to go about this? Thank you in advance. ARS 8.1 ITSM 8.1 Midtier 8.1.SP02 Patch 001 201503051028 Hotfix Windows Server 2008 r2 Standard 64-bit Tomcat 6.0 SQL _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Unable to select rows in table fields from mobile devices 8.1
Have your considered using SMART IT, it is free for all Remedy customers on 7.6.04 and higher version. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Lyndsay Reese Sent: Tuesday, May 12, 2015 9:22 AM To: arslist@ARSLIST.ORG Subject: Unable to select rows in table fields from mobile devices 8.1 ** Hello ARSListers, We have been asked to create a simple view of the Incident Management Console that our users can access from their mobile devices and perform a limited number of functions. I've created the view and it displays correctly, however, we are unable to select any rows in the table fields from touch screen devices. I opened a ticket with BMC and they advised that this would require customization, but were unable to explain what would be needed (other than to recommend BMC Professional Services). We cannot buy any additional products or services to accomplish this task and I am happy to do the work myself, if I know what needs to be done. Has anyone else tackled such a request without the help of 3rd party applications? If so, what is the best way to go about this? Thank you in advance. ARS 8.1 ITSM 8.1 Midtier 8.1.SP02 Patch 001 201503051028 Hotfix Windows Server 2008 r2 Standard 64-bit Tomcat 6.0 SQL _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Unable to select rows in table fields from mobile devices 8.1
Hello ARSListers, We have been asked to create a simple view of the Incident Management Console that our users can access from their mobile devices and perform a limited number of functions. I've created the view and it displays correctly, however, we are unable to select any rows in the table fields from touch screen devices. I opened a ticket with BMC and they advised that this would require customization, but were unable to explain what would be needed (other than to recommend BMC Professional Services). We cannot buy any additional products or services to accomplish this task and I am happy to do the work myself, if I know what needs to be done. Has anyone else tackled such a request without the help of 3rd party applications? If so, what is the best way to go about this? Thank you in advance. ARS 8.1 ITSM 8.1 Midtier 8.1.SP02 Patch 001 201503051028 Hotfix Windows Server 2008 r2 Standard 64-bit Tomcat 6.0 SQL ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Unable to select rows in table fields from mobile devices 8.1
Lyndsay, have you looked at the Smart IT native mobile apps for iOS and Android? These give you a very flexible, easy to use Ticket Console showing incident data from your Remedy ITSM 8.1 system, and it does support certain bulk actions. Users can also actively view and updates incidents from those mobile apps. Smart IT is covered by your standard Remedy Service Desk / Suite user licenses, so no extra purchase needed. You can download a sample version from app stores, if you want to try it out. Peter Adams From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Lyndsay Reese Sent: Tuesday, May 12, 2015 9:22 AM To: arslist@ARSLIST.ORG Subject: Unable to select rows in table fields from mobile devices 8.1 ** Hello ARSListers, We have been asked to create a simple view of the Incident Management Console that our users can access from their mobile devices and perform a limited number of functions. I've created the view and it displays correctly, however, we are unable to select any rows in the table fields from touch screen devices. I opened a ticket with BMC and they advised that this would require customization, but were unable to explain what would be needed (other than to recommend BMC Professional Services). We cannot buy any additional products or services to accomplish this task and I am happy to do the work myself, if I know what needs to be done. Has anyone else tackled such a request without the help of 3rd party applications? If so, what is the best way to go about this? Thank you in advance. ARS 8.1 ITSM 8.1 Midtier 8.1.SP02 Patch 001 201503051028 Hotfix Windows Server 2008 r2 Standard 64-bit Tomcat 6.0 SQL _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Data in server-side table fields is read-only.
Understood. Thanks Misi for explaining as always. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Data in server-side table fields is read-only.
Hi, You can not just save data from any table to the database, either server or client side. The only way to update data in the database is by doing a Push-Fields action. This must be done with a table-walk (call-guide triggering a bunch of push-fields). On the client side the user can edit data in some table-columns, or you can use Set-Fields to change it, but this has nothing to do with the database. To push this changed data to the database, you still have to do the table-walk. On the server side the data in the table always reflects what is in the database, so there is never any changes to save. You might want to change the data to something else though, for example setting 'Priority' = High on all the rows. If that is what you want to do you can skip the table completely and just do a single push-fields and update all-matching-entries. I have not read the entire thread, but it seems like we do not know what you want to accomplish. Can you please tell us what you want to do? Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. Hey Misi, thanks for reponding to the post. I was actually waiting for your reply. As you said we can update data in a table from both client side and server side table looping then do you think the statement Data in server-side table fields is read-only is valid? If not what it actually menas? Doug said server said table is readonly and you are saying we can update data in server side table. Really confusing. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Data in server-side table fields is read-only.
Here are some observations on server-side table fields (SSTFs) that may help you understand how to use them. Speaking in general terms, there are comparatively few use cases where developers need to use SSTFs. Many of the use cases that are satisfied by using SSTFs can also be satisfied using other techniques such as Push Fields or Direct SQL. So if you have no immediate plan to use an SSTF, then don't worry about the comment in the documentation. Specifically about the documentation's comment, as I understand it the intent is to state that if an SSTF has a row, and a developer modifies the contents of that row, then the modification is not reflected in the foreign table which is the source of data for the row. If a developer's intent is to update the data in the foreign table, then it will be necessary to use workflow to update the data and then optionally refresh the table field to reflect the update. Many of the experienced developers here on ARSList have built solutions using SSTFs, so my advice would be to wait until you have a requirement that may be satisfied by using an SSTF and then ask your questions. HTH, --Phil From: Action Request System discussion list(ARSList) [arslist@ARSLIST.ORG] On Behalf Of Sweety [sweetykhann...@gmail.com] Sent: Monday, May 19, 2014 18:04 To: arslist@ARSLIST.ORG Subject: Re: Data in server-side table fields is read-only. I have not said that I want to create a table field at all. It says data is read only. Why I cannot update the data in server side table? I do not understant the statement Data in server-side table fields is read-only. Make me understand it please. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Data in server-side table fields is read-only.
Table fields are a construct to show data from another form. Table fields include column fields which map to fields on the other form. When defining a table, you can specify that columns are editable. Yes, this means you can type data into the column in a table. You can also add and delete rows from a table. Now, you have to have workflow to take the changes and make it happen on the other form (it is not automatic), but you can edit the columns. Now, all this works ON THE CLIENT. On the server, there is no concept of editing a column value. This is what the comment in the documentation is about. On the client in an active link, you can perform a Set Fields operation to a column and if it is an editable column, the actual value in the column on the screen will change. If you read that row of the table in other workflow, you will get the changed value. However, on the server, if you try that same write to a column, the value WILL NOT be changed. The data is read only on the server regardless of whether the column says it is editable. Now, remember, the system doesn't automatically make changes to original data, you have to use workflow for that. You can use workflow to do that on either clients or servers. BUT, you can have editable columns where you change the value in columns on the client. You cannot do that on the server. The doc note is trying to call that out. I hope this explains what you are asking about. Doug Mueller -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Sweety Sent: Monday, May 19, 2014 3:05 PM To: arslist@ARSLIST.ORG Subject: Re: Data in server-side table fields is read-only. I have not said that I want to create a table field at all. It says data is read only. Why I cannot update the data in server side table? I do not understant the statement Data in server-side table fields is read-only. Make me understand it please. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Data in server-side table fields is read-only.
Ok, if I perform server side table looking to update data in table it will not get updated. I should use client side table looping to perform any data manipulation. Am I right on this? Server side table looping can be used for only performing read only operations Client side table looping can be used for performing read and write opertaions Feel free to correct me. If I am wrong then give me an example of both the loopings where it says server side looping is read only and client side is readable/writable. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Data in server-side table fields is read-only.
Hi, You can use both server and client side table looping to update data. The update is taking place only when you do the Push-Fields action. If you want to update multiple records with the same value. For example setting Priority=High on all child records, you do not need to use table looping. Just do a single Push-Fields and update all matching records. The search criteria should be similar to that of the table-field you are envisioning. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. Ok, if I perform server side table looking to update data in table it will not get updated. I should use client side table looping to perform any data manipulation. Am I right on this? Server side table looping can be used for only performing read only operations Client side table looping can be used for performing read and write opertaions Feel free to correct me. If I am wrong then give me an example of both the loopings where it says server side looping is read only and client side is readable/writable. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Data in server-side table fields is read-only.
Hey Misi, thanks for reponding to the post. I was actually waiting for your reply. As you said we can update data in a table from both client side and server side table looping then do you think the statement Data in server-side table fields is read-only is valid? If not what it actually menas? Doug said server said table is readonly and you are saying we can update data in server side table. Really confusing. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Data in server-side table fields is read-only.
Maybe I can make it a bit less confusing. I believe the statement Data in server-side table fields is read-only was put in because you can set the Display Type property of a column in a table field to Editable. When using a client a user can interact with and change the data in the table field's column when the property is set Editable. When working with a table field using Filters (Server Side) this property is ignored and all columns in the table field are Read Only. By Update Misi is talking about the fact you can walk a table on the server using filters and based on data in the table do Push fields to update the data in the Form the table field is displaying. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Sweety Sent: Tuesday, May 20, 2014 3:51 PM To: arslist@ARSLIST.ORG Subject: Re: Data in server-side table fields is read-only. Hey Misi, thanks for reponding to the post. I was actually waiting for your reply. As you said we can update data in a table from both client side and server side table looping then do you think the statement Data in server-side table fields is read-only is valid? If not what it actually menas? Doug said server said table is readonly and you are saying we can update data in server side table. Really confusing. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Data in server-side table fields is read-only.
Anybody help me in understanding this statement? Why is it read-only? //docs.bmc(dot)com/docs/display/public/ars81/Table+fields ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Data in server-side table fields is read-only.
Sweety, I'm unsure why that statement is even in therebut data in ALL table fields is read onlythe fact that some fields can be set as 'editable' doesn't make it actually editable, you still need to loop through the table and push values to the DB What is your concern about that statement specifically? On Mon, May 19, 2014 at 2:43 PM, Sweety sweetykhann...@gmail.com wrote: Anybody help me in understanding this statement? Why is it read-only? //docs.bmc(dot)com/docs/display/public/ars81/Table+fields ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Data in server-side table fields is read-only.
Statement says, Data in server-side table fields is read-only? What does it means? I can edit the record in a table by editing a record existing in a form which is refering to the table. It just says server side table field is ready-only, does it mean client side table field is writable? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Data in server-side table fields is read-only.
The statement is to allow a developer to create filter workflow that would allow for the concept of walking a table field without having to create the table field on the form and using Active Links to walk it. -Original Message- From: LJ LongWing lj.longw...@gmail.com To: arslist arslist@ARSLIST.ORG Sent: Mon, May 19, 2014 4:49 pm Subject: Re: Data in server-side table fields is read-only. ** Sweety, I'm unsure why that statement is even in therebut data in ALL table fields is read onlythe fact that some fields can be set as 'editable' doesn't make it actually editable, you still need to loop through the table and push values to the DB What is your concern about that statement specifically? On Mon, May 19, 2014 at 2:43 PM, Sweety sweetykhann...@gmail.com wrote: Anybody help me in understanding this statement? Why is it read-only? //docs.bmc(dot)com/docs/display/public/ars81/Table+fields ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Data in server-side table fields is read-only.
I have not said that I want to create a table field at all. It says data is read only. Why I cannot update the data in server side table? I do not understant the statement Data in server-side table fields is read-only. Make me understand it please. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Data in server-side table fields is read-only.
Sweety Are you using Chrome or IE as your browser? I find the site to only support Chrome. Phil -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Sweety Sent: Monday, May 19, 2014 3:05 PM To: arslist@ARSLIST.ORG Subject: Re: Data in server-side table fields is read-only. I have not said that I want to create a table field at all. It says data is read only. Why I cannot update the data in server side table? I do not understant the statement Data in server-side table fields is read-only. Make me understand it please. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
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
Table fields displaying 1 hour difference from searched date.
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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
why is it so complicate to read from table fields ???
listers, in my form A I have a table field with 2 columns lists and logins. And a qualification which is $Assignee$ = 'Lists'. I have so the Assignee field which gets updated from the web via filters. Basically on the web I fill in a form and I click on submit. This sends one of the web form fields to the Remedy form A. Basically the field Assignee gets the value from the web. At this stage on that form I have a Filter guide which gets triggered. This FG has 2 filters in it. First one checks whether the infos received could meet the qualification of the table field. If no it Exit guide. If yes, it reads the infos found in column logins. So far so good. But if I send a second time a new value, the form takes again the previous values from the column logins. Why ? How come ? Any help ? Thanks Serouche ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification???
Joe, try the following:
Change the table qualification to (EXTERNAL($ztmpQualification$)) AND
('Start Date' = $DATE$)
Create display only field ztmpQualification.
Create active link that sets ztmpQualification = ('Queue' = $Queue$)
Create active link that does a table refresh
You might have to end up setting ztmpQualification = ('Queue' =
$Queue$) AND ('Start Date' = $\DATE$) and your table field
qualification just to EXTERNAL($ztmpQualification$)
For some reason, a table field on a display-only form doesn't seem to
parse correctly $Field$ although the EXTERNAL() function does.
It is also worth noting that if you are pulling in data from 'Queue' and
there is the event that the value could be $NULL$, you need to check for
$NULL$ and for . I know you aren't doing that here, but for instance
if you had 'Queue' != $NULL$ on there, you need to change this to
('Queue' != $NULL$) AND ('Queue' != ). If the user puts value in the
'Queue' field and then backspaces over it, on a display only form, I've
noticed that the value is no longer $NULL$, but the empty set, .
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Monday, August 20, 2007 11:30 PM
To: arslist@ARSLIST.ORG
Subject: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
**
Listers,
I am literally pulling my hair over this.. I am on ARS 7.0.1 Patch 003
on Windows 2K3SP2 and MS-SQL 2K5SP2..
I have one data form and another display only form. In the data form
among other fields I have a character field called Queue and another
Date field (not Date/Time).
I have a simple qualification using a Date field in the qualification on
a Table field. I copied the qualification below.
('Queue' = $Queue$) AND ('Start Date' = $DATE$)
This returns all the records when the table field is refreshed after
having a value of Test Queue in the Queue field irrespective of the
value of the Start Date in the underlying data form when it should have
been returning only 1 record on the table field.
On the User Tool however if I search the form using advanced search
('Queue' = Test Queue) AND ('Start Date' = 8/20/2007)
I get just one record as I should given my data.
Is this a known bug with using a Date field on a table fields
qualification??
Joe
__20060125___This posting was submitted with HTML in
it___
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification???
Gary, (and maybe Joe too)
I actually think the date stuff your seeing is actually related to
these details...
Ref: Workflow-Objects-700.pdf Pg 199
For example, if you have a table field with a qualification of
EXTERNAL($Qualify Field$)
and Qualify Field is a character field with a value of
('Create Date' $TIMESTAMP$) AND ('Login Name' = $USER$)
the table field will not produce expected results when refreshed. The
keywords will expand, producing a qualification such as
('Create Date' 05/22/02 11:00:34 AM) AND ('Login Name' = Demo)
This is not a valid query, since the date/time and character values
are not enclosed in quotation marks. To prevent the keywords from
expanding, write the qualification like this:
('Create Date' $\TIMESTAMP$) AND ('Login Name' = $\USER$)
In forms viewed on the Web, if EXTERNAL() references a field that
contains a qualification such as $Date 1$ = 'Date 2', you must add
double quotation marks around $Date 1$, like this:
$Date 1$ = 'Date 2'.
Note: In BMC Remedy User, the EXTERNAL operator reads date and time
string from the server's time. On the web, the EXTERNAL operator reads
the date and time string from client's time zone.
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 8/21/07, Opela, Gary L Contr OC-ALC/ITMA
[EMAIL PROTECTED] wrote:
Joe, try the following:
Change the table qualification to (EXTERNAL($ztmpQualification$)) AND
('Start Date' = $DATE$)
Create display only field ztmpQualification.
Create active link that sets ztmpQualification = ('Queue' = $Queue$)
Create active link that does a table refresh
You might have to end up setting ztmpQualification = ('Queue' =
$Queue$) AND ('Start Date' = $\DATE$) and your table field
qualification just to EXTERNAL($ztmpQualification$)
For some reason, a table field on a display-only form doesn't seem to
parse correctly $Field$ although the EXTERNAL() function does.
It is also worth noting that if you are pulling in data from 'Queue' and
there is the event that the value could be $NULL$, you need to check for
$NULL$ and for . I know you aren't doing that here, but for instance
if you had 'Queue' != $NULL$ on there, you need to change this to
('Queue' != $NULL$) AND ('Queue' != ). If the user puts value in the
'Queue' field and then backspaces over it, on a display only form, I've
noticed that the value is no longer $NULL$, but the empty set, .
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Monday, August 20, 2007 11:30 PM
To: arslist@ARSLIST.ORG
Subject: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
**
Listers,
I am literally pulling my hair over this.. I am on ARS 7.0.1 Patch 003
on Windows 2K3SP2 and MS-SQL 2K5SP2..
I have one data form and another display only form. In the data form
among other fields I have a character field called Queue and another
Date field (not Date/Time).
I have a simple qualification using a Date field in the qualification on
a Table field. I copied the qualification below.
('Queue' = $Queue$) AND ('Start Date' = $DATE$)
This returns all the records when the table field is refreshed after
having a value of Test Queue in the Queue field irrespective of the
value of the Start Date in the underlying data form when it should have
been returning only 1 record on the table field.
On the User Tool however if I search the form using advanced search
('Queue' = Test Queue) AND ('Start Date' = 8/20/2007)
I get just one record as I should given my data.
Is this a known bug with using a Date field on a table fields
qualification??
Joe
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification???
Carey, thanks for expanding upon this, but I'm not using any keywords
such as $DATE$ or $TIMESTAMP$ in my external field's value. My situation
only worked whenever I used EXTERNAL(), and I think that Joe is probably
having the same thing.
I was suggesting he try using the EXTERNAL, and if he referenced $DATE$,
then it would have to be escaped as $\DATE$.
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
Sent: Tuesday, August 21, 2007 7:38 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Gary, (and maybe Joe too)
I actually think the date stuff your seeing is actually related to
these details...
Ref: Workflow-Objects-700.pdf Pg 199
For example, if you have a table field with a qualification of
EXTERNAL($Qualify Field$)
and Qualify Field is a character field with a value of
('Create Date' $TIMESTAMP$) AND ('Login Name' = $USER$)
the table field will not produce expected results when refreshed. The
keywords will expand, producing a qualification such as
('Create Date' 05/22/02 11:00:34 AM) AND ('Login Name' = Demo)
This is not a valid query, since the date/time and character values
are not enclosed in quotation marks. To prevent the keywords from
expanding, write the qualification like this:
('Create Date' $\TIMESTAMP$) AND ('Login Name' = $\USER$)
In forms viewed on the Web, if EXTERNAL() references a field that
contains a qualification such as $Date 1$ = 'Date 2', you must add
double quotation marks around $Date 1$, like this:
$Date 1$ = 'Date 2'.
Note: In BMC Remedy User, the EXTERNAL operator reads date and time
string from the server's time. On the web, the EXTERNAL operator reads
the date and time string from client's time zone.
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 8/21/07, Opela, Gary L Contr OC-ALC/ITMA
[EMAIL PROTECTED] wrote:
Joe, try the following:
Change the table qualification to (EXTERNAL($ztmpQualification$)) AND
('Start Date' = $DATE$)
Create display only field ztmpQualification.
Create active link that sets ztmpQualification = ('Queue' = $Queue$)
Create active link that does a table refresh
You might have to end up setting ztmpQualification = ('Queue' =
$Queue$) AND ('Start Date' = $\DATE$) and your table field
qualification just to EXTERNAL($ztmpQualification$)
For some reason, a table field on a display-only form doesn't seem to
parse correctly $Field$ although the EXTERNAL() function does.
It is also worth noting that if you are pulling in data from 'Queue'
and
there is the event that the value could be $NULL$, you need to check
for
$NULL$ and for . I know you aren't doing that here, but for instance
if you had 'Queue' != $NULL$ on there, you need to change this to
('Queue' != $NULL$) AND ('Queue' != ). If the user puts value in the
'Queue' field and then backspaces over it, on a display only form,
I've
noticed that the value is no longer $NULL$, but the empty set, .
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Monday, August 20, 2007 11:30 PM
To: arslist@ARSLIST.ORG
Subject: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
**
Listers,
I am literally pulling my hair over this.. I am on ARS 7.0.1 Patch 003
on Windows 2K3SP2 and MS-SQL 2K5SP2..
I have one data form and another display only form. In the data form
among other fields I have a character field called Queue and another
Date field (not Date/Time).
I have a simple qualification using a Date field in the qualification
on
a Table field. I copied the qualification below.
('Queue' = $Queue$) AND ('Start Date' = $DATE$)
This returns all the records when the table field is refreshed after
having a value of Test Queue in the Queue field irrespective of the
value of the Start Date in the underlying data form when it should
have
been returning only 1 record on the table field.
On the User Tool however if I search the form using advanced search
('Queue' = Test Queue) AND ('Start Date' = 8/20/2007)
I get just one record as I should given my data.
Is this a known bug with using a Date field on a table fields
qualification??
Joe
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where
the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification???
Carey, Gary,
Thanks for your notes.
Carey, mine isn't the Date/time field but the Date field so $TIMESTAMP$
cannot be used to compare it but the $DATE$ keyword would have to be used
instead.
Gary, about using external, sure I can try that and see if it works. I don't
yet see why this qualification shouldn't work directly from a table field..
And yes you do need to escape keywords with a \ when used in External
Qualifications..
Cheers
Joe
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA
Sent: Tuesday, August 21, 2007 8:43 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Carey, thanks for expanding upon this, but I'm not using any keywords
such as $DATE$ or $TIMESTAMP$ in my external field's value. My situation
only worked whenever I used EXTERNAL(), and I think that Joe is probably
having the same thing.
I was suggesting he try using the EXTERNAL, and if he referenced $DATE$,
then it would have to be escaped as $\DATE$.
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
Sent: Tuesday, August 21, 2007 7:38 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Gary, (and maybe Joe too)
I actually think the date stuff your seeing is actually related to
these details...
Ref: Workflow-Objects-700.pdf Pg 199
For example, if you have a table field with a qualification of
EXTERNAL($Qualify Field$)
and Qualify Field is a character field with a value of
('Create Date' $TIMESTAMP$) AND ('Login Name' = $USER$)
the table field will not produce expected results when refreshed. The
keywords will expand, producing a qualification such as
('Create Date' 05/22/02 11:00:34 AM) AND ('Login Name' = Demo)
This is not a valid query, since the date/time and character values
are not enclosed in quotation marks. To prevent the keywords from
expanding, write the qualification like this:
('Create Date' $\TIMESTAMP$) AND ('Login Name' = $\USER$)
In forms viewed on the Web, if EXTERNAL() references a field that
contains a qualification such as $Date 1$ = 'Date 2', you must add
double quotation marks around $Date 1$, like this:
$Date 1$ = 'Date 2'.
Note: In BMC Remedy User, the EXTERNAL operator reads date and time
string from the server's time. On the web, the EXTERNAL operator reads
the date and time string from client's time zone.
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 8/21/07, Opela, Gary L Contr OC-ALC/ITMA
[EMAIL PROTECTED] wrote:
Joe, try the following:
Change the table qualification to (EXTERNAL($ztmpQualification$)) AND
('Start Date' = $DATE$)
Create display only field ztmpQualification.
Create active link that sets ztmpQualification = ('Queue' = $Queue$)
Create active link that does a table refresh
You might have to end up setting ztmpQualification = ('Queue' =
$Queue$) AND ('Start Date' = $\DATE$) and your table field
qualification just to EXTERNAL($ztmpQualification$)
For some reason, a table field on a display-only form doesn't seem to
parse correctly $Field$ although the EXTERNAL() function does.
It is also worth noting that if you are pulling in data from 'Queue'
and
there is the event that the value could be $NULL$, you need to check
for
$NULL$ and for . I know you aren't doing that here, but for instance
if you had 'Queue' != $NULL$ on there, you need to change this to
('Queue' != $NULL$) AND ('Queue' != ). If the user puts value in the
'Queue' field and then backspaces over it, on a display only form,
I've
noticed that the value is no longer $NULL$, but the empty set, .
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Monday, August 20, 2007 11:30 PM
To: arslist@ARSLIST.ORG
Subject: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
**
Listers,
I am literally pulling my hair over this.. I am on ARS 7.0.1 Patch 003
on Windows 2K3SP2 and MS-SQL 2K5SP2..
I have one data form and another display only form. In the data form
among other fields I have a character field called Queue and another
Date field (not Date/Time).
I have a simple qualification using a Date field in the qualification
on
a Table field. I copied the qualification below.
('Queue' = $Queue$) AND ('Start Date' = $DATE$)
This returns all the records when the table field is refreshed after
Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification???
Joe, I agree that the qualification SHOULD work directly in the table
field, but in my experiences, for some reason it does not.
Give out the External a try, I'll bet you a Mt. Dew (if I ever meet you)
that it will :)
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Tuesday, August 21, 2007 9:36 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Carey, Gary,
Thanks for your notes.
Carey, mine isn't the Date/time field but the Date field so $TIMESTAMP$
cannot be used to compare it but the $DATE$ keyword would have to be
used
instead.
Gary, about using external, sure I can try that and see if it works. I
don't
yet see why this qualification shouldn't work directly from a table
field..
And yes you do need to escape keywords with a \ when used in External
Qualifications..
Cheers
Joe
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA
Sent: Tuesday, August 21, 2007 8:43 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Carey, thanks for expanding upon this, but I'm not using any keywords
such as $DATE$ or $TIMESTAMP$ in my external field's value. My situation
only worked whenever I used EXTERNAL(), and I think that Joe is probably
having the same thing.
I was suggesting he try using the EXTERNAL, and if he referenced $DATE$,
then it would have to be escaped as $\DATE$.
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
Sent: Tuesday, August 21, 2007 7:38 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Gary, (and maybe Joe too)
I actually think the date stuff your seeing is actually related to
these details...
Ref: Workflow-Objects-700.pdf Pg 199
For example, if you have a table field with a qualification of
EXTERNAL($Qualify Field$)
and Qualify Field is a character field with a value of
('Create Date' $TIMESTAMP$) AND ('Login Name' = $USER$)
the table field will not produce expected results when refreshed. The
keywords will expand, producing a qualification such as
('Create Date' 05/22/02 11:00:34 AM) AND ('Login Name' = Demo)
This is not a valid query, since the date/time and character values
are not enclosed in quotation marks. To prevent the keywords from
expanding, write the qualification like this:
('Create Date' $\TIMESTAMP$) AND ('Login Name' = $\USER$)
In forms viewed on the Web, if EXTERNAL() references a field that
contains a qualification such as $Date 1$ = 'Date 2', you must add
double quotation marks around $Date 1$, like this:
$Date 1$ = 'Date 2'.
Note: In BMC Remedy User, the EXTERNAL operator reads date and time
string from the server's time. On the web, the EXTERNAL operator reads
the date and time string from client's time zone.
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 8/21/07, Opela, Gary L Contr OC-ALC/ITMA
[EMAIL PROTECTED] wrote:
Joe, try the following:
Change the table qualification to (EXTERNAL($ztmpQualification$)) AND
('Start Date' = $DATE$)
Create display only field ztmpQualification.
Create active link that sets ztmpQualification = ('Queue' = $Queue$)
Create active link that does a table refresh
You might have to end up setting ztmpQualification = ('Queue' =
$Queue$) AND ('Start Date' = $\DATE$) and your table field
qualification just to EXTERNAL($ztmpQualification$)
For some reason, a table field on a display-only form doesn't seem to
parse correctly $Field$ although the EXTERNAL() function does.
It is also worth noting that if you are pulling in data from 'Queue'
and
there is the event that the value could be $NULL$, you need to check
for
$NULL$ and for . I know you aren't doing that here, but for instance
if you had 'Queue' != $NULL$ on there, you need to change this to
('Queue' != $NULL$) AND ('Queue' != ). If the user puts value in the
'Queue' field and then backspaces over it, on a display only form,
I've
noticed that the value is no longer $NULL$, but the empty set, .
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Monday, August 20, 2007 11:30 PM
To: arslist@ARSLIST.ORG
Subject: Bug with comparing
Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification???
How did you know that's my favorite soda after coke :-)
Joe
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA
Sent: Tuesday, August 21, 2007 10:38 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Joe, I agree that the qualification SHOULD work directly in the table
field, but in my experiences, for some reason it does not.
Give out the External a try, I'll bet you a Mt. Dew (if I ever meet you)
that it will :)
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Tuesday, August 21, 2007 9:36 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Carey, Gary,
Thanks for your notes.
Carey, mine isn't the Date/time field but the Date field so $TIMESTAMP$
cannot be used to compare it but the $DATE$ keyword would have to be
used
instead.
Gary, about using external, sure I can try that and see if it works. I
don't
yet see why this qualification shouldn't work directly from a table
field..
And yes you do need to escape keywords with a \ when used in External
Qualifications..
Cheers
Joe
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA
Sent: Tuesday, August 21, 2007 8:43 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Carey, thanks for expanding upon this, but I'm not using any keywords
such as $DATE$ or $TIMESTAMP$ in my external field's value. My situation
only worked whenever I used EXTERNAL(), and I think that Joe is probably
having the same thing.
I was suggesting he try using the EXTERNAL, and if he referenced $DATE$,
then it would have to be escaped as $\DATE$.
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
Sent: Tuesday, August 21, 2007 7:38 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Gary, (and maybe Joe too)
I actually think the date stuff your seeing is actually related to
these details...
Ref: Workflow-Objects-700.pdf Pg 199
For example, if you have a table field with a qualification of
EXTERNAL($Qualify Field$)
and Qualify Field is a character field with a value of
('Create Date' $TIMESTAMP$) AND ('Login Name' = $USER$)
the table field will not produce expected results when refreshed. The
keywords will expand, producing a qualification such as
('Create Date' 05/22/02 11:00:34 AM) AND ('Login Name' = Demo)
This is not a valid query, since the date/time and character values
are not enclosed in quotation marks. To prevent the keywords from
expanding, write the qualification like this:
('Create Date' $\TIMESTAMP$) AND ('Login Name' = $\USER$)
In forms viewed on the Web, if EXTERNAL() references a field that
contains a qualification such as $Date 1$ = 'Date 2', you must add
double quotation marks around $Date 1$, like this:
$Date 1$ = 'Date 2'.
Note: In BMC Remedy User, the EXTERNAL operator reads date and time
string from the server's time. On the web, the EXTERNAL operator reads
the date and time string from client's time zone.
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 8/21/07, Opela, Gary L Contr OC-ALC/ITMA
[EMAIL PROTECTED] wrote:
Joe, try the following:
Change the table qualification to (EXTERNAL($ztmpQualification$)) AND
('Start Date' = $DATE$)
Create display only field ztmpQualification.
Create active link that sets ztmpQualification = ('Queue' = $Queue$)
Create active link that does a table refresh
You might have to end up setting ztmpQualification = ('Queue' =
$Queue$) AND ('Start Date' = $\DATE$) and your table field
qualification just to EXTERNAL($ztmpQualification$)
For some reason, a table field on a display-only form doesn't seem to
parse correctly $Field$ although the EXTERNAL() function does.
It is also worth noting that if you are pulling in data from 'Queue'
and
there is the event that the value could be $NULL$, you need to check
for
$NULL$ and for . I know you aren't doing that here, but for instance
if you had 'Queue' != $NULL$ on there, you need to change this to
('Queue' != $NULL$) AND ('Queue' != ). If the user puts value in the
'Queue' field and then backspaces over it, on a display only form,
I've
noticed
Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification???
Well, I've grown up on Mt. Dew. Anyone who knows me can attest that I
have probably more Mt. Dew in my veins than blood at any one time!
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Tuesday, August 21, 2007 9:40 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
How did you know that's my favorite soda after coke :-)
Joe
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA
Sent: Tuesday, August 21, 2007 10:38 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Joe, I agree that the qualification SHOULD work directly in the table
field, but in my experiences, for some reason it does not.
Give out the External a try, I'll bet you a Mt. Dew (if I ever meet you)
that it will :)
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Tuesday, August 21, 2007 9:36 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Carey, Gary,
Thanks for your notes.
Carey, mine isn't the Date/time field but the Date field so $TIMESTAMP$
cannot be used to compare it but the $DATE$ keyword would have to be
used
instead.
Gary, about using external, sure I can try that and see if it works. I
don't
yet see why this qualification shouldn't work directly from a table
field..
And yes you do need to escape keywords with a \ when used in External
Qualifications..
Cheers
Joe
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA
Sent: Tuesday, August 21, 2007 8:43 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Carey, thanks for expanding upon this, but I'm not using any keywords
such as $DATE$ or $TIMESTAMP$ in my external field's value. My situation
only worked whenever I used EXTERNAL(), and I think that Joe is probably
having the same thing.
I was suggesting he try using the EXTERNAL, and if he referenced $DATE$,
then it would have to be escaped as $\DATE$.
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
Sent: Tuesday, August 21, 2007 7:38 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Gary, (and maybe Joe too)
I actually think the date stuff your seeing is actually related to
these details...
Ref: Workflow-Objects-700.pdf Pg 199
For example, if you have a table field with a qualification of
EXTERNAL($Qualify Field$)
and Qualify Field is a character field with a value of
('Create Date' $TIMESTAMP$) AND ('Login Name' = $USER$)
the table field will not produce expected results when refreshed. The
keywords will expand, producing a qualification such as
('Create Date' 05/22/02 11:00:34 AM) AND ('Login Name' = Demo)
This is not a valid query, since the date/time and character values
are not enclosed in quotation marks. To prevent the keywords from
expanding, write the qualification like this:
('Create Date' $\TIMESTAMP$) AND ('Login Name' = $\USER$)
In forms viewed on the Web, if EXTERNAL() references a field that
contains a qualification such as $Date 1$ = 'Date 2', you must add
double quotation marks around $Date 1$, like this:
$Date 1$ = 'Date 2'.
Note: In BMC Remedy User, the EXTERNAL operator reads date and time
string from the server's time. On the web, the EXTERNAL operator reads
the date and time string from client's time zone.
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 8/21/07, Opela, Gary L Contr OC-ALC/ITMA
[EMAIL PROTECTED] wrote:
Joe, try the following:
Change the table qualification to (EXTERNAL($ztmpQualification$)) AND
('Start Date' = $DATE$)
Create display only field ztmpQualification.
Create active link that sets ztmpQualification = ('Queue' = $Queue$)
Create active link that does a table refresh
You might have to end up setting ztmpQualification = ('Queue' =
$Queue$) AND ('Start Date' = $\DATE$) and your table field
qualification just to EXTERNAL($ztmpQualification$)
For some reason, a table field on a display-only
Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification???
I've been that way with coke..
Anyway getting back to the thread, did you notice this on just the $DATE$
keyword or the $TIMESTAMP$ keyword as well? I am pretty sure the $TIMESTAMP$
keyword works as expected at least on version 6.3.x. I am not sure if the
$DATE$ works on 6.3 as I don't think I ever had the need to use it on 6.3
table field qualifications..
Joe
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA
Sent: Tuesday, August 21, 2007 10:43 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Well, I've grown up on Mt. Dew. Anyone who knows me can attest that I
have probably more Mt. Dew in my veins than blood at any one time!
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Tuesday, August 21, 2007 9:40 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
How did you know that's my favorite soda after coke :-)
Joe
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA
Sent: Tuesday, August 21, 2007 10:38 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Joe, I agree that the qualification SHOULD work directly in the table
field, but in my experiences, for some reason it does not.
Give out the External a try, I'll bet you a Mt. Dew (if I ever meet you)
that it will :)
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Tuesday, August 21, 2007 9:36 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Carey, Gary,
Thanks for your notes.
Carey, mine isn't the Date/time field but the Date field so $TIMESTAMP$
cannot be used to compare it but the $DATE$ keyword would have to be
used
instead.
Gary, about using external, sure I can try that and see if it works. I
don't
yet see why this qualification shouldn't work directly from a table
field..
And yes you do need to escape keywords with a \ when used in External
Qualifications..
Cheers
Joe
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA
Sent: Tuesday, August 21, 2007 8:43 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Carey, thanks for expanding upon this, but I'm not using any keywords
such as $DATE$ or $TIMESTAMP$ in my external field's value. My situation
only worked whenever I used EXTERNAL(), and I think that Joe is probably
having the same thing.
I was suggesting he try using the EXTERNAL, and if he referenced $DATE$,
then it would have to be escaped as $\DATE$.
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
Sent: Tuesday, August 21, 2007 7:38 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Gary, (and maybe Joe too)
I actually think the date stuff your seeing is actually related to
these details...
Ref: Workflow-Objects-700.pdf Pg 199
For example, if you have a table field with a qualification of
EXTERNAL($Qualify Field$)
and Qualify Field is a character field with a value of
('Create Date' $TIMESTAMP$) AND ('Login Name' = $USER$)
the table field will not produce expected results when refreshed. The
keywords will expand, producing a qualification such as
('Create Date' 05/22/02 11:00:34 AM) AND ('Login Name' = Demo)
This is not a valid query, since the date/time and character values
are not enclosed in quotation marks. To prevent the keywords from
expanding, write the qualification like this:
('Create Date' $\TIMESTAMP$) AND ('Login Name' = $\USER$)
In forms viewed on the Web, if EXTERNAL() references a field that
contains a qualification such as $Date 1$ = 'Date 2', you must add
double quotation marks around $Date 1$, like this:
$Date 1$ = 'Date 2'.
Note: In BMC Remedy User, the EXTERNAL operator reads date and time
string from the server's time. On the web, the EXTERNAL operator reads
the date and time string from client's time zone.
HTH
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy
Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification???
Well, I'm not using either of the keywords, so I didn't have problem
with those. What I had problem was the equivalent of your $Queue$
reference. For some reason, that wasn't expanding properly. It would not
surprise me if the $Queue$ wasn't expanding properly for me, that you
would also experience a problem with $DATE$. I think for some reason
that the Display Only feature of the form must change something, because
of the action I noted below with $NULL$ and the empty set working
differently on Display Only forms vs. normal forms.
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Tuesday, August 21, 2007 9:50 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
I've been that way with coke..
Anyway getting back to the thread, did you notice this on just the
$DATE$
keyword or the $TIMESTAMP$ keyword as well? I am pretty sure the
$TIMESTAMP$
keyword works as expected at least on version 6.3.x. I am not sure if
the
$DATE$ works on 6.3 as I don't think I ever had the need to use it on
6.3
table field qualifications..
Joe
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA
Sent: Tuesday, August 21, 2007 10:43 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Well, I've grown up on Mt. Dew. Anyone who knows me can attest that I
have probably more Mt. Dew in my veins than blood at any one time!
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Tuesday, August 21, 2007 9:40 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
How did you know that's my favorite soda after coke :-)
Joe
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA
Sent: Tuesday, August 21, 2007 10:38 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Joe, I agree that the qualification SHOULD work directly in the table
field, but in my experiences, for some reason it does not.
Give out the External a try, I'll bet you a Mt. Dew (if I ever meet you)
that it will :)
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Tuesday, August 21, 2007 9:36 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Carey, Gary,
Thanks for your notes.
Carey, mine isn't the Date/time field but the Date field so $TIMESTAMP$
cannot be used to compare it but the $DATE$ keyword would have to be
used
instead.
Gary, about using external, sure I can try that and see if it works. I
don't
yet see why this qualification shouldn't work directly from a table
field..
And yes you do need to escape keywords with a \ when used in External
Qualifications..
Cheers
Joe
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA
Sent: Tuesday, August 21, 2007 8:43 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Carey, thanks for expanding upon this, but I'm not using any keywords
such as $DATE$ or $TIMESTAMP$ in my external field's value. My situation
only worked whenever I used EXTERNAL(), and I think that Joe is probably
having the same thing.
I was suggesting he try using the EXTERNAL, and if he referenced $DATE$,
then it would have to be escaped as $\DATE$.
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
Sent: Tuesday, August 21, 2007 7:38 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Gary, (and maybe Joe too)
I actually think the date stuff your seeing is actually related to
these details...
Ref: Workflow-Objects-700.pdf Pg 199
For example, if you have a table field with a qualification of
EXTERNAL($Qualify Field$)
and Qualify Field is a character field with a value of
('Create Date' $TIMESTAMP$) AND ('Login Name' = $USER
Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification???
I thought the NULL thingy was strange too. I didn't notice these qualifications behave differently on display only forms from regular forms though.. that's a new one to me. Did you ever raise a support call regarding that and if so what was the response you got? Not working as designed I hope.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA Sent: Tuesday, August 21, 2007 10:59 AM To: arslist@ARSLIST.ORG Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification??? Well, I'm not using either of the keywords, so I didn't have problem with those. What I had problem was the equivalent of your $Queue$ reference. For some reason, that wasn't expanding properly. It would not surprise me if the $Queue$ wasn't expanding properly for me, that you would also experience a problem with $DATE$. I think for some reason that the Display Only feature of the form must change something, because of the action I noted below with $NULL$ and the empty set working differently on Display Only forms vs. normal forms. Thanks, Gary Opela, Jr Sr. Remedy Developer Leader Communications, Inc. 405 736 3211 -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza Sent: Tuesday, August 21, 2007 9:50 AM To: arslist@ARSLIST.ORG Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification??? I've been that way with coke.. Anyway getting back to the thread, did you notice this on just the $DATE$ keyword or the $TIMESTAMP$ keyword as well? I am pretty sure the $TIMESTAMP$ keyword works as expected at least on version 6.3.x. I am not sure if the $DATE$ works on 6.3 as I don't think I ever had the need to use it on 6.3 table field qualifications.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA Sent: Tuesday, August 21, 2007 10:43 AM To: arslist@ARSLIST.ORG Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification??? Well, I've grown up on Mt. Dew. Anyone who knows me can attest that I have probably more Mt. Dew in my veins than blood at any one time! Thanks, Gary Opela, Jr Sr. Remedy Developer Leader Communications, Inc. 405 736 3211 -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza Sent: Tuesday, August 21, 2007 9:40 AM To: arslist@ARSLIST.ORG Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification??? How did you know that's my favorite soda after coke :-) Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA Sent: Tuesday, August 21, 2007 10:38 AM To: arslist@ARSLIST.ORG Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification??? Joe, I agree that the qualification SHOULD work directly in the table field, but in my experiences, for some reason it does not. Give out the External a try, I'll bet you a Mt. Dew (if I ever meet you) that it will :) Thanks, Gary Opela, Jr Sr. Remedy Developer Leader Communications, Inc. 405 736 3211 -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza Sent: Tuesday, August 21, 2007 9:36 AM To: arslist@ARSLIST.ORG Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification??? Carey, Gary, Thanks for your notes. Carey, mine isn't the Date/time field but the Date field so $TIMESTAMP$ cannot be used to compare it but the $DATE$ keyword would have to be used instead. Gary, about using external, sure I can try that and see if it works. I don't yet see why this qualification shouldn't work directly from a table field.. And yes you do need to escape keywords with a \ when used in External Qualifications.. Cheers Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA Sent: Tuesday, August 21, 2007 8:43 AM To: arslist@ARSLIST.ORG Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification??? Carey, thanks for expanding upon this, but I'm not using any keywords such as $DATE$ or $TIMESTAMP$ in my external field's value. My situation only worked whenever I used EXTERNAL(), and I think that Joe is probably having the same thing. I was suggesting he try using the EXTERNAL, and if he referenced $DATE$, then it would have to be escaped as $\DATE$. Thanks, Gary Opela, Jr Sr. Remedy Developer Leader Communications, Inc. 405 736 3211 -Original Message- From: Action
Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification???
What do your SQL logs say is being used for the qualification?
Thad Esser
Remedy Developer
Argue for your limitations, and sure enough, they're yours.-- Richard
Bach
Joe D'Souza [EMAIL PROTECTED]
Sent by: Action Request System discussion list(ARSList)
arslist@ARSLIST.ORG
08/21/2007 07:36 AM
Please respond to
arslist@ARSLIST.ORG
To
arslist@ARSLIST.ORG
cc
Subject
Re: Bug with comparing a Date field to the $DATE$ keyword in a table
fields qualification???
Carey, Gary,
Thanks for your notes.
Carey, mine isn't the Date/time field but the Date field so $TIMESTAMP$
cannot be used to compare it but the $DATE$ keyword would have to be used
instead.
Gary, about using external, sure I can try that and see if it works. I
don't
yet see why this qualification shouldn't work directly from a table
field..
And yes you do need to escape keywords with a \ when used in External
Qualifications..
Cheers
Joe
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Opela, Gary L Contr OC-ALC/ITMA
Sent: Tuesday, August 21, 2007 8:43 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Carey, thanks for expanding upon this, but I'm not using any keywords
such as $DATE$ or $TIMESTAMP$ in my external field's value. My situation
only worked whenever I used EXTERNAL(), and I think that Joe is probably
having the same thing.
I was suggesting he try using the EXTERNAL, and if he referenced $DATE$,
then it would have to be escaped as $\DATE$.
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
Sent: Tuesday, August 21, 2007 7:38 AM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
Gary, (and maybe Joe too)
I actually think the date stuff your seeing is actually related to
these details...
Ref: Workflow-Objects-700.pdf Pg 199
For example, if you have a table field with a qualification of
EXTERNAL($Qualify Field$)
and Qualify Field is a character field with a value of
('Create Date' $TIMESTAMP$) AND ('Login Name' = $USER$)
the table field will not produce expected results when refreshed. The
keywords will expand, producing a qualification such as
('Create Date' 05/22/02 11:00:34 AM) AND ('Login Name' = Demo)
This is not a valid query, since the date/time and character values
are not enclosed in quotation marks. To prevent the keywords from
expanding, write the qualification like this:
('Create Date' $\TIMESTAMP$) AND ('Login Name' = $\USER$)
In forms viewed on the Web, if EXTERNAL() references a field that
contains a qualification such as $Date 1$ = 'Date 2', you must add
double quotation marks around $Date 1$, like this:
$Date 1$ = 'Date 2'.
Note: In BMC Remedy User, the EXTERNAL operator reads date and time
string from the server's time. On the web, the EXTERNAL operator reads
the date and time string from client's time zone.
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 8/21/07, Opela, Gary L Contr OC-ALC/ITMA
[EMAIL PROTECTED] wrote:
Joe, try the following:
Change the table qualification to (EXTERNAL($ztmpQualification$)) AND
('Start Date' = $DATE$)
Create display only field ztmpQualification.
Create active link that sets ztmpQualification = ('Queue' = $Queue$)
Create active link that does a table refresh
You might have to end up setting ztmpQualification = ('Queue' =
$Queue$) AND ('Start Date' = $\DATE$) and your table field
qualification just to EXTERNAL($ztmpQualification$)
For some reason, a table field on a display-only form doesn't seem to
parse correctly $Field$ although the EXTERNAL() function does.
It is also worth noting that if you are pulling in data from 'Queue'
and
there is the event that the value could be $NULL$, you need to check
for
$NULL$ and for . I know you aren't doing that here, but for instance
if you had 'Queue' != $NULL$ on there, you need to change this to
('Queue' != $NULL$) AND ('Queue' != ). If the user puts value in the
'Queue' field and then backspaces over it, on a display only form,
I've
noticed that the value is no longer $NULL$, but the empty set, .
Thanks,
Gary Opela, Jr
Sr. Remedy Developer
Leader Communications, Inc.
405 736 3211
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Monday, August 20, 2007 11:30 PM
To: arslist@ARSLIST.ORG
Subject: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
**
Listers,
I am literally pulling my hair over this.. I am
Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification???
Joe,
I can't remember the bug number off the top of my head, but there has been a
longstanding issue with the use of the $DATE$ keyword in workflow
qualifications when used against Date fields. The keyword incorrectly expands
to a Date/Time integer value instead of a Date integer value. It works
correctly when used in a search qualification in the client, however.
The workaround that I would normally recommend is this:
1.. On 'Window Loaded', set a hidden, display-only Date field to the value of
$DATE$ (the bug doesn't affect set fields values).
2.. In your workflow qualification (i.e., 'Run If', 'Set Fields If', 'Push
Fields If', or table field qualification), replace the $DATE$ keyword with the
field reference to the hidden display-only Date field. For example, instead of
'Start Date' = $DATE$, use 'Start Date = $zTmpCurrentDate$.
3.. For table fields, make sure the table field is triggered to refresh AFTER
the hidden display-only Date field value is set to $DATE$ (you may need to
de-select the Refresh on Entry Change property).
Hope this helps,
Thomas
- Original Message -
From: Joe D'Souza
Newsgroups: gmane.comp.crm.arsystem.general
To: arslist@ARSLIST.ORG
Sent: Monday, August 20, 2007 11:29 PM
Subject: Bug with comparing a Date field to the $DATE$ keyword in a table
fields qualification???
**
Listers,
I am literally pulling my hair over this.. I am on ARS 7.0.1 Patch 003 on
Windows 2K3SP2 and MS-SQL 2K5SP2..
I have one data form and another display only form. In the data form among
other fields I have a character field called Queue and another Date field (not
Date/Time).
I have a simple qualification using a Date field in the qualification on a
Table field. I copied the qualification below.
('Queue' = $Queue$) AND ('Start Date' = $DATE$)
This returns all the records when the table field is refreshed after having a
value of Test Queue in the Queue field irrespective of the value of the Start
Date in the underlying data form when it should have been returning only 1
record on the table field.
On the User Tool however if I search the form using advanced search
('Queue' = Test Queue) AND ('Start Date' = 8/20/2007)
I get just one record as I should given my data.
Is this a known bug with using a Date field on a table fields qualification??
Joe
__20060125___This posting was submitted with HTML in it___
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
Re: Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification???
Now that would explain the cause of the error.. The integer converted by the
'Start Date' would then always be less than the integer converted by the
$DATE$ if it expands to the date time integer thus returning all the
records..
Joe
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Thomas Bean
Sent: Tuesday, August 21, 2007 7:17 PM
To: arslist@ARSLIST.ORG
Subject: Re: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
**
Joe,
I can't remember the bug number off the top of my head, but there has been
a longstanding issue with the use of the $DATE$ keyword in workflow
qualifications when used against Date fields. The keyword incorrectly
expands to a Date/Time integer value instead of a Date integer value. It
works correctly when used in a search qualification in the client, however.
The workaround that I would normally recommend is this:
1.. On 'Window Loaded', set a hidden, display-only Date field to the
value of $DATE$ (the bug doesn't affect set fields values).
2.. In your workflow qualification (i.e., 'Run If', 'Set Fields If',
'Push Fields If', or table field qualification), replace the $DATE$ keyword
with the field reference to the hidden display-only Date field. For
example, instead of 'Start Date' = $DATE$, use 'Start Date =
$zTmpCurrentDate$.
3.. For table fields, make sure the table field is triggered to refresh
AFTER the hidden display-only Date field value is set to $DATE$ (you may
need to de-select the Refresh on Entry Change property).
Hope this helps,
Thomas
- Original Message -
From: Joe D'Souza
Newsgroups: gmane.comp.crm.arsystem.general
To: arslist@ARSLIST.ORG
Sent: Monday, August 20, 2007 11:29 PM
Subject: Bug with comparing a Date field to the $DATE$ keyword in a
table fields qualification???
**
Listers,
I am literally pulling my hair over this.. I am on ARS 7.0.1 Patch 003
on Windows 2K3SP2 and MS-SQL 2K5SP2..
I have one data form and another display only form. In the data form
among other fields I have a character field called Queue and another Date
field (not Date/Time).
I have a simple qualification using a Date field in the qualification on
a Table field. I copied the qualification below.
('Queue' = $Queue$) AND ('Start Date' = $DATE$)
This returns all the records when the table field is refreshed after
having a value of Test Queue in the Queue field irrespective of the value
of the Start Date in the underlying data form when it should have been
returning only 1 record on the table field.
On the User Tool however if I search the form using advanced search
('Queue' = Test Queue) AND ('Start Date' = 8/20/2007)
I get just one record as I should given my data.
Is this a known bug with using a Date field on a table fields
qualification??
Joe
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.484 / Virus Database: 269.12.1/965 - Release Date: 8/21/2007
4:02 PM
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
Bug with comparing a Date field to the $DATE$ keyword in a table fields qualification???
Listers,
I am literally pulling my hair over this.. I am on ARS 7.0.1 Patch 003 on
Windows 2K3SP2 and MS-SQL 2K5SP2..
I have one data form and another display only form. In the data form among
other fields I have a character field called Queue and another Date field
(not Date/Time).
I have a simple qualification using a Date field in the qualification on a
Table field. I copied the qualification below.
('Queue' = $Queue$) AND ('Start Date' = $DATE$)
This returns all the records when the table field is refreshed after having
a value of Test Queue in the Queue field irrespective of the value of the
Start Date in the underlying data form when it should have been returning
only 1 record on the table field.
On the User Tool however if I search the form using advanced search
('Queue' = Test Queue) AND ('Start Date' = 8/20/2007)
I get just one record as I should given my data.
Is this a known bug with using a Date field on a table fields
qualification??
Joe
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.484 / Virus Database: 269.12.1/963 - Release Date: 8/20/2007
5:44 PM
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 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: Regarding archiving of table fields...some help!
Hi Nisha, The situation is quiet similar to Out of the box HPD:Helpdesk archiving and its related table field entries for SHR:ConsolidatedLists (Correponds to ur second form). We actually were in a fix as well when we implemented the Archiving in our systems. In our case we chose to archive SHR:ConsolidatedList just for record sake and did not really use it that much. However if you do need these entries to be displayed in table field of archive form i think you should not be archiving your second form at all. -Mudit On 4/1/07, Nisha Ramtri [EMAIL PROTECTED] wrote: ** Hello Listers, Today I tried to enable archiving of one of the forms being used in my organisation. This form has some table fields which have some data coming from some second regular form through some workflow. When I archived only the main form containing the table field and not the second regular form, then in the archived form I could see the data in the table. However, when I archived the second regular form (in addition to the main form), I could not see the data in the table of the archived main form. The data was however available in the second archived form. As per the documentation, the workflow does not get attached to the archived forms. --So instead of actually modifying the workflow and enabling it also for the archived forms, how can I ensure that I can overcome this issue? --Has anyone ever come across this kind of issue? If yes, how has it been overcome? --Have I missed something else which needs to be taken care of so that such table fields are populated with the data when archived? I got some suggestions offline but I would appreciate if there were some more of them. It'll be a great help if you could throw some light and suggest something. Thanks! Rgds, Nisha Ramtri __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Regarding archiving of table fields...some help!
Hello Listers, Today I tried to enable archiving of one of the forms being used in my organisation. This form has some table fields which have some data coming from some second regular form through some workflow. When I archived only the main form containing the table field and not the second regular form, then in the archived form I could see the data in the table. However, when I archived the second regular form (in addition to the main form), I could not see the data in the table of the archived main form. The data was however available in the second archived form. As per the documentation, the workflow does not get attached to the archived forms. --So instead of actually modifying the workflow and enabling it also for the archived forms, how can I ensure that I can overcome this issue? --Has anyone ever come across this kind of issue? If yes, how has it been overcome? --Have I missed something else which needs to be taken care of so that such table fields are populated with the data when archived? I got some suggestions offline but I would appreciate if there were some more of them. It'll be a great help if you could throw some light and suggest something. Thanks! Rgds, Nisha Ramtri ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
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
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___
Master/Detail Table Fields?
I have a HD Ticket form that has various info, including (of course) a Ticket #. I also have a 'related to ticket #' field where a user could put in a 'master' ticket number and create a partent/child relationship, of sorts. Now, I have a display form that has a table field at the top that shows all of the 'master' tickets in the system. I then have a table field at the bottom that I would like to show all of the 'detail' tickets that tie to the master ticket which is selected in the top field. When the top 'master' ticket changes, I want to refresh the bottom field to represent the new result list. My biggest problem is how do I configure the Qualification in the Table/Tree Property tab to be able to reference the record selected in the above table field? Thanks, in advance! Michael ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Master/Detail Table Fields?
First make sure that the Related to Ticket field is indexed Off the top of my head. the Qualification would be something like 'Related Ticket ID' = $Master Ticket Table_Ticket # column$ Fred From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Cupp, Michael E Jr. CTR USAF AFRL/SNOD Sent: Wednesday, March 28, 2007 2:21 PM To: arslist@ARSLIST.ORG Subject: Master/Detail Table Fields? ** I have a HD Ticket form that has various info, including (of course) a Ticket #. I also have a 'related to ticket #' field where a user could put in a 'master' ticket number and create a partent/child relationship, of sorts. Now, I have a display form that has a table field at the top that shows all of the 'master' tickets in the system. I then have a table field at the bottom that I would like to show all of the 'detail' tickets that tie to the master ticket which is selected in the top field. When the top 'master' ticket changes, I want to refresh the bottom field to represent the new result list. My biggest problem is how do I configure the Qualification in the Table/Tree Property tab to be able to reference the record selected in the above table field? Thanks, in advance! Michael ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
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. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
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
Walking Table Fields
We are using server 6.03 with user tool 6 on AIX/Oracle Scenario: Button on a form runs an active link which calls a guide that Loops a table The first guide has one active link which calls another guide that Loops a table. Problem: The second active link successfully walks the second table but the first table never moves beyond the first row. Is what I am trying to do possible? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Walking Table Fields
Hi Frank - I run nested AL Guide loops on a 6.0 server to build a file of command line arguments. Set Field 1 to $NULL$ being loop table 1 Append 'table 1' value to 'Field 1' begin loop table 2 Append 'table 2' value to 'Field 1' /end loop table 2 Append carriage return to 'Field 1' end loop table 1 Walks both tables as expected. Christopher Cook Applications Analyst Payment Systems 625 Fourth Ave. S., Minneapolis, MN 55415-1665 Direct: 612-340-4342 Toll-free: 800-847-4836, ext. 34342 Email: [EMAIL PROTECTED] This message contains confidential information intended only for the above addressees and may contain information that is proprietary or legally privileged. If you received this message in error, please notify us and delete the original message. You must obtain permission from Thrivent Financial to use its logo on all materials. Failure to do so could result in legal action. Frank Caruso [EMAIL PROTECTED] Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG 02/20/2007 12:13 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Walking Table Fields ** We are using server 6.03 with user tool 6 on AIX/Oracle Scenario: Button on a form runs an active link which calls a guide that Loops a table The first guide has one active link which calls another guide that Loops a table. Problem: The second active link successfully walks the second table but the first table never moves beyond the first row. Is what I am trying to do possible? __20060125___This posting was submitted with HTML in it___ jpgDYpi6f0xka.jpg Description: JPEG image
Re: Walking Table Fields
There are significant bugs with nested table loops. These are in all releases of the user tool up to at least 7.0.0. I have not tested these things beyond 7.0.0. Do not use a qualification in the second table based upon a column in the first (that is refreshed before calling the second). Instead, in the first table loop, move all columns to DO fields and use those fields in the qualifications. Similarly, in the second loop, make no references to the columns of the first. Again, have the first move all columns to DO fields and then have the second reference these fields. So, in general refresh table 1 call table loop 1 Loop1: move all columns to DO fields refresh table 2 (using the DO fields in the qualifications) call table loop2 Loop2: make no references to table 1's columns using DO fields instead. At least, when loop 2 completes (normally: do NOT exit!) it will go to the next row in table 1. So yes, it is possible... Cheers Ben _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Chris Cook Sent: February 20, 2007 7:13 PM To: arslist@ARSLIST.ORG Subject: Re: Walking Table Fields Hi Frank - I run nested AL Guide loops on a 6.0 server to build a file of command line arguments. Set Field 1 to $NULL$ being loop table 1 Append 'table 1' value to 'Field 1' begin loop table 2 Append 'table 2' value to 'Field 1' /end loop table 2 Append carriage return to 'Field 1' end loop table 1 Walks both tables as expected. Christopher Cook Applications Analyst Payment Systems 625 Fourth Ave. S., Minneapolis, MN 55415-1665 Direct: 612-340-4342 Toll-free: 800-847-4836, ext. 34342 Email: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] This message contains confidential information intended only for the above addressees and may contain information that is proprietary or legally privileged. If you received this message in error, please notify us and delete the original message. You must obtain permission from Thrivent Financial to use its logo on all materials. Failure to do so could result in legal action. Frank Caruso [EMAIL PROTECTED] Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG 02/20/2007 12:13 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Walking Table Fields ** We are using server 6.03 with user tool 6 on AIX/Oracle Scenario: Button on a form runs an active link which calls a guide that Loops a table The first guide has one active link which calls another guide that Loops a table. Problem: The second active link successfully walks the second table but the first table never moves beyond the first row. Is what I am trying to do possible? __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are attachment: ATT00313.jpg
Re: Walking Table Fields (Resolved)
Success That did it. Changed all my column references to display only fields. Thank you. On 2/20/07, Ben Chernys [EMAIL PROTECTED] wrote: ** There are significant bugs with nested table loops. These are in all releases of the user tool up to at least 7.0.0. I have not tested these things beyond 7.0.0. Do not use a qualification in the second table based upon a column in the first (that is refreshed before calling the second). Instead, in the first table loop, move all columns to DO fields and use those fields in the qualifications. Similarly, in the second loop, make no references to the columns of the first. Again, have the first move all columns to DO fields and then have the second reference these fields. So, in general refresh table 1 call table loop 1 Loop1: move all columns to DO fields refresh table 2 (using the DO fields in the qualifications) call table loop2 Loop2: make no references to table 1's columns using DO fields instead. At least, when loop 2 completes (normally: do NOT exit!) it will go to the next row in table 1. So yes, it is possible... Cheers Ben -- *From:* Action Request System discussion list(ARSList) [mailto: [EMAIL PROTECTED] *On Behalf Of *Chris Cook *Sent:* February 20, 2007 7:13 PM *To:* arslist@ARSLIST.ORG *Subject:* Re: Walking Table Fields Hi Frank - I run nested AL Guide loops on a 6.0 server to build a file of command line arguments. *Set Field 1 to $NULL$* being loop table 1 *Append 'table 1' value to 'Field 1'* begin loop table 2 *Append 'table 2' value to 'Field 1'* /end loop table 2 *Append carriage return to 'Field 1'* end loop table 1 Walks both tables as expected. Christopher Cook Applications Analyst Payment Systems 625 Fourth Ave. S., Minneapolis, MN 55415-1665 Direct: 612-340-4342 Toll-free: 800-847-4836, ext. 34342 Email: [EMAIL PROTECTED] [EMAIL PROTECTED] This message contains confidential information intended only for the above addressees and may contain information that is proprietary or legally privileged. If you received this message in error, please notify us and delete the original message. You must obtain permission from Thrivent Financial to use its logo on all materials. Failure to do so could result in legal action. *Frank Caruso [EMAIL PROTECTED]* Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG 02/20/2007 12:13 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Walking Table Fields ** We are using server 6.03 with user tool 6 on AIX/Oracle Scenario: Button on a form runs an active link which calls a guide that Loops a table The first guide has one active link which calls another guide that Loops a table. Problem: The second active link successfully walks the second table but the first table never moves beyond the first row. Is what I am trying to do possible? __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ -- Frank Caruso Specific Integration, Inc. Senior Remedy Engineer, ITIL Foundation Certified www.specificintegration.com 703-376-1249 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Tree Table Fields
Does anyone out there know what would prevent character fields having a length of 60 char and not being display only fields from being available in the sort/levels of a table (tree) based on that same base form? I have read that of course DO fields and those with a length over 128 characters aren't available, but these don't fit the bill and I'm left scratching my head. ARS 7.0.00 Oracle 10.2.0.1 Rob Tucker New Edge Networks ARS Administration and Development [EMAIL PROTECTED] Vancover,Washington tel: 360-759-9670 fax:360-693-9997 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Tree Table Fields
Rob, This might be the same bug that I found. From my support vendor email dated Dec 4: As we reported the problem with BMC, they detected this issue as a defect. The defect ID given by them is SW00255419. We are following up with them for any workaround, we will reply back as soon as we get any response. Stephen From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Tucker, Rob Sent: Thursday, December 21, 2006 3:52 PM To: arslist@ARSLIST.ORG Subject: Tree Table Fields ** Does anyone out there know what would prevent character fields having a length of 60 char and not being display only fields from being available in the sort/levels of a table (tree) based on that same base form? I have read that of course DO fields and those with a length over 128 characters aren't available, but these don't fit the bill and I'm left scratching my head. ARS 7.0.00 Oracle 10.2.0.1 Rob Tucker New Edge Networks ARS Administration and Development [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Vancover,Washington tel: 360-759-9670 fax:360-693-9997 __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
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
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
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___
ARS 7.0 Patch 2 Table Fields Sort Bug
ARS 7.0 p2 Windows Server 2003 SQL Server 2005 I think I found a bug with Table fields in ARS 7.0 Patch 2. It works on another computer with Patch 1. On the Sort/Levels tab of a table's Field Properties window not all columns are visible/available...only on Display Only forms. On Regular forms all columns [in the source form] 255 characters or less are visible, as they should. I even tried copying a table field originally created on a Regular form to a Display Only form. Most of the sort columns are no longer visible on the DO form. I tried List View and Tree View display types. Has anyone else experienced this? Stephen ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
Re: ARS 7.0 Patch 2 Table Fields Sort Bug - Workaround
Update: After further research and testing it seems to occur when there are character fields on the form that are larger than 255 characters. When I change the field length to 255 or less the columns reappear in the Sort/Levels tab. I was able to reproduce this using ARS 7.0 Patch 1 as well as Patch 2. Workaround: Delete the character fields that are larger than 255 characters. Save. Add new characters fields (with the same IDs if workflow is attached) with the previous lengths. Changing the length of the fields to 255, then saving, then changing it back didn't fix it. Note: I have only tested this on display-only forms. For regular forms or any form with data you would need to first store the contents of the character fields ( 255) in other new fields before deleting the problem fields. I have reported this as a bug to our support vendor. Stephen -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Heider, Stephen Sent: Thursday, September 28, 2006 9:55 AM To: arslist@ARSLIST.ORG Subject: ARS 7.0 Patch 2 Table Fields Sort Bug ARS 7.0 p2 Windows Server 2003 SQL Server 2005 I think I found a bug with Table fields in ARS 7.0 Patch 2. It works on another computer with Patch 1. On the Sort/Levels tab of a table's Field Properties window not all columns are visible/available...only on Display Only forms. On Regular forms all columns [in the source form] 255 characters or less are visible, as they should. I even tried copying a table field originally created on a Regular form to a Display Only form. Most of the sort columns are no longer visible on the DO form. I tried List View and Tree View display types. Has anyone else experienced this? Stephen ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
