OCS dialed Customer number again when the customer talking to Agent

[sundaraas]

Hi Team,

One of the customer has chaining record ( 2 records) in the callinglist

9779466626 ( Chain_n=0)
9878223311 (Chain_n=1)

9779466626 record was dialed and connected with Agent at 4/9/2013 12:07:49.395 [Connid: 02b302250b9dd27f] but OCS dialed the same number (9779466626) again  at 4/9/2013 12:07:49.863 [Connid: 02b302250b9dd283]
and updated the callinglist as NoAnswer. Since it was updated as NoAnswer and due to NoAnswer Treatment , it is dialed the Chaining number 9878223311 and connected with 2nd agent.

1. There is no duplicate in the calling list.
2. We can able to get the records when the call has been answered by the agent. [We don't have any idea about how many records are dialing this scenario in a day].
3. We are not facing the same problem in the different process campaign.
4. We have run the store procedure to update the value of GenesysField "GSW_Attempt" and userdefinedfield "Lastcallresult" in the calling list while campaign running.
5. I am not able to upload the logs in sggu.com. So, I uploaded the logs in the sendspace.com. Please download the logs from the below link,

http://www.sendspace.com/file/4r95s3

[Kubig]

Try to check your dialing filter for this campaign and treatment configuration (next_chain, next_chain_after)

[cavagnaro]

[quote]4. We have run the store procedure to update the value of GenesysField "GSW_Attempt" and userdefinedfield "Lastcallresult" in the calling list while campaign running.
[/quote]
Not a good idea to modify tables while a campaign is running...records that are already on OCS memory will not be affected. I guess that something modified the records while running and caused this behavior.

[Fra]

[quote author=cavagnaro link=topic=7751.msg33577#msg33577 date=1365601685]
[quote]4. We have run the store procedure to update the value of GenesysField "GSW_Attempt" and userdefinedfield "Lastcallresult" in the calling list while campaign running.
[/quote]
Not a good idea to modify tables while a campaign is running...records that are already on OCS memory will not be affected. I guess that something modified the records while running and caused this behavior.
[/quote]
Totally.
Rule #1 is NEVER EVER mess directly with OCS tables. Any changes to records should be done either via the OCS - Desktop protocol or the Communication DN API.
Try again without running any custom store procedure.

Fra