Re: Notification needs to send every assignment changes into task.

[Suresh Loganathan]

Hi Joe,

Thanks for your valuable info.

I have wrote 2 filters. 1st filter showing below.  Run if empty and  set
field I mentioned below qualification 'Long group name' =$Support
Company$+"->"+$Assignee organization$+"->"+$Assignee Group$ and auto map
table declared as temp =group I'd from group form.
can able to see that value into that field.but, mail notification not send.
Notify action, can see the mechanism drop down value as email, alert,cross
reference and user profile default. present , I have chosen as email. do I
need to change anything from mechanism drop down? Notify a tion can ableto
see  only 2 drop down .please advise. how to fix this.

Regards,

Suresh Loganathan...

On Thu, May 8, 2014 at 11:46 PM, Joe D'Souza  wrote:

> **
>
> This is quite simple actually and can be done with just a minor
> customization.
>
>
>
> Compare the database and the transactional value of that assignment field
> whatever it is, and if the DB. and TR. values do not equal each other, AND
> the current value (not TR or DB – just the field with no TR. or DB. prefix)
> is not null, send that notification to whoever you wish to send it to.
>
>
>
> Joe
>
>
>  --
>
> *From:* Action Request System discussion list(ARSList) [mailto:
> arslist@ARSLIST.ORG] *On Behalf Of *Suresh Loganathan
> *Sent:* Thursday, May 08, 2014 3:17 AM
> *To:* arslist@ARSLIST.ORG
> *Subject:* Notification needs to send every assignment changes into task.
>
>
>
> **
>
> Team,
>
> Got new requirement to send a email notification when assignment fields
> changes from one group to other. In OOB Task having an issue with email
> notification. if the task has been created by task template(Single template
> multi purpose, so assignment field is an empty) with out assignment fields
> that task went to"Staging" status.When the appropriate incident went from
> In progress that time task will go to"Pending" stays with out assignment
> entry.
>
> After the pending status, i filled the assignee group and name and it's
> not sending the group and individual notification.
>
> Based on this scenario, need to write work flow every time assignment
> field  changes notification will send.
>
> Can you please advise how to fix this? Remedy Version 8.1.
>
> Regards,
>
> SureshLoganathan .
>
> _ARSlist: "Where the Answers Are" and have been for 20 years_
> _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: Non-Unicode database

[Theo Fondse]

Hi Tony,

I have a client that runs a non-unicode DB on Oracle due to legacy reasons.
There are currently no plans to switch over as the general feeling is that
they do not stand to gain anything by doing so as their system is custom
built and only used in one timezone & one language - English

Best Regards,
Theo
.


On Tue, May 13, 2014 at 5:03 PM, Tony Myers  wrote:

> Hi ARList,
>
> I doing some research on non-Unicode database usage with Remedy. Are there
> folks out there that still deploy non-Unicode DB's and if so, why? Do you
> plan to move to Unicode?
>
> Many thanks, TM
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "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: Non-Unicode database

[Sam Rx]

Tony,
my customer is on 8.1 non-unicode server and the only REASON is
that the previous versions of ARS were non-Unicode.  Customer wants Unicode
and hopefully when we upgrade next time, i expect a easier path to move
from a non-Unicode server to Unicode server.

Thanks,
Samir


On Tue, May 13, 2014 at 8:33 PM, Tony Myers  wrote:

> Hi ARList,
>
> I doing some research on non-Unicode database usage with Remedy. Are there
> folks out there that still deploy non-Unicode DB's and if so, why? Do you
> plan to move to Unicode?
>
> Many thanks, TM
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>



-- 
Best Regards,
Samir

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Transactional (TR) and Database (DB)

[Misi Mladoniczky]

Hi,

The only reason I can see for this is something I said in one of the other
zillion messages to this thread.

When you have anything but 'TR.Field' in the run-if clauses of filters, the
system will do a fetch of that fields DB-value before the filters are
processed.

So it could be a performance benefit to use ('TR.Field' != $NULL$).

In most cases the gain will be very small, but I guess it could matter 
sometimes.

Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)

Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.

