[asterisk-users] Error writing CDR

[jg]

>> Hi All
>>
>> I have dozens of these messages on CLI complaining about database
>> connection and error writing CDR to disk.
>>
>> The curious thing is I can find them all inside the database. I
>> "selected" them using uniqueid and manually compared each column
>> with the cdr_adaptive_odbc.c error line.
>>
>> "mysqlcheck -a -e -v DBase"  and "mysqlcheck -c -e -v DBase" both
>> returned OK for all tables.
>>
>> Environment is: in production Asterisk 11.7.0~dfsg-1ubuntu1 Ubuntu
>> 14.04.1 LTS
>>
>> Any thoughts?
>>
>> Thanx
>>
>> Ethy
>>
>> [Apr 25 10:56:56] WARNING[19013][C-000002cb]: res_odbc.c:645
>> ast_odbc_prepare_and_execute: SQL Execute returned an error -1:
>> 23000: [MySQL][ODBC 5.1
>> Driver][mysqld-5.5.40-0ubuntu0.14.04.1-log]Duplicate entry
>> '0000-00-00 00:00:00-1234-CLIENT_ID' for key 'PRIMARY' (133)
> Hi Ethy,
>
> why date and time are empty?
>
> At least date is used as a unique key and a unique key has to be
> unique. In other words, the same key can not exist twice like in your
> case.
>
> Check why there is no date and time anymore ...
>

Or define your table with and independent primary key that gets added automatically:

mysql> describe cdr;
+------------------+--------------+------+-----+---------------------+----------------+
| Field            | Type         | Null | Key | Default             | Extra          |
+------------------+--------------+------+-----+---------------------+----------------+
*| id               | int(11) | NO   | PRI | NULL                | auto_increment |*
| clid             | varchar(80)  | NO   | |                     |                |
| src              | varchar(80)  | NO   | MUL |                     |                |
| dst              | varchar(80)  | NO   | |                     |                |
...
| lastapp          | varchar(80)  | NO   | |                     |                |
| lastdata         | varchar(80)  | NO   | |                     |                |
| duration         | int(11)      | NO   |     | 0                   |                |
| billsec          | int(11)      | NO   |     | 0                   |                |
| disposition      | varchar(45)  | NO   | |                     |                |
| start            | datetime     | NO   | MUL | 0000-00-00 00:00:00 |                |
| answer           | datetime     | NO   |     | 0000-00-00 00:00:00 |                |
| end              | datetime     | NO   |     | 0000-00-00 00:00:00 |                |
| uniqueid         | varchar(45)  | NO   | |                     |                |
...

Just in case you get bogus records with offending primary keys due to some other problem, you 
would still have valid data base entries and you would be able to look at the pattern.

jg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20150426/a3d991a7/attachment.html>