Norm,
For every MERGE operation on the destination there is a corresponding
MODIFY operation on the source. Make sure that is not triggering another
DSO.
Regards,
Chad Whilding
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Kaiser Norm E CIV
USAF 96 CS/SCCE
<[EMAIL PROTECTED] To
N.AF.MIL> [email protected]
Sent by: "Action cc
Request System
discussion Subject
list(ARSList)" Re: Weird DSO Behavior
<[EMAIL PROTECTED]
ORG>
08/03/2007 08:47
AM
Please respond to
[EMAIL PROTECTED]
RG
Thanks. I know how DSO works as far as a row being fetched, a row being
deleted, and a row being inserted. And we've turned on DSO, filter, and
SQL logging when performing the troubleshooting. That's pretty much a
given.
The point is, there is ONE merge event that seems to be triggering a
filter more than once.
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
Sent: Thursday, August 02, 2007 9:48 PM
To: [email protected]
Subject: Re: Weird DSO Behavior
Norm,
I think your not seeing the whole picture here.
You speak of filters and sql logs. Where is the filter logs in your
analysis? Where are the filter/sql logs from both servers? (or maybe
you just left that detail out?)
Now with that aside... I am also confused about what transfer is the
issue. Your "question" states more than a few back and forth transfers
from two ARS servers. Can you help narrow down the point that is the
problem?
You also did not list the times/order that the ARS Server selected the
record of interest. ( I think this is very important for you to figure
out what the ARS server is really doing.)
However in general you might want to know this too....
During a regular/ordinary merge event that updates an existing record
the ARS server will:
Get the record from the DB
Delete the record from the DB
Insert the record into the DB with the changes.
It is my understanding that DSO uses merge to push data from server to
server.
If you track activities on both servers (and you likely want to make
sure their system clocks are insync before you do that) then look at
the order of filter operations starts and stops first then you should
see the general flow of the data. [ How the ARS Server deals with the
RDBMS may not answer your questions about why the filter is triggered
twice. Even a simple Submit event might talk to the RDBMS several
times to get all the data saved if multiple Filter Phases are
involved. ] And I am guessing that the sql "strangeness" is a result
of Merge logic internal to the ARS server.
What I would be looking for, if I were you, is multiple Merge events
being called from the sending DSO server to the target DSO. Maybe you
are transferring the ticket multiple times? (once without ownership,
and then finally once with ownership?)
[Just a WAG.]
HTH
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
On 8/2/07, Kaiser Norm E CIV USAF 96 CS/SCCE <[EMAIL PROTECTED]>
wrote:
> **
>
>
> Hello everyone:
>
>
>
> We've run into a very weird problem with DSO and I was hoping maybe
> someone's encountered this before.
>
>
>
> We have DSO set up between two identical servers. One server is in
Florida,
> the other is in Ohio. What we do is create a request on the server in
> Florida. The technicians in Florida work the issue as best they can.
If
> they can't resolve the issue, they DSO it to the tech support center
in
> Ohio. The Ohio techs then work the issue, and when it's solved, they
return
> it back to Florida.
>
>
>
> Now, when Ohio sends the ticket back, we have workflow on the Ohio
server
> that sets the status of the ticket to Closed. When the Florida server
gets
> ownership of the ticket back, we have a filter that sets the ticket to
Group
> Assigned. The reason for that is, as far as Ohio is concerned, the
issue is
> complete. For Florida, however, the local technicians still need to
follow
> up with the customer, so the ticket is appropriately set to Group
Assigned.
>
>
>
> Here's the problem. That filter I just described? It's evaluated
TWICE.
> The filter's RUN IF qualification is 'TR.Master Flag' = "Yes" AND
'DB.Master
> Flag' != "Yes".
>
>
>
> We looked at the SQL log, and what it's doing is...
>
>
>
> 1. Delete the corresponding row on the Florida server.
>
> 2. Insert the corresponding row from the Ohio server with the
correct
> status (Group Assigned).
>
> 3. Delete the row.
>
> 4. Insert the row with the status set to CLOSED!
>
>
>
> What the...?!
>
>
>
> Any ideas?
>
> Norm
________________________________________________________________________
_______
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the
Answers Are"