> I'm curious, what's the 0.1% case when it would be useful? I'm just not
> seeing any unique use for it at all.
>
> -charlie
>
>
> On Sat, May 17, 2014 at 1:04 PM, Misi Mladoniczky  wrote:
>
>> Hi,
>>
>> It is up to the client.
>>
>> If this for example was done through a Push-Fields, 'TR.City' could
>> contain a
>> value even if it was not changed. The same could be done using a
>> Modify-All,
>> and I think it is possible to fool some clients by first changing the field
>> value in the GUI and then change it back before pressing Save.
>>
>> As others have suggested, we should stay away from TR in 99.9% of the
>> cases.
>>
>> Best Regards - Misi, RRR AB, http://rrr.se
>>
>> > Misi,
>> > Joe's example stated
>> >
>> > Case 1: When there is no change in the 'City' value during the
>> modification.
>> > 'City' = "Gotham"
>> > 'TR.City' = $NULL$ (as there was no transnational change in the value)
>> > 'DB.City' = "Gotham"
>> >
>> > So, this isn't a modify to City...this is an existing record with City
>> > already populated...so I still say that Joe's analysis is correct :)
>> >
>> >
>> > On Sun, May 11, 2014 at 4:35 AM, Misi Mladoniczky  wrote:
>> >
>> >> Hi Joe and LJ,
>> >>
>> >> You are wrong on Case 1:
>> >>
>> >> If you set the City to "Gotham", it will have a TR-value of "Gotham"
>> even
>> >> on a
>> >> Create.
>> >>
>> >> Case 2 is nothing much to say about.
>> >>
>> >> The problem with the TR value is:
>> >>
>> >> A. If the value is NOT changed it can both be set or be empty during a
>> >> Modify.
>> >> This depends on the client and how they use the API. For example a
>> >> Push-Fields
>> >> will always send a value, but a normal Save will only send a value if it
>> >> has
>> >> been changed.
>> >>
>> >> B. A value that is changed to NULL can not be distinguished from a value
>> >> that
>> >> is not sent in the transaction. Both situations will match a 'TR.Field'
>> =
>> >> $NULL$.
>> >>
>> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
>> 2011)
>> >>
>> >> Ask the Remedy Licensing Experts (Best R.O.I. Award at
>> WWRUG10/11/12/13):
>> >> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>> >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
>> logs.
>> >> Find these products, and many free tools and utilities, at
>> http://rrr.se.
>> >>
>> >> > While most of everything you stated is in sync with my understanding
>> of
>> >> TR,
>> >> > there is one small difference. MAYBE, I'm wrong and if so, I would
>> love
>> >> to
>> >> > be corrected.
>> >> >
>> >> > I can best explain this with an example.
>> >> >
>> >> > Lets say a record is created and there is a field called 'City' and
>> >> during
>> >> > creation, that field was set to "Gotham"..
>> >> >
>> >> > Case 1: When there is no change in the 'City' value during the
>> >> modification.
>> >> > 'City' = "Gotham"
>> >> > 'TR.City' = $NULL$ (as there was no transactional change in the value)
>> >> > 'DB.City' = "Gotham"
>> >> >
>> >> > Case 2: When the value in the field 'City' is changed during a
>> >> modification
>> >> > to "Xanadu"
>> >> > 'City' = "Xanadu"
>> >> > 'TR.City' = "Xanadu"
>> >> > 'DB.City' = "Gotham"
>> >> >
>> >> > So according to my understanding, it is incorrect to say that
>> 'TR.City'
>> >> is
>> >> > the same as 'City' at all times.
>> >> >
>> >> > Cheers
>> >> >
>> >> > Joe
>> >> >
>> >> >
>> >> > -Original Message-
>> >> > From: Action Request System discussion list(ARSList)
>> >> > [mailto:arslist@ARSLIST.ORG] On Behalf Of William Rentfrow
>> >> > Sent: Friday, May 09, 2014 9:28 AM
>> >> > To: arslist@ARSLIST.ORG
>> >> > Subject: Re: Transactional (TR) and Database (DB)
>> >> >
>> >> > I think there's a few reasons.
>> >> >
>> >> > First, using TR. is redundant.  Every value in a filter (unless it
>> >> already
>> >> > has DB. in front of it) is by it's nature a transactional value.
>>  There's
>> >> > literally almost no reason to use, it, EXCEPT that it makes the code a
>> >> bit
>> >> > more clear from a visual standpoint if you do decide to use DB. on a
>> >> field.
>> >> >
>> >> > I think the reason most people don't use DB. on field workflow is that
>> >> it's

Re: Transactional (TR) and Database (DB)

[Charlie Lotridge]

Hi Randeep & Misi,

I've performed a few tests and confirmed your propositions that the 'DB.'
construct causes a DB read. In a SQL log I can see a DB read before the
UPDATE only when I have a 'DB.' filter active (but not when I just have one
using 'TR.').

This is interesting and something I wasn't aware of and hadn't considered.
It certainly has only a very narrow potential usage, but I agree there may
be times when it'll come in handy as a performance boost.

Another interesting aspect of this is that ARS seems to read the entire
record, even though only one field is being used in one 'DB.'
qualification. So, I guess if you absolutely must use 'DB.' construct
anywhere in the filter sequence for a form, you may as well use it
everywhere.

I also tried turning off all of the triggers of the filter that had the
'DB.' qualification (i.e. there was no way it could be executed), and ARS
still performed the DB read. But, of course, the server can't *know* that
the filter can't run...it might be called in a guide somewhere. So this
makes sense.

So, it seems that if you have *any* active filter associated with a form
that uses a 'DB.' construct in it's qualification, ARS is going to perform
a full read of the record before filter processing.

-charlie



On Mon, May 19, 2014 at 6:04 AM, Misi Mladoniczky  wrote:

> Hi,
>
> The only reason I can see for this is something I said in one of the other
> zillion messages to this thread.
>
> When you have anything but 'TR.Field' in the run-if clauses of filters, the
> system will do a fetch of that fields DB-value before the filters are
> processed.
>
> So it could be a performance benefit to use ('TR.Field' != $NULL$).
>
> In most cases the gain will be very small, but I guess it could matter
> sometimes.
>
> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
>
> Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
> Find these products, and many free tools and utilities, at http://rrr.se.
>
> > I'm curious, what's the 0.1% case when it would be useful? I'm just not
> > seeing any unique use for it at all.
> >
> > -charlie
> >
> >
> > On Sat, May 17, 2014 at 1:04 PM, Misi Mladoniczky  wrote:
> >
> >> Hi,
> >>
> >> It is up to the client.
> >>
> >> If this for example was done through a Push-Fields, 'TR.City' could
> >> contain a
> >> value even if it was not changed. The same could be done using a
> >> Modify-All,
> >> and I think it is possible to fool some clients by first changing the
> field
> >> value in the GUI and then change it back before pressing Save.
> >>
> >> As others have suggested, we should stay away from TR in 99.9% of the
> >> cases.
> >>
> >> Best Regards - Misi, RRR AB, http://rrr.se
> >>
> >> > Misi,
> >> > Joe's example stated
> >> >
> >> > Case 1: When there is no change in the 'City' value during the
> >> modification.
> >> > 'City' = "Gotham"
> >> > 'TR.City' = $NULL$ (as there was no transnational change in the value)
> >> > 'DB.City' = "Gotham"
> >> >
> >> > So, this isn't a modify to City...this is an existing record with City
> >> > already populated...so I still say that Joe's analysis is correct :)
> >> >
> >> >
> >> > On Sun, May 11, 2014 at 4:35 AM, Misi Mladoniczky  wrote:
> >> >
> >> >> Hi Joe and LJ,
> >> >>
> >> >> You are wrong on Case 1:
> >> >>
> >> >> If you set the City to "Gotham", it will have a TR-value of "Gotham"
> >> even
> >> >> on a
> >> >> Create.
> >> >>
> >> >> Case 2 is nothing much to say about.
> >> >>
> >> >> The problem with the TR value is:
> >> >>
> >> >> A. If the value is NOT changed it can both be set or be empty during
> a
> >> >> Modify.
> >> >> This depends on the client and how they use the API. For example a
> >> >> Push-Fields
> >> >> will always send a value, but a normal Save will only send a value
> if it
> >> >> has
> >> >> been changed.
> >> >>
> >> >> B. A value that is changed to NULL can not be distinguished from a
> value
> >> >> that
> >> >> is not sent in the transaction. Both situations will match a
> 'TR.Field'
> >> =
> >> >> $NULL$.
> >> >>
> >> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
> >> 2011)
> >> >>
> >> >> Ask the Remedy Licensing Experts (Best R.O.I. Award at
> >> WWRUG10/11/12/13):
> >> >> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
> >> >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
> >> logs.
> >> >> Find these products, and many free tools and utilities, at
> >> http://rrr.se.
> >> >>
> >> >> > While most of everything you stated is in sync with my
> understanding
> >> of
> >> >> TR,
> >> >> > there is one small difference. MAYBE, I'm wrong and if so, I would
> >> love
> >> >> to
> >> >> > be corrected.
> >> >> >
> >> >> > I can best explain this with an example.
> >> >> >
> >> >> > Lets say a record 

