I would recommend.. IMHO
Setting your Escalation to fire with the Qual's exactly like they
are now.. With 1 addition.
Add in the exact "Entry ID" of the One (1) you want to specifically
test this on...
Then turn on Logging.. And let her rip -- Giving Tech's a warning if
needed.. Otherwise use one for your email address..

Then watch what happens.. Use the api and sql with the same log name this
way it will be in order..
As soon as it fires, turn the log off, then Rip into the log and if you do
not get it then.. Pass the info out here
Well look her over.. And I know someone will find it..


-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:ARSLIST@ARSLIST.ORG] On Behalf Of Mougis, Phil
Sent: Friday, March 19, 2004 8:49 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: EGG on my FACE


ALL,

Thanks for ALL the responses..

My concern was not performance.. However, I will use the <= (or >=) in the
future..

As to my concern.. Isn't there a Keyword which Remedy provides which maps
effectively to DATE fields?

For such a robust product.. you would think this problem could be avoided...

for DATETIME field use.. $DATE$
for DATE field use.. something else..

By the way.. I will also mention the second part of my problem (and Why i
still have egg on my face)..

my escalatioin does 2 things...
first fires of the notifcation (too many unfortunately)...
second pushs a value to a field (which is a flag indicating the
escalation fired for the record in question)..

Well.. the second action.. the Set Fields push is not working... so I end up
sending the same emails.. over and over..

Any thoughts on why the second step in my escalation is NOT firing...

as background.. I will mention in fact there are two fields which are
supposed to be set...

Escalated - which is a data type Selection field... the Value gets set to
"Yes" Escalation Email - which is a character field (label on this hidden
field on the form is (Escalation Email)

Any thoughts on when the set fields is NOT working?

Phil



UNSUBSCRIBE or access ARSList Archives at http://www.ARSLIST.org (Support:
mailto:support@arslist.org ) ARSList is hosted by QMX SUPPORT SERVICES at
www.QMXS.com

**

I am not a manual, nor do I write them for a living.. Not my job. Nor could it be, as I Stink at writing..


The Link http://manuals.sybase.com/onlinebooks/group-as/asg1200e/aseperf/@GenericBookTextView/2137;pt=2087
Still a valid sybase link.. If you , after reading this page went to the next logical conclusion.. The little index button..

and then looked at of Sybase examples in the maunal.. It explains this for sybase.. Right ?
I mean this is the manual and it is still correct right ?


The link http://www.teradataforum.com/teradata/20020610191632.htm .. That just turned out to be the wrong link..
I thought I had the correct on .. But I did not .. I am sorry..


The link http://www.atg.com/repositories/ContentCatalogRepositoryen/manuals/ATG6.2.0/installdas/installdas2207.html
-----
The following query is fine:

SELECT *
FROM product
WHERE sku = 'a12345'
That query will not cause performance problems because the WHERE clause refers to a very specific condition on a column with an index.

Here is an example of a query that is likely to cause problems:

SELECT *
FROM product
WHERE description LIKE '%shoes%'
This query causes a table scan, since the indexes can't help the database to optimize the query. Queries like this on a large table will result in an unacceptable performance drag and therefore should not be allowed in a production system.

Here are some more queries that are likely to cause performance problems. The following query is inadvisable because, although it refers to the indexed sku column, it is not very selective and could return millions of rows:

SELECT *
FROM product
WHERE sku > 'abc'
The following query is bad because, although it is relatively selective, it will cause a table scan (at least, on most DBMSs). A LIKE query with a leading wildcard typically cannot be optimized:

SELECT *
FROM product
WHERE name LIKE '%stereo'
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What is wrong with the above ????? Looks True to me.. And helpful...


The Link http://www.schemamania.org/jkl/booksonline/SQLBOL70/html/8des051.htm

Did you click on the composite index or read
Queries using LIKE comparisons can benefit from an index if the pattern starts with a specific character string, for example 'abc%', but not if the pattern starts with a wildcard search, for example '%xyz'.

Still looks True to me for MSSQL .. And Helpful..
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The issue here is did they validate my argument.. And I would have to say.. You are correct.. I did not specifically show the argument of = or not by links clear..

My fault...
I appreciate the corrections.. Thanks.


-----Original Message-----
From: Action Request System discussion list(ARSList) [ mailto:ARSLIST@ARSLIST.ORG] On Behalf Of Thackeray, Gareth
Sent: Friday, March 19, 2004 4:56 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: EGG on my FACE


