Re: Weird DSO Behavior
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: arslist@ARSLIST.ORG 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
Re: Weird DSO Behavior
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 arslist@ARSLIST.ORG Sent by: Action cc Request System discussionSubject 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: arslist@ARSLIST.ORG 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
Weird DSO Behavior
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
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