Re: Transactional (TR) and Database (DB)

[Thad Esser]

Misi,

In regards to the argument that using TR values improves performance... if
the performance gain was measurable, then the logical extension of that
would be to re-engineer the Run-IFs of every filter in the system so that
they all use a TR value to avoid that database read.  There is a long list
of performance enhancing things that can be done before getting to that
point.

Randeep,  I have no sympathy for the TR value.  I'll keep beating up on it
until I stop seeing TR values in code from BMC.  More than once, it has
been the cause of issues.

Thad



On Mon, May 19, 2014 at 6:04 AM, Misi Mladoniczky  wrote:

> Hi,
>
> The only reason I can see for this is something I said in one of the other
> zillion messages to this thread.
>
> When you have anything but 'TR.Field' in the run-if clauses of filters, the
> system will do a fetch of that fields DB-value before the filters are
> processed.
>
> So it could be a performance benefit to use ('TR.Field' != $NULL$).
>
> In most cases the gain will be very small, but I guess it could matter
> sometimes.
>
> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
>
> Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
> Find these products, and many free tools and utilities, at http://rrr.se.
>
> > I'm curious, what's the 0.1% case when it would be useful? I'm just not
> > seeing any unique use for it at all.
> >
> > -charlie
> >
> >
> > On Sat, May 17, 2014 at 1:04 PM, Misi Mladoniczky  wrote:
> >
> >> Hi,
> >>
> >> It is up to the client.
> >>
> >> If this for example was done through a Push-Fields, 'TR.City' could
> >> contain a
> >> value even if it was not changed. The same could be done using a
> >> Modify-All,
> >> and I think it is possible to fool some clients by first changing the
> field
> >> value in the GUI and then change it back before pressing Save.
> >>
> >> As others have suggested, we should stay away from TR in 99.9% of the
> >> cases.
> >>
> >> Best Regards - Misi, RRR AB, http://rrr.se
> >>
> >> > Misi,
> >> > Joe's example stated
> >> >
> >> > Case 1: When there is no change in the 'City' value during the
> >> modification.
> >> > 'City' = "Gotham"
> >> > 'TR.City' = $NULL$ (as there was no transnational change in the value)
> >> > 'DB.City' = "Gotham"
> >> >
> >> > So, this isn't a modify to City...this is an existing record with City
> >> > already populated...so I still say that Joe's analysis is correct :)
> >> >
> >> >
> >> > On Sun, May 11, 2014 at 4:35 AM, Misi Mladoniczky  wrote:
> >> >
> >> >> Hi Joe and LJ,
> >> >>
> >> >> You are wrong on Case 1:
> >> >>
> >> >> If you set the City to "Gotham", it will have a TR-value of "Gotham"
> >> even
> >> >> on a
> >> >> Create.
> >> >>
> >> >> Case 2 is nothing much to say about.
> >> >>
> >> >> The problem with the TR value is:
> >> >>
> >> >> A. If the value is NOT changed it can both be set or be empty during
> a
> >> >> Modify.
> >> >> This depends on the client and how they use the API. For example a
> >> >> Push-Fields
> >> >> will always send a value, but a normal Save will only send a value
> if it
> >> >> has
> >> >> been changed.
> >> >>
> >> >> B. A value that is changed to NULL can not be distinguished from a
> value
> >> >> that
> >> >> is not sent in the transaction. Both situations will match a
> 'TR.Field'
> >> =
> >> >> $NULL$.
> >> >>
> >> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
> >> 2011)
> >> >>
> >> >> Ask the Remedy Licensing Experts (Best R.O.I. Award at
> >> WWRUG10/11/12/13):
> >> >> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
> >> >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
> >> logs.
> >> >> Find these products, and many free tools and utilities, at
> >> http://rrr.se.
> >> >>
> >> >> > While most of everything you stated is in sync with my
> understanding
> >> of
> >> >> TR,
> >> >> > there is one small difference. MAYBE, I'm wrong and if so, I would
> >> love
> >> >> to
> >> >> > be corrected.
> >> >> >
> >> >> > I can best explain this with an example.
> >> >> >
> >> >> > Lets say a record is created and there is a field called 'City' and
> >> >> during
> >> >> > creation, that field was set to "Gotham"..
> >> >> >
> >> >> > Case 1: When there is no change in the 'City' value during the
> >> >> modification.
> >> >> > 'City' = "Gotham"
> >> >> > 'TR.City' = $NULL$ (as there was no transactional change in the
> value)
> >> >> > 'DB.City' = "Gotham"
> >> >> >
> >> >> > Case 2: When the value in the field 'City' is changed during a
> >> >> modification
> >> >> > to "Xanadu"
> >> >> > 'City' = "Xanadu"
> >> >> > 'TR.City' = "Xanadu"
> >> >> > 'DB.City' = "Gotham"
> >> >> >
> >> >> > So according to my understanding, it is incorrect to say that
> >> 'TR.City'
> >> >> is
> >> >> > the s

