Re: Create Date later than $TIMESTAMP$ from filters
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 rwestbr...@qmxs.com 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
Re: Create Date later than $TIMESTAMP$ from filters
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.ORGmailto: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
Re: Create Date later than $TIMESTAMP$ from filters
As you are working with Filters the time zone will not be an issue (as you are processing the keyword on the server in both cases) I only noticed it when I had a form with a lot of Filters that took a while to process Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Thursday, June 13, 2013 11:17 AM To: arslist@ARSLIST.ORG Subject: Re: Create Date later than $TIMESTAMP$ from filters ** 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 -Original Message- 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 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Create Date later than $TIMESTAMP$ from filters
Good point, I realized after I sent my reply that the previous problem was using active links and not filters. I will have to check out the total filter count for that form since I hadn't looked at that yet. -Rick ___ Rick Westbrock QMX Support Services -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Thursday, June 13, 2013 9:51 AM To: arslist@ARSLIST.ORG Subject: Re: Create Date later than $TIMESTAMP$ from filters As you are working with Filters the time zone will not be an issue (as you are processing the keyword on the server in both cases) I only noticed it when I had a form with a lot of Filters that took a while to process Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Thursday, June 13, 2013 11:17 AM To: arslist@ARSLIST.ORG Subject: Re: Create Date later than $TIMESTAMP$ from filters ** 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 -Original Message- 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 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 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
Re: Create Date later than $TIMESTAMP$ from filters
I seem to recall I had a similar problem a while back and the solution I came up with was to use business time based on the create date. Might work for you. $PROCESS$ Application-Bus-Time-Add $Create Date$ 0 0 Business Time Holidays Business Time Workdays Mark -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Thursday, June 13, 2013 2:01 PM To: arslist@ARSLIST.ORG Subject: Re: Create Date later than $TIMESTAMP$ from filters Good point, I realized after I sent my reply that the previous problem was using active links and not filters. I will have to check out the total filter count for that form since I hadn't looked at that yet. -Rick ___ Rick Westbrock QMX Support Services -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Thursday, June 13, 2013 9:51 AM To: arslist@ARSLIST.ORG Subject: Re: Create Date later than $TIMESTAMP$ from filters As you are working with Filters the time zone will not be an issue (as you are processing the keyword on the server in both cases) I only noticed it when I had a form with a lot of Filters that took a while to process Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Thursday, June 13, 2013 11:17 AM To: arslist@ARSLIST.ORG Subject: Re: Create Date later than $TIMESTAMP$ from filters ** 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 -Original Message- 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 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years Important
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. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
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:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Wednesday, June 12, 2013 4:57 PM To: 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 _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: Create Date later than $TIMESTAMP$ from filters
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:arslist@ARSLIST.ORG] On Behalf Of Joe D'Souza Sent: Wednesday, June 12, 2013 14:09 PM To: arslist@ARSLIST.ORG 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:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Wednesday, June 12, 2013 4:57 PM To: arslist@ARSLIST.ORGmailto: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 _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
Re: Create Date later than $TIMESTAMP$ from filters
Exactly - which is why your custom filters having processed that 1 second earlier on occasions have a older time stamp by a second after which the record gets submitted where it gets all its core information which includes user stamps, time stamps and the request ID. Joe _ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Wednesday, June 12, 2013 5:19 PM To: arslist@ARSLIST.ORG Subject: Re: Create Date later than $TIMESTAMP$ from filters 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:arslist@ARSLIST.ORG] On Behalf Of Joe D'Souza Sent: Wednesday, June 12, 2013 14:09 PM To: arslist@ARSLIST.ORG 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:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Wednesday, June 12, 2013 4:57 PM To: 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 _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. _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: 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 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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
