[asterisk-users] only the first ResetCDR works after upgrade to 1.6

[Andrew Witt]

Hello -

I am upgrading from asterisk v1.2 to v1.6 and I am seeing a problem with
recording CDRs using MySQL.  Unlike all of the other postings and web
pages I have found on this issue, my installation successfully stores
the -first- CDR, but nothing after that.

As background info, I will note that I don't use CDRs for billing, but
more in a logging fashion, to record how a given call branches through
the dialplan, the selections the caller makes, info retrieved from other
sources, etc.

The cdr_addon_mysql module loads; I have a working cdr_mysql.conf; MySQL
is running; etc., etc., etc.  The fact that the first time ResetCDR is
called it writes out a CDR shows that all the right pieces are in place,
so it isn't any of the basic installation, set-up and config issues.

By way of debugging, I pulled cdr_addon_mysql.c out of SVN (from
asterisk-addons/branches/1.6.2) and added a bunch of debug assertions
amidst the code that INSERTs the CDR record into the db.  I see in my
asterisk logs and on the asterisk console all of the expected assertions,
between the first "Executing ResetCDR" and the "Inserting a CDR record."

There are further "Executing ResetCDR" lines in the debug output, but
-no- further log lines from cdr_addon_mysql at all.

My dialplan is also stored in MySQL, and the debug output shows that
the connection from asterisk to MySQL remains up and functional, so I'm
fairly certain it is not a dropped MySQL connection.

It looks to me as if ResetCDR simply is not calling mysql_log( ) after
the first time ResetCDR is called.

Is this a known issue?  Has anyone else seen this behavior?  Does anyone
have a solution or at least a work-around?

Also, a number of other subtle but important things changed between v1.2
and v1.6 -- do I need to change my basic CDR logging strategy, too?
Currently, I have what amounts to a subroutine in the dialplan which
calls "Set(CDR(userfield)=...." and then "ResetCDR(w)".  From what I have
read, this approach should still work under v1.6.

Many thanks in advance.  Asterisk rocks, and has served me well and been
very stable as my company's 24x7 payment IVR for nearly four years.  This
single issue is holding up my upgrade from v1.2 to v1.6, and I anticipate
many more solid years on 1.6 once this is resolved.  Thanks again.

-- 
Andrew Witt
Sr. Software Systems Engineer
revol wireless
216-525-1195 phone
216-240-1991 wireless
216-525-1112 fax
andrew.witt at revol.com
www.revol.com

THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL, AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, forwarding, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail or telephone, and delete the original message immediately.