Re: Transactional (TR) and Database (DB)

[Misi Mladoniczky]

Hi,

Just note that 'Field' and 'DB.Field' will cause exactly the same result. This
is because the 'Field' (most current value) will need to know the DB value to
work.

Best Regards - Misi, RRR AB, http://rrr.se

> Hi Randeep & Misi,
>
> I've performed a few tests and confirmed your propositions that the 'DB.'
> construct causes a DB read. In a SQL log I can see a DB read before the
> UPDATE only when I have a 'DB.' filter active (but not when I just have one
> using 'TR.').
>
> This is interesting and something I wasn't aware of and hadn't considered.
> It certainly has only a very narrow potential usage, but I agree there may
> be times when it'll come in handy as a performance boost.
>
> Another interesting aspect of this is that ARS seems to read the entire
> record, even though only one field is being used in one 'DB.'
> qualification. So, I guess if you absolutely must use 'DB.' construct
> anywhere in the filter sequence for a form, you may as well use it
> everywhere.
>
> I also tried turning off all of the triggers of the filter that had the
> 'DB.' qualification (i.e. there was no way it could be executed), and ARS
> still performed the DB read. But, of course, the server can't *know* that
> the filter can't run...it might be called in a guide somewhere. So this
> makes sense.
>
> So, it seems that if you have *any* active filter associated with a form
> that uses a 'DB.' construct in it's qualification, ARS is going to perform
> a full read of the record before filter processing.
>
> -charlie
>
>
>
> On Mon, May 19, 2014 at 6:04 AM, Misi Mladoniczky  wrote:
>
>> Hi,
>>
>> The only reason I can see for this is something I said in one of the other
>> zillion messages to this thread.
>>
>> When you have anything but 'TR.Field' in the run-if clauses of filters, the
>> system will do a fetch of that fields DB-value before the filters are
>> processed.
>>
>> So it could be a performance benefit to use ('TR.Field' != $NULL$).
>>
>> In most cases the gain will be very small, but I guess it could matter
>> sometimes.
>>
>> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
>>
>> Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
>> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
>> Find these products, and many free tools and utilities, at http://rrr.se.
>>
>> > I'm curious, what's the 0.1% case when it would be useful? I'm just not
>> > seeing any unique use for it at all.
>> >
>> > -charlie
>> >
>> >
>> > On Sat, May 17, 2014 at 1:04 PM, Misi Mladoniczky  wrote:
>> >
>> >> Hi,
>> >>
>> >> It is up to the client.
>> >>
>> >> If this for example was done through a Push-Fields, 'TR.City' could
>> >> contain a
>> >> value even if it was not changed. The same could be done using a
>> >> Modify-All,
>> >> and I think it is possible to fool some clients by first changing the
>> field
>> >> value in the GUI and then change it back before pressing Save.
>> >>
>> >> As others have suggested, we should stay away from TR in 99.9% of the
>> >> cases.
>> >>
>> >> Best Regards - Misi, RRR AB, http://rrr.se
>> >>
>> >> > Misi,
>> >> > Joe's example stated
>> >> >
>> >> > Case 1: When there is no change in the 'City' value during the
>> >> modification.
>> >> > 'City' = "Gotham"
>> >> > 'TR.City' = $NULL$ (as there was no transnational change in the value)
>> >> > 'DB.City' = "Gotham"
>> >> >
>> >> > So, this isn't a modify to City...this is an existing record with City
>> >> > already populated...so I still say that Joe's analysis is correct :)
>> >> >
>> >> >
>> >> > On Sun, May 11, 2014 at 4:35 AM, Misi Mladoniczky  wrote:
>> >> >
>> >> >> Hi Joe and LJ,
>> >> >>
>> >> >> You are wrong on Case 1:
>> >> >>
>> >> >> If you set the City to "Gotham", it will have a TR-value of "Gotham"
>> >> even
>> >> >> on a
>> >> >> Create.
>> >> >>
>> >> >> Case 2 is nothing much to say about.
>> >> >>
>> >> >> The problem with the TR value is:
>> >> >>
>> >> >> A. If the value is NOT changed it can both be set or be empty during
>> a
>> >> >> Modify.
>> >> >> This depends on the client and how they use the API. For example a
>> >> >> Push-Fields
>> >> >> will always send a value, but a normal Save will only send a value
>> if it
>> >> >> has
>> >> >> been changed.
>> >> >>
>> >> >> B. A value that is changed to NULL can not be distinguished from a
>> value
>> >> >> that
>> >> >> is not sent in the transaction. Both situations will match a
>> 'TR.Field'
>> >> =
>> >> >> $NULL$.
>> >> >>
>> >> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
>> >> 2011)
>> >> >>
>> >> >> Ask the Remedy Licensing Experts (Best R.O.I. Award at
>> >> WWRUG10/11/12/13):
>> >> >> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>> >> >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
>> >> logs.
>> >> >> Find these products, and many f

Re: Transactional (TR) and Database (DB)

[Misi Mladoniczky]

Hi,

