Tony, adding $USER$ would be the easy solution (one I had considered), however, the transfer-to server is not just a reporting server but it is also a fail over box. So, all work flow on the box must match production. Making that type of change would break work flow if we ever failed over.
Chad, your right. Even though the RunProcess set its a MERGE operation, I don't believe it truly is. I added to the filter RunIf $OPERATE$ != MERGE and it still ran! I added $USER$!="Distributed Server" and it did not. However, as mention above, that is not a possible solution.
To make this even more complicated. The DSO transfer is actually being initiated by a third server in the UK, which then writes to temp table here, which pushes changes to forms which in turn causes DSO to replicate data.
Still thinking about it ......
Thank you
On 10/17/06, Tony Worthington <[EMAIL PROTECTED]
> wrote:
Frank -
To catch times when this happens -- as mentioned below -- I would say it
couldn't hurt to add a ( AND $USER$ != "Distributed Server" )
qualification to the workflow in question that you want to make sure is
never triggered by a DSO transaction. This way the workflow will function
on an import merge, but not a DSO transfer/etc.
--
Tony Worthington
[EMAIL PROTECTED]
262-703-5911
Chad M Whilding < [EMAIL PROTECTED]>
Sent by: "Action Request System discussion list(ARSList)"
<[email protected]>
10/17/2006 01:17 PM
Please respond to
[email protected]
To
[email protected]
cc
Subject
Re: DSO and $OPERATION$
Frank,
If your problem is not intermittent, have you confirmed with logging,or
some other method, that it is actually firing in Merge and not Modify.
In my experience, the DSO transaction on the destination will first
receive
the Merge and then a follow-up Modify. So I am assuming the issue is on
the destination end, since you mention MERGE.
Even if the Run Process with keywords, is showing Merge, I wouldn't
necessarily trust it, as that is also a Phase III operation and will fire
the first time Phase III is processed and that could well be the Merge
operation. A Phase III operation doesn't wait until the Phase I or Phase
II that triggered it completes. A Phase III operation is an opportunistic
little bugger, they fire as soon as any Phase III is initiated.
All that being said, what does the filter logging show? Any chance that
you have a MERGE operation that triggers a modify unto the record itself?
Even via a third form?
Hope this helps
Chad
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Frank Caruso
<[EMAIL PROTECTED]
IL.COM> To
Sent by: "Action [email protected]
Request System cc
discussion
list(ARSList)" Subject
<[EMAIL PROTECTED] DSO and $OPERATION$
ORG>
10/16/2006 10:11
AM
Please respond to
[EMAIL PROTECTED]
RG
ARS 5.01.02 p?????
Sybase on Solaris
DSO
Have a filter that runs on MODIFY only. However, have found instances
where
the filter is running on a MERGE action. So, I added a Run Process action
to
log to a file when the filter runs and am outputting the following:
$USER$ $SERVER$ $SCHEMA$ $OPERATION$ $Request ID$ $TIMESTAMP$
What I am finding is that the user is Distributed Server and the Operation
is MERGE, however, the filter is set to fire only on Modify.
Any thought on how this could happen?
Thank you.
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
CONFIDENTIALITY NOTICE:
This is a transmission from Kohl's Department Stores, Inc.
and may contain information which is confidential and proprietary.
If you are not the addressee, any disclosure, copying or distribution or use of the contents of this message is expressly prohibited.
If you have received this transmission in error, please destroy it and notify us immediately at 262-703-7000.
CAUTION:
Internet and e-mail communications are Kohl's property and Kohl's reserves the right to retrieve and read any message created, sent and received. Kohl's reserves the right to monitor messages to or from authorized Kohl's Associates at any time
without any further consent.
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
--
Frank Caruso
Specific Integration, Inc.
Senior Remedy Engineer
www.specificintegration.com
703-376-1249 __20060125_______________________This posting was submitted with HTML in it___
