<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <blockquote cite="mid:553C4BAC.9040601@gmail.com" type="cite">
      <blockquote type="cite">
        <pre wrap="">
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)
</pre>
      </blockquote>
      <pre wrap="">
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 ...

</pre>
    </blockquote>
    <br>
    Or define your table with and independent primary key that gets
    added automatically:<br>
    <br>
    <tt>mysql> describe cdr;</tt><tt><br>
    </tt><tt>+------------------+--------------+------+-----+---------------------+----------------+</tt><tt><br>
    </tt><tt>| Field            | Type         | Null | Key |
      Default             | Extra          |</tt><tt><br>
    </tt><tt>+------------------+--------------+------+-----+---------------------+----------------+</tt><tt><br>
    </tt><b><font color="#3333ff"><tt>| id               | int(11)     
          | NO   | PRI | NULL                | auto_increment |</tt></font></b><tt><br>
    </tt><tt>| clid             | varchar(80)  | NO   |    
      |                     |                |</tt><tt><br>
    </tt><tt>| src              | varchar(80)  | NO   | MUL
      |                     |                |</tt><tt><br>
    </tt><tt>| dst              | varchar(80)  | NO   |    
      |                     |                |</tt><tt><br>
    </tt><tt>...</tt><tt><br>
    </tt><tt>| lastapp          | varchar(80)  | NO   |    
      |                     |                |</tt><tt><br>
    </tt><tt>| lastdata         | varchar(80)  | NO   |    
      |                     |                |</tt><tt><br>
    </tt><tt>| duration         | int(11)      | NO   |     |
      0                   |                |</tt><tt><br>
    </tt><tt>| billsec          | int(11)      | NO   |     |
      0                   |                |</tt><tt><br>
    </tt><tt>| disposition      | varchar(45)  | NO   |    
      |                     |                |</tt><tt><br>
    </tt><tt>| start            | datetime     | NO   | MUL | 0000-00-00
      00:00:00 |                |</tt><tt><br>
    </tt><tt>| answer           | datetime     | NO   |     | 0000-00-00
      00:00:00 |                |</tt><tt><br>
    </tt><tt>| end              | datetime     | NO   |     | 0000-00-00
      00:00:00 |                |</tt><tt><br>
    </tt><tt>| uniqueid         | varchar(45)  | NO   |    
      |                     |                |</tt><tt><br>
    </tt><tt>...</tt><br>
    <br>
    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.<br>
    <br>
    jg<br>
    <br>
    <br>
  </body>
</html>