;;; odbc setup file

; ENV is a global set of environmental variables that will get set.
; Note that all environmental variables can be seen by all connections,
; so you can't have different values for different connections.
[ENV]
;INFORMIXSERVER => my_special_database
;INFORMIXDIR => /opt/informix
;ORACLE_HOME => /home/oracle

; All other sections are arbitrary names for database connections.

;
; The context name is what will be used in other configuration files, such
; as extconfig.conf and func_odbc.conf, to reference this connection.
[asterisk]
;
; Permit disabling sections without needing to comment them out.
; If not specified, it is assumed the section is enabled.
enabled => no
;
; This value should match an entry in /etc/odbc.ini
; (or /usr/local/etc/odbc.ini, on FreeBSD and similar systems).
dsn => asterisk
;
; Username for connecting to the database.  The user defaults to the context name if unspecified.
;username => myuser
;
; Password for authenticating the user to the database.  The default
; password is blank.
;password => mypass
;
; Build a connection at startup?
pre-connect => yes
;
; What should we execute to ensure that our connection is still alive?  The
; statement should return a non-zero value in the first field of its first
; record.  The default is "select 1".
;sanitysql => select 1
;
; The maximum number of connections to have open at any given time.
; This defaults to 1 and it is highly recommended to only set this higher
; if using a version of UnixODBC greater than 2.3.1.
;max_connections => 20
;
; When the channel is destroyed, should any uncommitted open transactions
; automatically be committed?
;forcecommit => no
;
; How should we perceive data in other transactions within the database?
; Possible values are read_uncommitted, read_committed, repeatable_read,
; and serializable.  The default is read_committed.
;isolation => repeatable_read
;
; Is the backslash a native escape character?  The default is yes, but for
; MS SQL Server, the answer is no.
;backslash_is_escape => yes
;
; How long (in seconds) should we attempt to connect before considering the
; connection dead?  The default is 10 seconds, but you may wish to reduce it,
; to increase responsiveness.
;connect_timeout => 10
;
; When a connection fails, how long (in seconds) should we cache that
; information before we attempt another connection?  This increases
; responsiveness, when a database resource is not working.
;negative_connection_cache => 300
;
; Enable query logging. This keeps track of the number of prepared queries
; and executed queries as well as the query that has taken the longest to
; execute. This can be useful for determining the latency with a database.
; The data can be viewed using the "odbc show" CLI command.
; Note that only successful queries are logged currently.
;logging => yes
;
; Slow query limit. If a query exceeds the given amount of time (in milliseconds)
; when executing then a WARNING message will be output to indicate that there
; may be a problem. Note that logging must be set to "yes" for this to occur. By
; default this is set to 5000 milliseconds (or 5 seconds). If you would like to
; disable the WARNING message it can be set to "0".
;slow_query_limit => 5000
;
; Set the type of connection cache.  Historically res_odbc used a stack, resulting in
; a single connection being re-used frequently, whilst other connections could end up
; dying.  Using a queue or round-robin strategy results in all connections being re-used
; and kept alive.
; Each strategy has pros and cons as debated on
; https://github.com/asterisk/asterisk/pull/1026.  In summary, the stack results
; in a small number of connections remaining "hot" on the database side which
; could argumentatively maintain higher performance at the cost of longer-idle
; connections being timed out from the DB side, resulting in a short CPU spike on
; asterisk side when that "dead tail" is attempted to be used.  The queue on the
; other hand will keep the load more spread over connections, resulting in them
; being kept active, avoiding the CPU spike on asterisk side to a much larger
; degree, at the cost of potentially keeping more connections (which could
; potentially be purged DB side) active.
; The default remains a stack to be backwards compatible, setting this value to
; any of rr, roundrobin or queue will result in a round-robin queue being used.
;cache_type => roundrobin
;
; Limit the number of connections to cache.  This is separate from
; max_connections which is the total number of connections that open, whereas
; this value specifies how many idle connections will be stored in the connection
; cache.  On extremely spiky loads this could be useful to limit the overall
; number of connections that's kept open when the spike comes down.  The default
; is to not limit the cache size (thus effectively limit to max_connections).
; When a returned connection would result in the cache size being exceeded, the
; longest idle connection in the cache shall be dropped.
; Setting this to zero will effectively disable the connection cache, setting to -1
; will set this to "infinite" (default).
;cache_size => 10

[mysql2]
enabled => no
dsn => MySQL-asterisk
username => myuser
password => mypass
pre-connect => yes

; Certain servers, such as MS SQL Server and Sybase use the TDS protocol, which
; limits the number of active queries per connection to 1.
[sqlserver]
enabled => no
dsn => mickeysoft
max_connections => 5
username => oscar
password => thegrouch
pre-connect => yes
sanitysql => select count(*) from systables
; forcecommit => no            ; Default to committing uncommitted transactions?
                               ; Note:  this is NOT the autocommit flag; this
                               ; determines the end result of transactions which
                               ; are not explicitly committed or rolled back.  By
                               ; default, such transactions are rolled back if the
                               ; call ends without an explicit commit.
; isolation => read_committed  ; Isolation level; supported levels are:
                               ; read_uncommitted, read_committed, repeatable_read,
                               ; serializable.  Note that not all databases support
                               ; all isolation levels (e.g. Postgres only supports
                               ; repeatable_read and serializable).  See database
                               ; documentation for further information.
;
; Many databases have a default of '\' to escape special characters.  MS SQL
; Server does not.
backslash_is_escape => no

;
; If you are having problems with concurrency, please read this note from the
; mailing lists, regarding UnixODBC:
;
; http://lists.digium.com/pipermail/asterisk-dev/2009-February/036539.html
;
; In summary, try setting "Threading=2" in the relevant section within your
; odbcinst.ini.
;
