Hi Farah,
 
To make sure I understand your question correctly, you want to log how many times a caller has dialled your IVR script and if it exceeds 10 then you'll take an action to restrict the service?  Also assuming you have an ICM based system and not CVP standalone or UCCX IVR.
 
Assuming above is correct you have a few ways to do it, here's one:
 
Have a DTS package running on SQL that counts unique CLIs, if it finds more than 10 you populate a custom table called tblBlock with the CLI
 
Each time the call hits the script, you use a DBLookup node to interrogate the tblBlock table
If it matches then restrict
If not then carry on.
 
 
Happy to take a look at your DTS and SQL if you struggle with this bit.
 
 
Best Regards
MT
 
 
Mark Tindal
Engineering Manager
JAMIP
 
 
 
 
 

Okay, so the DTS and the SQL code are the bits that do the couting.  Here's a step by step guide:
 
 
Create SQL code to populate a new table with all of the ANI/CLI that have called 10 times or more (pseudo code below):
 
UPDATE TABLE (TBLRESTRICT)
COUNT OF ANI SELECT FROM ROUTECALLDETAIL
GREATER THAN 10 COUNT
 
 
Create a new DTS package that runs the above code on a schedule every 15 minutes.
 
You now have a table of ANIs that have called more than 10 times
 
In your ICM script, you do a DBLOOKUP of your current ANI and if it matches one in the list (True/False) then perform whatever action in the script.
 
 
I know this is probably just as confusing but hope you get it working.
 
 
Regards
MT
 
 
Mark Tindal
Engineering Manager
JAMIP
 
 

The ROUTE_CALL_DETAIL table gets updated automatically for each call so if you run your query every 15 minutes, it'll update your custom table using the latest data.
 
 
Regards
MT

Marvelous Thanks Mark......

 
 
Hi Farhan, very pleased to hear you got it working, glad to be of help.
 
 
 
 
 
 
Mark Tindal
Engineering Manager
JAMIP (Kcom)

Hmm, an interesting issue but I'm not sure I'd be able to recommend a fix without playing around with it.  If it help (and you may already know this), tables Route_Call_DetailTmp1 and Route_Call_DetailTmp2 are written to first and the Route_Call_Detail view is then updated.  Perhaps you could use a trigger off the view instead, not sure if that would work.
 
Also check the DBWORKER process on the CallLogger at FFFF tracing levels to see if it gives you any clues.
 
 
Good luck
MT
 
 
 
Mark Tindal
Engineering Manager
JAMIP