Callmanager CDR reporting is limited to 100 records

I did find the following as well:

CDR Search by User ExtensionAvailable for CAR administrators. You can search CDRs by user or extension to analyze call details for the first 100 records that satisfy the search criteria. If more than 100 records are returned, the system truncates the results. You can search for calls by using specific extensions for the period that you specify. This helps you trace calls that are placed from specific extensions for diagnostic or informational purposes. All associated records, such as transfer and conference calls, appear together as a logical group. If you do not specify an extension, the system returns the first 100 CDR records that match the date range that you specify.
 
CDR Search by GatewayAvailable for CAR administrators. You can search CDRs by gateways to analyze the call details of calls that are using specific gateways. This method helps you trace issues on calls through specific gateways. If more than 100 records are returned, the system truncates the results.

I will look for any way to change this limit, but most customers seeking to analyze more than 100 calls for a specific user will send the CDR raw data to a Call Accounting system (separate server), where they can organize formal reports, maintain historical information, create statistical comparisons and graphs, etc.

It appears a workaround for the search limit might be to export the dump file and then open up the info in a spreadsheet.  From Cisco documents:
"Export CDR/CMRAvailable for CAR administrators. With this feature, you can export CDR/CMR dump information, for a given date range in the CSV format, to a location that you choose on your computer. You can also view the file size of the dump information and delete CDR/CMR files.

JRSCGI,
I did some research on this and knew most the above, but don't know about a Call Accounting system.  Is the Accounting system youre talking about from Cisco?  
I once found a registry hack on the Internet, to change the limit on the CDR reports, but I was working on another issue with CallManager at the time and didnt save the link.  Ive never been able to find it again.  

I appreciate your responses.

Cisco does not offer their own call accounting system, but there are a wide variety of products on the marketplace with a corresponding wide variety of prices.  The basic engine of a call accounting system is a filter that parses out the CDR record (which comes out of the CM as a text file) into a database.  If all you want is to explore the records, inexpensive systems are available or you can use basic tools to dump the records into a homegrown system.  Most Call Accounting systems take the call records and match to pricing tables, then divide the records into a report format that matches the organizational structure (used for chargeback systems).  You can do a google search and find a wide variety of products, which saves you the time of writing your own communications link and application front end.

I have generally avoided unauthorized tweaks to products, but I would guess it would not be the most complex thing to change - if only Cisco weren't so closed and proprietary.

I actually found an accounting system product from Syn-Apps that works great, but the need doesn't justify the cost.  I've done some SQL scripting to get the information, but I don't trust the result like a more professional or Cisco product.

Unless you are talking about CallManager Express, or CDR/CAR aren't actually installed/enabled, the limit should be 1.5 million.  If it is only keeping 100 records, something is very wrong with your kit.  Where do you see the 100 record limit referenced?

Cisco's own documents state they STORE 1.5 million records but only provide a report up to 100 records at a time when using the stand query.

Thanks JRSCGI.  The 100 limit was in the query.  But I found a "hack" for a registry key that allowed unlimited, but I've never found it on the Internet again.

Do you need pretty reports, or would direct SQL querying be a solution?

The thing I worry most about is the accuracy of the information.

I used this info for a SQL query, and modified it to fit my dates need:
http://www.ipvoicehelp.com/index.php?blogid=1
http://www.flairdata.com/cdr/

Jan 15: SQL Queries for CallManager Administrators.

Cisco has done a lot to make the web interface for CallManager be most of what you need for managing your phone system. But what happens if you want to do something that goes beyond what the web interface can do. For many many years CallManager has relied upon a Microsoft SQL database. That's the good news, there's a lot of tasks you can do by simply tapping directly into those tables instead of using the web page. The bad news? All of the information is spread across many different tables and it's not always clear where to look for the information that you want. The following is a list of some of the useful SQL queries that I have used over the years and that people I know have found helpful.

CDR Lookups

CallManager has built in CDR reporting tools, but sometimes if you're looking for specific information they can be a bit cumbersome and hard to use. These helpful queries are useful for finding the information you are looking for. One tricky thing though, all of the date-time stamps in CallManager are in seconds since 1970. Thankfully there is a tool, located here: http://www.flairdata.com/cdr that will help you convert to and from this timing. Just input the information that you have and then pop the results into one of the queries below. The queries will get more added into them as we go along so hopefully you will be able to see what is here and then be able to manipulate them to make your own custom queries. For all of the following queries, we are using the CDR database and the CallDetailRecord table. Here we go:

Looking up Calls from One Number Placed to Another Number Between Two Date Times

SELECT *
FROM CallDetailRecord
WHERE (callingPartyNumber='2125555555') AND (originalCalledPartyNumber='4444') AND (dateTimeOrigination > 1151758800) AND (dateTimeOrigination < 1153284503)

All we did to look between a date time range was add a less than statement for dateTimeOrigination to the end and now it is searching between July 1 2006 at 8AM and July 18 2006 at 10:48.

But all of the results when converted in a spreadsheet (Excel) were times that turned out to be after 12:00pm, minus a couple (out of hundreds) that were like 11:45 or something close.  Some of the times where after 5:00 but most were between the normal business if before 5:00pm.

The end result is that I dont trust my SQL queries.  Using professional software as I said before were all accurate.

Wow, the code snippet tool totally mangled these.  Let me attach it as a text file.

I'll check this out asap.