Thanks Joe. If I remember correctly on submit of a new request that Request ID wouldn't get generated until after all filters have processed. This particular issues is for our custom forms only so far (nothing OOTB).
I forgot that the other option would be to tweak the reporting criteria so that if the difference between fields is only one second that they wouldn't be flagged as problem records in the first place. -Rick ___________________________ Rick Westbrock QMX Support Services From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Joe D'Souza Sent: Wednesday, June 12, 2013 14:09 PM To: [email protected] Subject: Re: Create Date later than $TIMESTAMP$ from filters ** My guess is that the create date is set at the same time that the Request ID is set, as that would be the true create date stamp, at the time the Request ID is created. Just a guess - I have noticed such differences of a second too but didn't question the difference as it seemed too insignificant to the business processes that I have had to track in my experience. Joe ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Rick Westbrock Sent: Wednesday, June 12, 2013 4:57 PM To: [email protected]<mailto:[email protected]> 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 _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"
