The value for the create date is generated after phase 2, when the record is committed. I don't believe there's a way to override that value. You could ensure your set field filter is at 999 to limit the time gap between phase 1 and the commit, but you'll still have to wait for the push fields and other phase 2 actions to run. What about running an escalation to clean up any of the status fields that are less than the create date?
Jason Bess On Jun 12, 2013, at 4:57 PM, Rick Westbrock <[email protected]> wrote: > ** > 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_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