As discussed earlier, the TR-values are not foolproof to find a change.
Because of this you cant just redesign to use TR-values instead of 'DB.Field'
and 'Field' (Most Current) values.

Best Regards - Misi, RRR AB, http://rrr.se

> Misi,
>
> In regards to the argument that using TR values improves performance... if
> the performance gain was measurable, then the logical extension of that
> would be to re-engineer the Run-IFs of every filter in the system so that
> they all use a TR value to avoid that database read.  There is a long list
> of performance enhancing things that can be done before getting to that
> point.
>
> Randeep,  I have no sympathy for the TR value.  I'll keep beating up on it
> until I stop seeing TR values in code from BMC.  More than once, it has
> been the cause of issues.
>
> Thad
>
>
>
> On Mon, May 19, 2014 at 6:04 AM, Misi Mladoniczky  wrote:
>
>> Hi,
>>
>> The only reason I can see for this is something I said in one of the other
>> zillion messages to this thread.
>>
>> When you have anything but 'TR.Field' in the run-if clauses of filters, the
>> system will do a fetch of that fields DB-value before the filters are
>> processed.
>>
>> So it could be a performance benefit to use ('TR.Field' != $NULL$).
>>
>> In most cases the gain will be very small, but I guess it could matter
>> sometimes.
>>
>> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
>>
>> Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
>> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
>> Find these products, and many free tools and utilities, at http://rrr.se.
>>
>> > I'm curious, what's the 0.1% case when it would be useful? I'm just not
>> > seeing any unique use for it at all.
>> >
>> > -charlie
>> >
>> >
>> > On Sat, May 17, 2014 at 1:04 PM, Misi Mladoniczky  wrote:
>> >
>> >> Hi,
>> >>
>> >> It is up to the client.
>> >>
>> >> If this for example was done through a Push-Fields, 'TR.City' could
>> >> contain a
>> >> value even if it was not changed. The same could be done using a
>> >> Modify-All,
>> >> and I think it is possible to fool some clients by first changing the
>> field
>> >> value in the GUI and then change it back before pressing Save.
>> >>
>> >> As others have suggested, we should stay away from TR in 99.9% of the
>> >> cases.
>> >>
>> >> Best Regards - Misi, RRR AB, http://rrr.se
>> >>
>> >> > Misi,
>> >> > Joe's example stated
>> >> >
>> >> > Case 1: When there is no change in the 'City' value during the
>> >> modification.
>> >> > 'City' = "Gotham"
>> >> > 'TR.City' = $NULL$ (as there was no transnational change in the value)
>> >> > 'DB.City' = "Gotham"
>> >> >
>> >> > So, this isn't a modify to City...this is an existing record with City
>> >> > already populated...so I still say that Joe's analysis is correct :)
>> >> >
>> >> >
>> >> > On Sun, May 11, 2014 at 4:35 AM, Misi Mladoniczky  wrote:
>> >> >
>> >> >> Hi Joe and LJ,
>> >> >>
>> >> >> You are wrong on Case 1:
>> >> >>
>> >> >> If you set the City to "Gotham", it will have a TR-value of "Gotham"
>> >> even
>> >> >> on a
>> >> >> Create.
>> >> >>
>> >> >> Case 2 is nothing much to say about.
>> >> >>
>> >> >> The problem with the TR value is:
>> >> >>
>> >> >> A. If the value is NOT changed it can both be set or be empty during
>> a
>> >> >> Modify.
>> >> >> This depends on the client and how they use the API. For example a
>> >> >> Push-Fields
>> >> >> will always send a value, but a normal Save will only send a value
>> if it
>> >> >> has
>> >> >> been changed.
>> >> >>
>> >> >> B. A value that is changed to NULL can not be distinguished from a
>> value
>> >> >> that
>> >> >> is not sent in the transaction. Both situations will match a
>> 'TR.Field'
>> >> =
>> >> >> $NULL$.
>> >> >>
>> >> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
>> >> 2011)
>> >> >>
>> >> >> Ask the Remedy Licensing Experts (Best R.O.I. Award at
>> >> WWRUG10/11/12/13):
>> >> >> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>> >> >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
>> >> logs.
>> >> >> Find these products, and many free tools and utilities, at
>> >> http://rrr.se.
>> >> >>
>> >> >> > While most of everything you stated is in sync with my
>> understanding
>> >> of
>> >> >> TR,
>> >> >> > there is one small difference. MAYBE, I'm wrong and if so, I would
>> >> love
>> >> >> to
>> >> >> > be corrected.
>> >> >> >
>> >> >> > I can best explain this with an example.
>> >> >> >
>> >> >> > Lets say a record is created and there is a field called 'City' and
>> >> >> during
>> >> >> > creation, that field was set to "Gotham"..
>> >> >> >
>> >> >> > Case 1: When there is no change in the 'City' value during the
>> >> >> modification.
>> >> >> > 'City' = "Gotham"
>> >> >> > 'TR.City' = $NULL$ (as there was no transaction

Re: Transactional (TR) and Database (DB)

[Sweety]

Totally agree with Misi. Putting all together in simple way

TR - Holds only transaction values coming from API or remedy workflow
DB - Holds the values present in database
Just a field - Checks the value changes/entered by user and if it is blank, a 
check is made against database values.

Hope that clears concept of everything.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Data in server-side table fields is read-only.

[Sweety]

Anybody help me in understanding this statement? Why is it read-only?

//docs.bmc(dot)com/docs/display/public/ars81/Table+fields

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Data in server-side table fields is read-only.

[LJ LongWing]

Sweety,
I'm unsure why that statement is even in therebut data in ALL table
fields is read onlythe fact that some fields can be set as 'editable'
doesn't make it actually editable, you still need to loop through the table
and push values to the DB

What is your concern about that statement specifically?


On Mon, May 19, 2014 at 2:43 PM, Sweety  wrote:

> Anybody help me in understanding this statement? Why is it read-only?
>
> //docs.bmc(dot)com/docs/display/public/ars81/Table+fields
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "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: Data in server-side table fields is read-only.

[Sweety]

Statement says, Data in server-side table fields is read-only? What does it 
means? I can edit the record in a table by editing a record existing in a form 
which is refering to the table.

It just says server side table field is ready-only, does it mean client side 
table field is writable?

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Data in server-side table fields is read-only.

[Roger Justice]

The statement is to allow a developer to create filter workflow that would 
allow for the concept of walking a table field without having to create the 
table field on the form and using Active Links to walk it.



-Original Message-
From: LJ LongWing 
To: arslist 
Sent: Mon, May 19, 2014 4:49 pm
Subject: Re: Data in server-side table fields is read-only.


** 
Sweety, 
I'm unsure why that statement is even in therebut data in ALL table fields 
is read onlythe fact that some fields can be set as 'editable' doesn't make 
it actually editable, you still need to loop through the table and push values 
to the DB


What is your concern about that statement specifically?




On Mon, May 19, 2014 at 2:43 PM, Sweety  wrote:

Anybody help me in understanding this statement? Why is it read-only?

//docs.bmc(dot)com/docs/display/public/ars81/Table+fields

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"



_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: Data in server-side table fields is read-only.

[Sweety]

I have not said that I want to create a table field at all. It says data is 
read only. Why I cannot update the data in server side table? I do not 
understant the statement "Data in server-side table fields is read-only". Make 
me understand it please.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Copying a decimal field into a currency field

[Rick Westbrock]

Hi folks, I am working with a legacy custom application on my ARS 7.0.1 system 
(Oracle 10 back-end) where the initial developer created a Price field as a 
decimal field. My problem is that now we are integrating this form with the 
CMDB (ITSM 7.0.03) and I need to get that data into a currency field. My 
initial thought was to create a new currency field named Cost and do a simple 
SQL update statement to get the data copied rather than rely on an escalation.

I thought that this statement would work and it does update the destination 
fields to the expected values, however when I look at the record in the WUT the 
new field is empty. Any idea why this might be or how to get around it via SQL? 
I will use an escalation if I have to but I don't like having to change the 
Modified Date on historical records. If there's a way to preserve the Modified 
Date with some smoke & mirrors I would appreciate that as well.

My understanding is that there is come CMDB "black box" functionality that 
handles currency fields and I can import currency data into AST forms via a CSV 
file and that process works fine so apparently the import tool runs the data 
through that black box on the way into the AST forms.

-Rick

_
Rick Westbrock
Remedy Administrator | IT Department
24 Hour Fitness USA, Inc.




___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Copying a decimal field into a currency field

[Randeep Atwal]

**
Check out the database Ref document for 7.0I recall that for currency fields, there are four columns that need updating. Value, Code, Date of conversion and value for the supported currencies.They all use the same field id with special suffixes, so it will be tricky with sql but ou could set it up with one currency quite easily I would think.  Sent from my BlackBerry 10 smartphone on the Rogers network. From: Rick WestbrockSent: Monday, May 19, 2014 6:10 PMTo: arslist@ARSLIST.ORGReply To: arslist@ARSLIST.ORGSubject: Copying a decimal field into a currency field**








Hi folks, I am working with a legacy custom application on my ARS 7.0.1 system (Oracle 10 back-end) where the initial developer created a Price field as a decimal field. My problem is that now we are integrating this form with the CMDB
 (ITSM 7.0.03) and I need to get that data into a currency field. My initial thought was to create a new currency field named Cost and do a simple SQL update statement to get the data copied rather than rely on an escalation.
 
I thought that this statement would work and it does update the destination fields to the expected values, however when I look at the record in the WUT the new field is empty. Any idea why this might be or how to get around it via SQL?
 I will use an escalation if I have to but I don’t like having to change the Modified Date on historical records. If there’s a way to preserve the Modified Date with some smoke & mirrors I would appreciate that as well.
 
My understanding is that there is come CMDB “black box” functionality that handles currency fields and I can import currency data into AST forms via a CSV file and that process works fine so apparently the import tool runs the data through
 that black box on the way into the AST forms.
 
-Rick
 
_
Rick Westbrock
Remedy Administrator | IT Department
24 Hour Fitness USA, Inc.



 



_ARSlist: "Where the Answers Are" and have been for 20 years_

_ARSlist: "Where the Answers Are" and have been for 20 years_

Re: Data in server-side table fields is read-only.

[Carlyle, Phil]

Sweety
Are you using Chrome or IE as your browser?
I find the site to only support Chrome.
Phil

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Sweety
Sent: Monday, May 19, 2014 3:05 PM
To: arslist@ARSLIST.ORG
Subject: Re: Data in server-side table fields is read-only.

I have not said that I want to create a table field at all. It says data is 
read only. Why I cannot update the data in server side table? I do not 
understant the statement "Data in server-side table fields is read-only". Make 
me understand it please.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "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: Copying a decimal field into a currency field

[Rick Westbrock]

Thanks Randeep, I only saw three fields in the DB associated with my new Cost 
field: CostC (currency type such as USD), CostV (the numeric value) and CostD 
(epoch time). That must be because I was lazy and was looking at the view 
instead of the table itself. Once I looked directly at the table I see that 
there’s a fourth suffix “USD” but for the record that I had modified via SQL 
that fourth column was indeed null.

I re-ran the SQL statement but this time against the table and it updated all 
four columns (C, V, D and USD) however the WUT still shows the field empty. 
Thanks for directing me to the Database Reference document, I will definitely 
remember to check there in the future but it didn’t completely resolve my issue 
yet. I had set the value of the USD column the same as the V column based on 
the data for a record I had modified via the WUT first.

I must still be missing something, below is the update statement that I used.

UPDATE T1545
SET C536870961V = C26061, C536870961C = 'USD', C536870961D = C6, 
C536870961USD = C26061
 WHERE C1 = '0044210'


Thanks in advance,
Rick

_
Rick Westbrock
Remedy Administrator | IT Department
24 Hour Fitness USA, Inc.



From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Randeep Atwal
Sent: Monday, May 19, 2014 3:36 PM
To: arslist@ARSLIST.ORG
Subject: Re: Copying a decimal field into a currency field

**
Check out the database Ref document for 7.0

I recall that for currency fields, there are four columns that need updating. 
Value, Code, Date of conversion and value for the supported currencies.

They all use the same field id with special suffixes, so it will be tricky with 
sql but ou could set it up with one currency quite easily I would think.

Sent from my BlackBerry 10 smartphone on the Rogers network.
From: Rick Westbrock
Sent: Monday, May 19, 2014 6:10 PM
To: arslist@ARSLIST.ORG
Reply To: arslist@ARSLIST.ORG
Subject: Copying a decimal field into a currency field


**
Hi folks, I am working with a legacy custom application on my ARS 7.0.1 system 
(Oracle 10 back-end) where the initial developer created a Price field as a 
decimal field. My problem is that now we are integrating this form with the 
CMDB (ITSM 7.0.03) and I need to get that data into a currency field. My 
initial thought was to create a new currency field named Cost and do a simple 
SQL update statement to get the data copied rather than rely on an escalation.

I thought that this statement would work and it does update the destination 
fields to the expected values, however when I look at the record in the WUT the 
new field is empty. Any idea why this might be or how to get around it via SQL? 
I will use an escalation if I have to but I don’t like having to change the 
Modified Date on historical records. If there’s a way to preserve the Modified 
Date with some smoke & mirrors I would appreciate that as well.

My understanding is that there is come CMDB “black box” functionality that 
handles currency fields and I can import currency data into AST forms via a CSV 
file and that process works fine so apparently the import tool runs the data 
through that black box on the way into the AST forms.

-Rick

_
Rick Westbrock
Remedy Administrator | IT Department
24 Hour Fitness USA, Inc.


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Copying a decimal field into a currency field

[Randeep Atwal]

**
I'd suggest just adding a record or updating one from the user tool with sql logging turned on and reverse engineer it from there once you see how AR is doing it.Hope this helpsRandeep   From: Rick WestbrockSent: Monday, May 19, 2014 7:18 PMTo: arslist@ARSLIST.ORGReply To: arslist@ARSLIST.ORGSubject: Re: Copying a decimal field into a currency field**








Thanks Randeep, I only saw three fields in the DB associated with my new Cost field: CostC (currency type such as USD), CostV (the numeric value) and CostD (epoch time). That must be because I was lazy and was
 looking at the view instead of the table itself. Once I looked directly at the table I see that there’s a fourth suffix “USD” but for the record that I had modified via SQL that fourth column was indeed null.
 
I re-ran the SQL statement but this time against the table and it updated all four columns (C, V, D and USD) however the WUT still shows the field empty. Thanks for directing me to the Database Reference document,
 I will definitely remember to check there in the future but it didn’t completely resolve my issue yet. I had set the value of the USD column the same as the V column based on the data for a record I had modified via the WUT first.
 
I must still be missing something, below is the update statement that I used.
 
UPDATE
T1545
SET
 C536870961V = C26061,
 C536870961C =
'USD',
 C536870961D = C6,
 C536870961USD = C26061

 WHERE
 C1 =
'0044210'

 
 
Thanks in advance,
Rick
 
_
Rick Westbrock
Remedy Administrator | IT Department
24 Hour Fitness USA, Inc.



 
From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG]
On Behalf Of Randeep Atwal
Sent: Monday, May 19, 2014 3:36 PM
To: arslist@ARSLIST.ORG
Subject: Re: Copying a decimal field into a currency field
 