Hi Patrick,

Thanks for all your information. There's a few bits that don't seem to ring too true, though.

>ALL --- I have been to 2 (yes this is true) Remedy Performance
>Classes..
and this is a Fundamental >Teaching.

>"=" equals Index if Available.
>Like equals Table Scan forever.
> equals Table scan of all rows

My experience is that there are very few exception-free rules in db performance. It very much depends on your data and the type of queries you run.

>Test it yourself.. ensure the table is not in memory first, now with
>some
DB's you can do that.. >> >but a large server will not.. let say 30 million rows...

Well unfortunately I don't have a table with 30 million rows, but conceptually I think it should be the same for a table with 60000 rows, so I tried this.

> you can cache some but not all...
> Take the 30K row and do a query on a field let say a Char field,
> and
put the query in as a >
> Do the same thing with a >=
>I have tested and tested this.. with Oracle and mssql and it is
consistent...
> 30 seconds for first one
> 1 second for the second.

My understanding is that it is not the length of time that is interesting, it is the number of logical reads, and the mechanism used to retreive the data. This is because you cannot know which result sets / base data / whatever will be in memory when you run the query.

Since in your example, assuming there is a fairly even distribution across the rows (and not some spike at the very value on which you are searching) the results would be the same. I think the 2nd query would be quicker because the results were already in memory, rather than because indexes were / were not used. What if you try the ">" query again immediately afterwards?

On my experiment with 6000 rows on SQL Server 2000, I found that the same execution plan was used for both queries.

> http://www.atg.com/repositories/ContentCatalogRepositoryen/manuals/ATG
>6.2.
0/installdas/installdas207.html

> http://www.teradataforum.com/teradata/20020610191632.htm

> http://manuals.sybase.com/onlinebooks/group-as/asg1200e/aseperf/@Generi
>cB
ookTextView/2137;pt=2087

> http://www.schemamania.org/jkl/booksonline/SQLBOL70/html/8des051.htm

>Those Above Might help you out a little...

Well I had a look, and none of them seemed to mention this issue we're dealing with here. The first one gave the example of

SELECT *
FROM product
WHERE sku > 'abc'

being a bad query as it was not very selective. It is my understanding that it is the selectivity of a query that is the main issue in determining whether indices are used or not. In this example, replacing the > with a >= would in most cases do nothing to make the query more selective.

I'd be interested to here if the Remedy performance classes actually gave any justification why > is bad.

Best regards,

Gareth

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.




This posting was submitted via the Web interface

**
Phil,
Unfortunately, there is no other keyword that will correctly return the current date value for Date fields. In most cases, $DATE$ does work with Date fields, for example:

* As a set fields value for a Date field
* In a WUT search in the Advanced query bar, compared to a Date field

However, it doesn't seem to work in workflow qualifications such as Run If statements, table field qualifications, etc. when compared to a Date field. According to my ARS documentation, the $DATE$ keyword is supposed to function for both Date and Date/Time fields. I have a ticket in open bug status with Remedy support for this issue (bug ID is 180639). I'm guessing this wasn't resolved in 6.0, but I'm not certain.
You should be able to implement one of the work-arounds in my original posting on this thread to resolve this problem.

Concerning the issue with the Set Fields action, what value are you setting in the 'Escalation Email' field? Is this a permanent field or display-only? I would suggest turning on escalation and SQL logging on your server to try to determine what value, if any, is being set. These logs can grow very quickly, so I would suggest performing this on a non-production server if available.

Regards,

Thomas

----- Original Message -----
From: "Mougis, Phil" < phil.mougis@ACS-INC.COM>
Newsgroups: cogniza.remedy.arsystem.general
To: < ARSLIST@ARSLIST.ORG>
Sent: Friday, March 19, 2004 7:48 AM
Subject: Re: EGG on my FACE


