[asterisk-bugs] [JIRA] (ASTERISK-30023) cdr_adaptive_odbc does not support DATETIME database columns

[Gregory Massel (JIRA)]

Gregory Massel created ASTERISK-30023:
-----------------------------------------

             Summary: cdr_adaptive_odbc does not support DATETIME database columns
                 Key: ASTERISK-30023
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30023
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: CDR/cdr_adaptive_odbc
    Affects Versions: 18.11.1
         Environment: Ubuntu 18.04 LTS, Ubuntu 20.04 LTS, Asterisk 18.10.1, Asterisk 18.11.2, MySQL ODBC connector 8.0.28.
            Reporter: Gregory Massel


When configuring cdr_adaptive_odbc with recent and/or latest versions of the MySQL ODBC connector and UnixODBC, and MySQL 8 (wasn't an issue on v5.7 with older connectors), cdr_adaptive_odbc no longer supports the 'start' column being a DATETIME column.

It will log:
WARNING[1925399]: cdr_adaptive_odbc.c:731 odbc_log: Column type 9 (field 'asterisk-cdr-connector:cdr:start') is unsupported at this time.

The simple way to fix this from the database side is to alter the column from a DATETIME to a TIMESTAMP type. However, this is not immediately obvious to most and, there is no good reason why cdr_adaptive_odbc shouldn't support a DATETIME column type.

To support DATETIME columns properly requires just a single additional line of code:

*** cdr/cdr_adaptive_odbc.c~    2022-04-14 23:53:34.000000000 +0200
--- cdr/cdr_adaptive_odbc.c     2022-04-20 05:00:08.956054103 +0200
***************
*** 564,569 ****
--- 564,570 ----
                                        break;
                                case SQL_TYPE_TIMESTAMP:
                                case SQL_TIMESTAMP:
+                               case SQL_DATETIME:
                                        if (ast_strlen_zero(colptr)) {
                                                continue;
                                        } else {




--
This message was sent by Atlassian JIRA
(v6.2#6252)