Interesting! I will have to give that a try. The problem doesn't happen to all first-call resolution tickets but I don't know what percentage of them have this problem so it might take a while to replicate in the test environment. I am not sure if that would cause problems if the user is in a different time zone than the server; the only reason I mention that is we had resolved a totally unrelated issue by switching keywords like that due to the time zone difference.
-Rick ___________________________ Rick Westbrock QMX Support Services From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Wednesday, June 12, 2013 20:28 PM To: arslist@ARSLIST.ORG Subject: Re: Create Date later than $TIMESTAMP$ from filters ** One thing I have seen is $TIMESTAMP$ is only set at the beginning of the filter cycle. If you want the real time inside a filter you need to use $SERVERTIMESTAMP$ Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Wednesday, June 12, 2013 3:57 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Create Date later than $TIMESTAMP$ from filters ** In light of the other thread about Create Date vice Modified Date I ran into something along similar lines today an wondered if anyone else has seen something similar. We have a set of filters that put $TIMESTAMP$ into date/time fields, one per status value (i.e. if there are five different status values there will be five date/time fields). The qualifications on the filters are such that if the status changes to that value (i.e. if ticket changes to status value 2 then the Status 2 Date/Time field is used) and sets $TIMESTAMP$ into the corresponding date/time field. The strange behavior that I am seeing is that these status date/time values are all exactly one second older than the value in the core Create Date field. My assumption is that $TIMESTAMP$ is evaluated during the filter processing but the Create Date field is not populated by the server until probably the very instant before the record is actually committed to the database; if filter processing takes too long then the clock might tick over into the next second. Has anyone else run into this dilemma? It is only a problem for me because in reporting any tickets that have say the Work In Progress date/time less than the Create Date field then it is out of compliance and we have to massage the data for multiple tickets after the fact. In a recent check I found that there were 796 records where the status date/time fields were less than the Create Date but only four of them were more than one second older (obviously due to unrelated issues). The obvious quick & dirty fix for this (which may not be optimal) is to modify the filters to set the status date/time fields to $TIMESTAMP$ + 1 so that they either match the Create Date or might possibly be one second later but I wanted to investigate the root cause before touching any existing code. -Rick ARS 7.6.04 SP2/Windows/MS-SQL ___________________________ Rick Westbrock QMX Support Services ________________________________ Important: This email is intended for the above named only and may be confidential, proprietary, and/or legally privileged. If this email has come to you in error, you must take no action on it, nor may you copy or show it to anyone. Please contact the sender and delete the material from any computer. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ ________________________________ Important: This email is intended for the above named only and may be confidential, proprietary, and/or legally privileged. If this email has come to you in error, you must take no action on it, nor may you copy or show it to anyone. Please contact the sender and delete the material from any computer. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"