> ALL,
>
> Thanks for ALL the responses..
>
> My concern was not performance.. However, I will use the <= (or >=) in the
> future..
>
> As to my concern.. Isn't there a Keyword which Remedy provides which maps
> effectively to DATE fields?
>
> For such a robust product.. you would think this problem could be avoided...
>
> for DATETIME field use.. $DATE$
> for DATE field use.. something else..
>
> By the way.. I will also mention the second part of my problem (and Why i
> still have egg on my face)..
>
> my escalatioin does 2 things...
> first fires of the notifcation (too many unfortunately)...
> second pushs a value to a field (which is a flag indicating the
> escalation fired for the record in question)..
>
> Well.. the second action.. the Set Fields push is not working... so I end up
> sending the same emails.. over and over..
>
> Any thoughts on why the second step in my escalation is NOT firing...
>
> as background.. I will mention in fact there are two fields which are
> supposed to be set...
>
> Escalated - which is a data type Selection field... the Value gets set to
> "Yes"
> Escalation Email - which is a character field (label on this hidden field
> on the form is (Escalation Email)
>
> Any thoughts on when the set fields is NOT working?
>
> Phil
>
>
>
This posting was submitted via the Web interface

**

I looked at the escalation log...

the second line does have a Filter operation in escalation failed, errno=30042 but the interesting thing is the next line relates to something totally unrelated to the problem... the problem being the set fields function for testting the field Escalation Email (536870975) = Past Due 3 is not successfully occurring...



TECHNICAL Request REQ000000001068 is past due.

Filter operation in escalation failed, errno=30042

Only Submitter, CRM or Member of Target Group can update a Request

REQ000000001069

0: Set Fields

Escalation Email (536870975) = Past Due 3

Escalated (536870916) = 1

1: Notify

Priority: 0 Mechanism: Email To: pmougis

TECHNICAL Request REQ000000001069 is past due.

TECHNICAL Request REQ000000001069 is past due.

Filter operation in escalation failed, errno=30042

Only Submitter, CRM or Member of Target Group can update a Request

REQ000000001210

0: Set Fields

Escalation Email (536870975) = Past Due 3

Escalated (536870916) = 1

1: Notify

Priority: 0 Mechanism: Email To: pmougis

TECHNICAL Request REQ000000001210 is past due.

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:ARSLIST@ARSLIST.ORG]On Behalf Of Thomas Bean
Sent: Friday, March 19, 2004 11:13 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: EGG on my FACE


**
Phil,
Unfortunately, there is no other keyword that will correctly return the current date value for Date fields. In most cases, $DATE$ does work with Date fields, for example:

* As a set fields value for a Date field
* In a WUT search in the Advanced query bar, compared to a Date field

However, it doesn't seem to work in workflow qualifications such as Run If statements, table field qualifications, etc. when compared to a Date field. According to my ARS documentation, the $DATE$ keyword is supposed to function for both Date and Date/Time fields. I have a ticket in open bug status with Remedy support for this issue (bug ID is 180639). I'm guessing this wasn't resolved in 6.0, but I'm not certain.
You should be able to implement one of the work-arounds in my original posting on this thread to resolve this problem.

Concerning the issue with the Set Fields action, what value are you setting in the 'Escalation Email' field? Is this a permanent field or display-only? I would suggest turning on escalation and SQL logging on your server to try to determine what value, if any, is being set. These logs can grow very quickly, so I would suggest performing this on a non-production server if available.

Regards,

Thomas

----- Original Message -----
From: "Mougis, Phil" < phil.mougis@ACS-INC.COM>
Newsgroups: cogniza.remedy.arsystem.general
To: < ARSLIST@ARSLIST.ORG>
Sent: Friday, March 19, 2004 7:48 AM
Subject: Re: EGG on my FACE


