Asterisk func_odbc returns empty, errors or delays the call

Classify the first wrong observation

Capture one authorized occurrence with timestamp and timezone, Asterisk branch and package, exact function name, argument count and redacted values, expected result shape, channel identity, dialplan priority, elapsed lookup time, returned value, ODBCROWS or fetch status where applicable, subsequent branch and caller outcome. Preserve the contemporaneous Asterisk and database-owner evidence without copying credentials or sensitive rows.

Classify the symptom as missing function, missing CLI support, unknown connection name, disconnected resource, authentication or network failure, SQL error, escaping failure, zero rows, null or blank field, duplicate rows, opaque multirow identifier, fetch exhaustion, stale data, slow query, connection timeout or wrong dialplan interpretation.

Prove module and connection layers before the query

Confirm the installed package contains and loads res_odbc and func_odbc, then identify the exact func_odbc.conf owner. Match its read handle to the res_odbc.conf section and that section to the system DSN. Use odbc show to preserve configured and connected state, but continue to an approved test of the actual function.

If the connection is down, separate driver and DSN configuration, name resolution, route and firewall, database listener, account authentication, connection capacity and server state. Do not broaden database network access or substitute a more privileged credential merely to make the symptom disappear.

Inspect the generated query without exposing secrets

Compare the loaded function class, minimum argument count, actual ARGn values and the fixed SQL template. Validate identifier format before reviewing quote and backslash handling. On databases where backslashes escape characters, confirm that the installed Asterisk branch includes the advisory fix and that the template applies the documented backslash and single-quote escaping in the required order.

Redact customer data and credentials while retaining placeholders, lengths, character classes and the database error code. Do not paste a fully substituted sensitive query into a ticket, and do not use an unrestricted arbitrary-SQL helper as a production diagnostic shortcut.

Separate zero rows, blank values and query failure

A blank dialplan value can represent no matching row, a null or empty selected field, an execution failure, an assignment problem or a later overwrite. Preserve the function status variables and Asterisk log, then run the same constrained lookup through the approved database-owner path. Confirm schema, column, collation, normalization and data freshness before changing the route.

Define a safe dialplan fallback for each state. A lookup that returns one row does not prove the row is authorized, current or suitable as a destination; validate the returned value before using it to route or originate a call.

Handle multirow state on the creating channel

If the function uses mode=multirow, preserve the returned result identifier, fetch rows only on the channel that created it, test ODBC_FETCH_STATUS after each fetch and finish the result when done. Confirm rowlimit before treating truncation as missing database data.

Do not compare the opaque identifier with the expected first column, move it to a sibling channel or assume a failed fetch means the original SQL failed. Distinguish zero stored rows, exhausted rows, channel ownership, early dialplan exit and missing cleanup.

Measure delay and retest the fallback

Correlate Asterisk timestamps with connection attempt, query execution and database evidence. Distinguish connection timeout from negative-connection cache, pool wait, server execution, lock wait, result transfer and later dialplan work. Query logging and the slow-query warning can help only when their documented conditions are met; the sample notes that current logging covers successful queries.

Correct one evidenced owner, then retest one matching row, zero-row fallback, invalid input and database-unavailable case with an authorized non-emergency call. Confirm caller treatment does not wait indefinitely and credentials and rows remain protected. No host, driver, DSN, module, credential, database, query, result, channel or live call was inspected or tested for this diagnostic.

Branch to transaction evidence when the function mutates data

For a write, use the ODBC mutation diagnostic to distinguish statement execution, row match, active transaction, commit, rollback and retry.

Separate query shape from structured assignment

Use the HASH and ARRAY diagnostic after proving the query result to check key creation, ARRAY cardinality and the consuming channel.

Switch traces when the dependency is HTTP

If the dialplan uses CURL instead of func_odbc, follow the CURL diagnostic through destination, option, transport, HTTP and parsing boundaries.