ODBC, or Open Database Connectivity, is an interface through which an application accesses a data source using a driver. The connection path contains an application, a driver manager, a driver, and a data source. Compatibility depends on the entire path and the identity under which it runs.
A data source name, or DSN, supplies connection configuration. It is a reference used by that path, rather than a guarantee that the intended application can reach the intended database with the required behavior.
Four layers perform different work
The application issues ODBC calls. The driver manager manages access to the appropriate driver. The driver handles requests for its associated data source, including the interaction with the underlying database. The data source holds or supplies the requested data.
A common interface allows applications to use a common family of calls. It does not make every database accept identical SQL, return identical types, or handle a transaction identically. Those properties still need examination when either a driver or the database changes.
An inventory that records only the server and database omits executable dependencies. Driver name, version, architecture, configuration, and deployment location belong beside the consumer that uses them.
Architecture is a connection constraint
On Windows, 32-bit and 64-bit ODBC administration tools expose configuration differently. System DSNs are separated by architecture. User DSNs can appear in both tools even when the listed driver cannot be used by the application inspecting them.
A visible entry therefore provides evidence of configuration, not a completed compatibility test. The application process and the driver it loads need compatible architecture. Installing a driver for another process architecture does not repair the application’s existing path.
These DSN visibility details describe Windows. A Unix deployment requires the corresponding driver-manager and configuration evidence instead of an assumption that Windows registry behavior applies there.
The runtime identity matters
A connection that works for an interactive administrator can fail for a scheduled job. The job may use another profile, resolve a different DSN, lack credentials, or reach a different configuration file.
Discovery should start from the actual consumer: its machine, execution identity, process architecture, and launch mechanism. Windows DSN enumeration can help, but a single enumeration does not cover every user profile, file DSN, or connection string embedded in application configuration.
Secret references and ownership belong in the inventory. Copying passwords into a connection catalogue creates a separate exposure without demonstrating that the runtime can obtain them correctly.
Test the workload after the handshake
Opening a connection tests an initial path through authentication and configuration. It does not exercise all the queries, parameter bindings, or update patterns used during a business cycle.
A controlled comparison can include non-ASCII text, high-precision decimals, boundary dates, null values, and parameterized queries. These examples should come from the application’s actual semantic requirements. A generic driver test cannot determine whether a rounded amount remains acceptable for that application.
Transaction boundaries and connection loss also deserve explicit cases. If the application loses its connection after submitting an update, recovery must establish whether the update committed before deciding to repeat it.
Change one path deliberately
A driver replacement should record the old and new configurations and compare the same workload under the same execution context. A database replacement adds another variable: SQL and storage behavior can change even when the ODBC interface remains.
Acceptance requires the intended consumer to resolve the intended destination, perform its required reads and writes, and recover according to the agreed business rules. Retaining the previous configuration helps reversal, but returning to it after new writes also requires a data reconciliation decision.