Axton:
Take it as my personal preference that I don't use TR
values, so I am blind by choice to the existence of
TR. Not that I never mingled with this guy TR. I bid
goodbye to TR after huge issues using it in ITSM 6.
Especially with the big forms.
Funny thing is I didn't say one day now I stop using
TR. I just don't want to set myself up (or others that
may inherit the code/form) to go crazy one day why the
code doesn't work,
in case they are updating records in ways in which all
field values being set, regardless of whether they
match db values or not, produce a non blank TR value.
There are many ways this can happen currently and who
knows what future versions will bring.
TR values make complete sense (i.e. give you what you
think it will give you) in the context of transactions
originated from non-dialog windows in Remedy User.
Outside of that context...if you just think of the
APIs...they are trouble.
In APIs, the pipe any transaction has to go through,
TR value just tells you if A field value is being sent
in the transaction or not (1), and ***NOT*** WHETHER
THE VALUE BEING SENT FOR THAT FIELD IS DIFFERENT FROM
THE VALUE SITTING IN DATABASE!! So, if the API call
was not done by Remedy User from a non-dialog window,
good luck.
Regarding the note (1) above, to make it more
confusing, if a field is being blanked out, this
statement is not true, as mentioned by others, so you
can't use a basic 'TR.Field Value' = $NULL$
I would rather be correct in my code than gain a
microsecond, especially when each DB reference is not
a separate db call.
The only situation in which I would use a TR is in
your hypothetical case...that I have form on which my
workflow will fire on a huge number of records and I
can write qualifications for all the filters firing on
that event to not use DB, but only TR. I don't
remember the last time I was in that situation.
I challenge anybody to come up with a completely
accurate and complete description of what a TR value
represents in all different ways transactions can be
initiated in Remedy.
After we all agree that the description is correct and
complete, if anybody has the appetite to read it,
understand it, remember the caveats, and then apply
that understanding accurately on a daily basis, I
would like to know.
Overall, there may be some rare instances when using
TR would give you huge advantages. Rest of the time, I
just shun it.
For me, clarity and accuracy trumps performance,
unless the performance difference is a demonstrably
huge one. So I stuffed TR deepest in my back pocket. I
still have it with me though. I think.
-------
On 10/4/07, Axton <[EMAIL PROTECTED]> wrote:
I said this last week, I'll say it again: to
blindly use one approach
is to be blind. There are certain benefits using
TR when other
methods could suffice. The trick is knowing when
and how to use them.
Any time you use a DB value in your filter
qualification, you take
another round trip to the db and add another query
to the db from the
app server.
____________________________________________________________________________________
Check out the hottest 2008 models today at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the
Answers Are"
