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 th
lyze 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
>
icensing 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
>> >> log
ty' = "Gotham"
> >> >> >
> >> >> > So according to my understanding, it is incorrect to say that
> >> 'TR.City'
> >> >> is
> >> >> > the same as 'City' at all times.
> >> >> >
>
y
> understanding
> >> of
> >> >> TR,
> >> >> > there is one small difference. MAYBE, I'm wrong and if so, I would
> >> love
> >> >> to
> >> >> > be corrected.
> >> >> >
> >> >
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
>> >&g
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"
>&
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"
&
t; '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"
>>
Hi all,
I have to admit that I've never once used the TR. construct, and I've been
working with this system a long time. I guess I've always assumed it had a
reasonable usage but, since I was always able to accomplish everything I
needed to do with the 'Field' and 'DB.Field' constructs, I never lo
R.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: Tra
Hi,
There is one single real benefit from using TR-values.
If you have a field that is only referenced as 'TR.Field' in the run-if of any
filter, the database value will not be retrieved during the transaction. This
is a small performance benefit.
If you have any non-TR field reference in the ru
4) Forget to change the lookup field attributes if the actual field
attributes has been changed.
Therefore, the need for Transactional (TR) and Database (DB) values on filter
level.
HTH.
Best Regards,
Theo
-Original Message-
From: Action Request System discussion list(ARSList)
[mailt
uot;
> '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
>
&
inal Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of James Smith
Sent: Thursday, May 08, 2014 10:22 AM
To: arslist@ARSLIST.ORG
Subject: Transactional (TR) and Database (DB)
Hi List,
We can achieve things without using TR and DB values
ot;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
>
>
> -Origina
Hi,
The TR values are pretty useless.
The reason is that a TR value can be set to NULL either by a change to NULL or
by not changing the field at all. In the latter case the field will retain the
value in the database after the transaction, but in the first case the NULL
will be written to the da
Some wonder why TR was built others say it works fine. I thought I had a good
handle on TR but now reading the differing opinions I am questing my
understanding of TR.
Some posts indicate it is completely useless and can't be trusted. Some other
indicate like a weapon as long as you treat it
James,
I've been doing Remedy for awhile now, and I'll be honest...I don't use TR
much, and most people that DO use it, don't understand the intricacies of
using it properly. DB is a good tool for determining if the current value
is different than the currently stored in the DB value, and I use it
slist@ARSLIST.ORG
Subject: Transactional (TR) and Database (DB)
Hi List,
We can achieve things without using TR and DB values in a filter by just using
Field but I do not understand why they have been developed to use? I have heard
from many remedy developers like Misi and BMC who suggest not to
Some wonder why TR was built others say it works fine. I thought I had a good
handle on TR but now reading the differing opinions I am questing my
understanding of TR.
Some posts indicate it is completely useless and can't be trusted. Some other
indicate like a weapon as long as you treat it
James,
TR.Field - "Transactional" value. Its the value that will be used in the
"UPDATE" sql statement that gets sent to the database.
DB.Field - "Database" value. It's the value that is currently in the
database.
Field - Without TR or DB, the value used is the "most current" value for
the field
[mailto:arslist@ARSLIST.ORG] On Behalf Of James Smith
Sent: Thursday, May 08, 2014 11:22 AM
To: arslist@ARSLIST.ORG
Subject: Transactional (TR) and Database (DB)
Hi List,
We can achieve things without using TR and DB values in a filter by just
using Field but I do not understand why they have be
Hi List,
We can achieve things without using TR and DB values in a filter by just using
Field but I do not understand why they have been developed to use? I have heard
from many remedy developers like Misi and BMC who suggest not to use TR and DB
in Run If qualification of a filter but why?
Wh
24 matches
Mail list logo