**

Check out the database Ref document for 7.0

 


I recall that for currency fields, there are four columns that need updating. Value, Code, Date of conversion and value for the supported currencies.


 


They all use the same field id with special suffixes, so it will be tricky with sql but ou could set it up with one currency quite easily I would think.


 


Sent from my BlackBerry 10 smartphone on the Rogers network.







From:
Rick Westbrock


Sent:
Monday, May 19, 2014 6:10 PM


To:
arslist@ARSLIST.ORG


Reply To:
arslist@ARSLIST.ORG


Subject:
Copying a decimal field into a currency field






 

** 

Hi folks, I am working with a legacy custom application on my ARS 7.0.1 system (Oracle 10 back-end) where the initial developer created a Price field as a decimal field. My problem is that now we are integrating
 this form with the CMDB (ITSM 7.0.03) and I need to get that data into a currency field. My initial thought was to create a new currency field named Cost and do a simple SQL update statement to get the data copied rather than rely on an escalation.
 
I thought that this statement would work and it does update the destination fields to the expected values, however when I look at the record in the WUT the new field is empty. Any idea why this might be or how to
 get around it via SQL? I will use an escalation if I have to but I don’t like having to change the Modified Date on historical records. If there’s a way to preserve the Modified Date with some smoke & mirrors I would appreciate that as well.
 