> ALL,
>
> Thanks for ALL the responses..
>
> My concern was not performance.. However, I will use the <= (or >=) in the
> future..
>
> As to my concern.. Isn't there a Keyword which Remedy provides which maps
> effectively to DATE fields?
>
> For such a robust product.. you would think this problem could be avoided...
>
> for DATETIME field use.. $DATE$
> for DATE field use.. something else..
>
> By the way.. I will also mention the second part of my problem (and Why i
> still have egg on my face)..
>
> my escalatioin does 2 things...
> first fires of the notifcation (too many unfortunately)...
> second pushs a value to a field (which is a flag indicating the
> escalation fired for the record in question)..
>
> Well.. the second action.. the Set Fields push is not working... so I end up
> sending the same emails.. over and over..
>
> Any thoughts on why the second step in my escalation is NOT firing...
>
> as background.. I will mention in fact there are two fields which are
> supposed to be set...
>
> Escalated - which is a data type Selection field... the Value gets set to
> "Yes"
> Escalation Email - which is a character field (label on this hidden field
> on the form is (Escalation Email)
>
> Any thoughts on when the set fields is NOT working?
>
> Phil
>
>
> This posting was submitted via the Web interface

This posting was submitted via the Web interface

**
Phil,
Where is this error message coming from?

Only Submitter, CRM or Member of Target Group can update a Request

Is this the line that you said was unrelated?
When you said "testting the field Escalation Email (536870975) = Past Due 3 is not successfully occurring", are you referring the the 'Run If' for the escalation testing whether the field is null? This probably wouldn't show up in the escalation log, you would need to add SQL logging to see the query that is being issued to generate the list of entries that trigger the notification.

--Thomas

----- Original Message -----
From: Mougis, Phil
Newsgroups: cogniza.remedy.arsystem.general
To: ARSLIST@ARSLIST.ORG
Sent: Friday, March 19, 2004 2:45 PM
Subject: Re: EGG on my FACE

**

I looked at the escalation log...

the second line does have a Filter operation in escalation failed, errno=30042 but the interesting thing is the next line relates to something totally unrelated to the problem... the problem being the set fields function for testting the field Escalation Email (536870975) = Past Due 3 is not successfully occurring...



TECHNICAL Request REQ000000001068 is past due.

Filter operation in escalation failed, errno=30042

Only Submitter, CRM or Member of Target Group can update a Request

REQ000000001069

0: Set Fields

Escalation Email (536870975) = Past Due 3

Escalated (536870916) = 1

1: Notify

Priority: 0 Mechanism: Email To: pmougis

TECHNICAL Request REQ000000001069 is past due.

TECHNICAL Request REQ000000001069 is past due.

Filter operation in escalation failed, errno=30042

Only Submitter, CRM or Member of Target Group can update a Request

REQ000000001210

0: Set Fields

Escalation Email (536870975) = Past Due 3

Escalated (536870916) = 1

1: Notify

Priority: 0 Mechanism: Email To: pmougis

TECHNICAL Request REQ000000001210 is past due.

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:ARSLIST@ARSLIST.ORG]On Behalf Of Thomas Bean
Sent: Friday, March 19, 2004 11:13 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: EGG on my FACE


**
Phil,
Unfortunately, there is no other keyword that will correctly return the current date value for Date fields. In most cases, $DATE$ does work with Date fields, for example:

* As a set fields value for a Date field
* In a WUT search in the Advanced query bar, compared to a Date field

However, it doesn't seem to work in workflow qualifications such as Run If statements, table field qualifications, etc. when compared to a Date field. According to my ARS documentation, the $DATE$ keyword is supposed to function for both Date and Date/Time fields. I have a ticket in open bug status with Remedy support for this issue (bug ID is 180639). I'm guessing this wasn't resolved in 6.0, but I'm not certain.
You should be able to implement one of the work-arounds in my original posting on this thread to resolve this problem.

Concerning the issue with the Set Fields action, what value are you setting in the 'Escalation Email' field? Is this a permanent field or display-only? I would suggest turning on escalation and SQL logging on your server to try to determine what value, if any, is being set. These logs can grow very quickly, so I would suggest performing this on a non-production server if available.

Regards,

Thomas

----- Original Message -----
From: "Mougis, Phil" < phil.mougis@ACS-INC.COM>
Newsgroups: cogniza.remedy.arsystem.general
To: < ARSLIST@ARSLIST.ORG>
Sent: Friday, March 19, 2004 7:48 AM
Subject: Re: EGG on my FACE


