I installed CUCM 7 (Publisher and Subscriber),whenever i am trying to generate a CDR Report for users by ext its giving me error message
"10021"There are no matching records "
how i can fix this problem.i had UNchecked disable loader from CDR Load what else i need to do to fix this problem.
Attched is the file for CDR Load.
When you unchecked the disable Loader and save the changes, did you then restart the CAR Scheduler in order for the changes to take immediate affect? This noted at the bottom of that specific page.
Have you also enabled the CDR Enabled Flag within CallManager Service Parameters under Advanced?
Hope this helps, pls rate helpful posts.
Just to throw another suggestion in on top of Allan's suggestions:
Make sure you enable the 'CDR Enabled Flag in service parameters for all CCM servers in the cluster - it's a per server setting (not a clusterwide setting).
Please rate helpful posts...
No i did not unchecked it,diable loader was by default unchecked.
As per your above post yes i enabled on both of the servers CDR Enabled Flag but still i am getting the same error message
|10021||There are no matching records|
what should i do now ?
This may be a dumb question, but when you are running the query through CAR what parameters are you using? Is it possible the parameters you are using are invalid and not matching any records? I have seen people get errors similar to yours when the data parameters are wrong. Like querying using today's date when the report engine hasn't processed today's data yet. I believe some/most of these reports lag by a day but that may have changed in the latest releases. (I don't use CAR much anymore. Hence, why my line of questioning may be stupid ).
If you want to check to see if you have records in CAR, you can look at raw CDR data (via the CAR tool) or you can a query like this from the console of your CUCM server:
admin:run sql select count(*) from car:tbl_billing_data
Expanding on this, if you want to see records to/from a particular extensions (e.g. 12345) then you could do something like this:
admin:run sql select count(*) from car:tbl_billing_data where ((originalcalledpartynumber='12345') or (callingpartynumber='12345')
These two queries can be used to confirm that yes there is data in this table for the extension you are testing. If there is no data in the table then I guess you are back to what I assume your original suspicion was. If you do see a count greater than 0, then either the parameters you are providing in CAR are wrong or there is a defect in the CAR web interface.
Please remember to rate helpful responses and identify
I just learnt something - didn't realize you could query the other DBs from the CLI with that dbname: prefix in the query.
Every day is a school day +5
As Bill stated, running a CAR report depends on whether the record have been processed and that the data is available in the table to query in the first instance, remember that this is not real time. In order to query records for today you would have to run the report for tomorrow unless of course you have continuous loading 24/7 enabled, which you have and therefore the data should be available within a few minutes.
What I would like to substaniate is what the maximum date for which records are available, ordinarily I would expect a different error if there was no data available, and as you get an error stating that there are no matches suggests that something was not entered correctly for the query by user/extension for the report?
Could you run the following command to verify the latest date for which data is available and post the output.
run sql select param_value from car:tbl_system_preferences where param_name='CDR_MAX_DATE'
The returned param_value should essentially be today's date as you have continuous loading enabled. Incidentally how are you selecting the extension? Are you typing the extension and hitting add rather than searching by user and adding? If a date is returned other than today, then this would indicate a problem with the repository loader/scheduler, I would therefore try restarting the CDR Scheduler again.