My understanding is that there is come CMDB “black box” functionality that handles currency fields and I can import currency data into AST forms via a CSV file and that process works fine so apparently the import
 tool runs the data through that black box on the way into the AST forms.
 
-Rick
 
_
Rick Westbrock
Remedy Administrator | IT Department
24 Hour Fitness USA, Inc.






_ARSlist: "Where the Answers Are" and have been for 20 years_

_ARSlist: "Where the Answers Are" and have been for 20 years_

Re: Copying a decimal field into a currency field

[Randeep Atwal]

**
  Sent from my BlackBerry 10 smartphone on the Rogers network. From: ratwals...@gmail.comSent: Monday, May 19, 2014 8:06 PMTo: arslist@ARSLIST.ORG; arslist@ARSLIST.ORGSubject: Re: Copying a decimal field into a currency fieldI'd suggest just adding a record or updating one from the user tool with sql logging turned on and reverse engineer it from there once you see how AR is doing it.Hope this helpsRandeep   From: Rick WestbrockSent: Monday, May 19, 2014 7:18 PMTo: arslist@ARSLIST.ORGReply To: arslist@ARSLIST.ORGSubject: Re: Copying a decimal field into a currency field**








Thanks Randeep, I only saw three fields in the DB associated with my new Cost field: CostC (currency type such as USD), CostV (the numeric value) and CostD (epoch time). That must be because I was lazy and was
 looking at the view instead of the table itself. Once I looked directly at the table I see that there’s a fourth suffix “USD” but for the record that I had modified via SQL that fourth column was indeed null.
 