> ALL,
>
> Thanks for ALL the responses..
>
> My concern was not performance.. However, I will use the <= (or >=) in the
> future..
>
> As to my concern.. Isn't there a Keyword which Remedy provides which maps
> effectively to DATE fields?
>
> For such a robust product.. you would think this problem could be avoided...
>
> for DATETIME field use.. $DATE$
> for DATE field use.. something else..
>
> By the way.. I will also mention the second part of my problem (and Why i
> still have egg on my face)..
>
> my escalatioin does 2 things...
> first fires of the notifcation (too many unfortunately)...
> second pushs a value to a field (which is a flag indicating the
> escalation fired for the record in question)..
>
> Well.. the second action.. the Set Fields push is not working... so I end up
> sending the same emails.. over and over..
>
> Any thoughts on why the second step in my escalation is NOT firing...
>
> as background.. I will mention in fact there are two fields which are
> supposed to be set...
>
> Escalated - which is a data type Selection field... the Value gets set to
> "Yes"
> Escalation Email - which is a character field (label on this hidden field
> on the form is (Escalation Email)
>
> Any thoughts on when the set fields is NOT working?
>
> Phil
>
>
> This posting was submitted via the Web interface

This posting was submitted via the Web interface

This posting was submitted via the Web interface

**
correct me if I am wrong here Thomas
Filter operation in escalation failed, errno=30042
this is a filter with number 30042 that is blocking the escalation.. am I wrong here ?

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of Thomas Bean
Sent: Friday, March 19, 2004 7:45 PM
To: ARSLIST@ARSLIST.ORG
Subject: Re: EGG on my FACE


**
Phil,
Where is this error message coming from?

Only Submitter, CRM or Member of Target Group can update a Request

Is this the line that you said was unrelated?
When you said "testting the field Escalation Email (536870975) = Past Due 3 is not successfully occurring", are you referring the the 'Run If' for the escalation testing whether the field is null? This probably wouldn't show up in the escalation log, you would need to add SQL logging to see the query that is being issued to generate the list of entries that trigger the notification.

--Thomas

----- Original Message -----
From: Mougis, Phil
Newsgroups: cogniza.remedy.arsystem.general
To: ARSLIST@ARSLIST.ORG
Sent: Friday, March 19, 2004 2:45 PM
Subject: Re: EGG on my FACE

**

I looked at the escalation log...

the second line does have a Filter operation in escalation failed, errno=30042 but the interesting thing is the next line relates to something totally unrelated to the problem... the problem being the set fields function for testting the field Escalation Email (536870975) = Past Due 3 is not successfully occurring...



TECHNICAL Request REQ000000001068 is past due.

Filter operation in escalation failed, errno=30042

Only Submitter, CRM or Member of Target Group can update a Request

REQ000000001069

0: Set Fields

Escalation Email (536870975) = Past Due 3

Escalated (536870916) = 1

1: Notify

Priority: 0 Mechanism: Email To: pmougis

TECHNICAL Request REQ000000001069 is past due.

TECHNICAL Request REQ000000001069 is past due.

Filter operation in escalation failed, errno=30042

Only Submitter, CRM or Member of Target Group can update a Request

REQ000000001210

0: Set Fields

Escalation Email (536870975) = Past Due 3

Escalated (536870916) = 1

1: Notify

Priority: 0 Mechanism: Email To: pmougis

TECHNICAL Request REQ000000001210 is past due.

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:ARSLIST@ARSLIST.ORG]On Behalf Of Thomas Bean
Sent: Friday, March 19, 2004 11:13 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: EGG on my FACE


**
Phil,
Unfortunately, there is no other keyword that will correctly return the current date value for Date fields. In most cases, $DATE$ does work with Date fields, for example:

* As a set fields value for a Date field
* In a WUT search in the Advanced query bar, compared to a Date field

However, it doesn't seem to work in workflow qualifications such as Run If statements, table field qualifications, etc. when compared to a Date field. According to my ARS documentation, the $DATE$ keyword is supposed to function for both Date and Date/Time fields. I have a ticket in open bug status with Remedy support for this issue (bug ID is 180639). I'm guessing this wasn't resolved in 6.0, but I'm not certain.
You should be able to implement one of the work-arounds in my original posting on this thread to resolve this problem.

Concerning the issue with the Set Fields action, what value are you setting in the 'Escalation Email' field? Is this a permanent field or display-only? I would suggest turning on escalation and SQL logging on your server to try to determine what value, if any, is being set. These logs can grow very quickly, so I would suggest performing this on a non-production server if available.

Regards,

Thomas

----- Original Message -----
From: "Mougis, Phil" < phil.mougis@ACS-INC.COM>
Newsgroups: cogniza.remedy.arsystem.general
To: < ARSLIST@ARSLIST.ORG>
Sent: Friday, March 19, 2004 7:48 AM
Subject: Re: EGG on my FACE


