;;; 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

[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.
;