I re-ran the SQL statement but this time against the table and it updated all four columns (C, V, D and USD) however the WUT still shows the field empty. Thanks for directing me to the Database Reference document,
 I will definitely remember to check there in the future but it didn’t completely resolve my issue yet. I had set the value of the USD column the same as the V column based on the data for a record I had modified via the WUT first.
 
I must still be missing something, below is the update statement that I used.
 
UPDATE
T1545
SET
 C536870961V = C26061,
 C536870961C =
'USD',
 C536870961D = C6,
 C536870961USD = C26061

 WHERE
 C1 =
'0044210'

 
 
Thanks in advance,
Rick
 
_
Rick Westbrock
Remedy Administrator | IT Department
24 Hour Fitness USA, Inc.



 
From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG]
On Behalf Of Randeep Atwal
Sent: Monday, May 19, 2014 3:36 PM
To: arslist@ARSLIST.ORG
Subject: Re: Copying a decimal field into a currency field
 
**

Check out the database Ref document for 7.0

 


I recall that for currency fields, there are four columns that need updating. Value, Code, Date of conversion and value for the supported currencies.


 


They all use the same field id with special suffixes, so it will be tricky with sql but ou could set it up with one currency quite easily I would think.


 


Sent from my BlackBerry 10 smartphone on the Rogers network.







From:
Rick Westbrock


Sent:
Monday, May 19, 2014 6:10 PM


To:
arslist@ARSLIST.ORG


Reply To:
arslist@ARSLIST.ORG


Subject:
Copying a decimal field into a currency field






 

** 

Hi folks, I am working with a legacy custom application on my ARS 7.0.1 system (Oracle 10 back-end) where the initial developer created a Price field as a decimal field. My problem is that now we are integrating
 this form with the CMDB (ITSM 7.0.03) and I need to get that data into a currency field. My initial thought was to create a new currency field named Cost and do a simple SQL update statement to get the data copied rather than rely on an escalation.
 
I thought that this statement would work and it does update the destination fields to the expected values, however when I look at the record in the WUT the new field is empty. Any idea why this might be or how to
 get around it via SQL? I will use an escalation if I have to but I don’t like having to change the Modified Date on historical records. If there’s a way to preserve the Modified Date with some smoke & mirrors I would appreciate that as well.
 
My understanding is that there is come CMDB “black box” functionality that handles currency fields and I can import currency data into AST forms via a CSV file and that process works fine so apparently the import
 tool runs the data through that black box on the way into the AST forms.
 
-Rick
 
_
Rick Westbrock
Remedy Administrator | IT Department
24 Hour Fitness USA, Inc.






_ARSlist: "Where the Answers Are" and have been for 20 years_


_ARSlist: "Where the Answers Are" and have been for 20 years_

Re: Advanced Remedy Log Analyzer - ARSKit.com

[anandsagar sah]

Hello Everyone,

ARSKit.com introduces new feature "Field Usages" to identify the usages of
field from remedy log.

Watch 5 minutes of Video tutorial (download it
now)
on how difficult it is to identify field usages manually and how easy you
can achieve same from ARSKit Remedy Log Analyzer.
Click here to visit the product
page
.

Thanks and Regards,
Sah Anandsagar
arskit.com


On Mon, May 5, 2014 at 9:32 AM, anandsagar sah wrote:

> Hello Remedy Folks,
>
>
>
> My name is Anandsagar Sah, and this is regarding new product that has been
> launched through ARSkit.com.
>
>
>
> *ARSKit.com * (renamed from
> remedyloganalyzer[dot]com) offer supporting products for BMC ARS Remedy
> based applications, useful for remedy developers/administrators/support
> agents. Remedy Log Analyzer is the first product and has been enhanced to
> provide various option to deal with remedy logs.
>
>
>
> Following are features of ARSKit Remedy log Analyzer :-
>
> •Capture Remedy Logs “easily”
>
> •Manipulate logs for better analysis (split, combine, extract)
>
> •Convert Remedy logs into different format for better workflow analysis
>
> oColourful representation
>
> oEasy understanding of flow with execution period
>
> oEagle view of execution
>
> oEasy navigation
>
> oEasy debugging
>
> •Generate Performance Report
>
> oAPI Walk through for functional performance analysis
>
> oAPI, Filter and SQL detail report
>
> oTable detail for overall usages of database table
>
> oUser/Client detail for overall system resources utilization
>
> oThread Statistics
>
> •Easy sharing of Remedy workflow/performance analysis result
>
> •Maintain history of analysis result into your online account
>
>
>
> If this seems interesting, please visit the site, check out demo reports
> and start uploading your remedy application logs. Please contact us for any
> suggestions or if you face any issue or would like to provide any feedback.
>
>
>
> Home Page: http://arskit.com
>
> Demo: http://arskit.com/demo/
> Download presentation 
> video
>
> --
> Thanks and Regards,
> Sah Anandsagar
> arskit.com
>



--

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"