> ALL,
>
> Thanks for ALL the responses..
>
> My concern was not performance.. However, I will use the <= (or >=) in the
> future..
>
> As to my concern.. Isn't there a Keyword which Remedy provides which maps
> effectively to DATE fields?
>
> For such a robust product.. you would think this problem could be avoided...
>
> for DATETIME field use.. $DATE$
> for DATE field use.. something else..
>
> By the way.. I will also mention the second part of my problem (and Why i
> still have egg on my face)..
>
> my escalatioin does 2 things...
> first fires of the notifcation (too many unfortunately)...
> second pushs a value to a field (which is a flag indicating the
> escalation fired for the record in question)..
>
> Well.. the second action.. the Set Fields push is not working... so I end up
> sending the same emails.. over and over..
>
> Any thoughts on why the second step in my escalation is NOT firing...
>
> as background.. I will mention in fact there are two fields which are
> supposed to be set...
>
> Escalated - which is a data type Selection field... the Value gets set to
> "Yes"
> Escalation Email - which is a character field (label on this hidden field
> on the form is (Escalation Email)
>
> Any thoughts on when the set fields is NOT working?
>
> Phil
>
>
> This posting was submitted via the Web interface

This posting was submitted via the Web interface

This posting was submitted via the Web interface

This posting was submitted via the Web interface

**
**

Patrick: That’s not the filter number, but rather the error number assigned (manually) to the Message action in the filter that is blocking the escalation. If you have access to SQL tools, search the table “filtermessage” for msgNum = 30042. (Note that msgNum is an integer field, not character.)



Mike Luttmann

Senior Database Engineer

Michael.Luttmann@peterson.af.mil





-----Original Message-----
From: Zandi Patrick S TSgt AFRL/IFOSS [mailto:Patrick.Zandi@RL.AF.MIL]
Sent: Friday, March 19, 2004 5:57 PM
To: ARSLIST@ARSLIST.ORG
Subject: Re: EGG on my FACE



correct me if I am wrong here Thomas

Filter operation in escalation failed, errno=30042

this is a filter with number 30042 that is blocking the escalation.. am I wrong here ?

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of Thomas Bean
Sent: Friday, March 19, 2004 7:45 PM
To: ARSLIST@ARSLIST.ORG
Subject: Re: EGG on my FACE

**

Phil,

Where is this error message coming from?



Only Submitter, CRM or Member of Target Group can update a Request



Is this the line that you said was unrelated?

When you said "testting the field Escalation Email (536870975) = Past Due 3 is not successfully occurring", are you referring the the 'Run If' for the escalation testing whether the field is null? This probably wouldn't show up in the escalation log, you would need to add SQL logging to see the query that is being issued to generate the list of entries that trigger the notification.



--Thomas



This posting was submitted via the Web This posting was submitted via the Web interface interface

**
Agreed.. Funny, I never have been great at the Proper terminology at times..
But yeah ... "What you said"

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of Luttmann Michael W Contr 21 SCS/SCBBN
Sent: Monday, March 22, 2004 9:28 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: EGG on my FACE



** **

Patrick: That's not the filter number, but rather the error number assigned (manually) to the Message action in the filter that is blocking the escalation. If you have access to SQL tools, search the table "filtermessage" for msgNum = 30042. (Note that msgNum is an integer field, not character.)



Mike Luttmann

Senior Database Engineer

Michael.Luttmann@peterson.af.mil





-----Original Message-----
From: Zandi Patrick S TSgt AFRL/IFOSS [mailto:Patrick.Zandi@RL.AF.MIL]
Sent: Friday, March 19, 2004 5:57 PM
To: ARSLIST@ARSLIST.ORG
Subject: Re: EGG on my FACE



correct me if I am wrong here Thomas

Filter operation in escalation failed, errno=30042

this is a filter with number 30042 that is blocking the escalation.. am I wrong here ?

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of Thomas Bean
Sent: Friday, March 19, 2004 7:45 PM
To: ARSLIST@ARSLIST.ORG
Subject: Re: EGG on my FACE

**

Phil,

Where is this error message coming from?



Only Submitter, CRM or Member of Target Group can update a Request



Is this the line that you said was unrelated?

When you said "testting the field Escalation Email (536870975) = Past Due 3 is not successfully occurring", are you referring the the 'Run If' for the escalation testing whether the field is null? This probably wouldn't show up in the escalation log, you would need to add SQL logging to see the query that is being issued to generate the list of entries that trigger the notification.



--Thomas



This posting was submitted via the Web This posting was submitted via the Web interface interface

This posting was submitted via the Web interface