The Excel VBA code was using ADODB.Connection and setting CursorLocation = adUseClient . The PostgreSQL 32-bit ODBC driver, version 9.3+ on Windows 7, had a known but rarely documented bug: when adUseClient was set before opening the connection, the driver failed to negotiate the bytea type mapping correctly with the 32-bit PostgreSQL client library — especially if any column in the queried table was type bytea (even if not selected). The driver would throw a generic -2147467259 instead of a meaningful error.
I opened the ( C:\Windows\System32\odbcad32.exe ) — no DSN listed. Opened the 32-bit version ( C:\Windows\SysWOW64\odbcad32.exe ) — the DSN was there, but it was marked as using PostgreSQL ANSI (no x64). So far so good. postgresql odbc driver windows 7 32 bit
But the connection failed even with the 32-bit driver. I ran psql from the same machine — worked perfectly. Firewall, network, credentials — all fine. The Excel VBA code was using ADODB
For five years, it worked perfectly. Then one Monday, the chart stopped updating. I opened the ( C:\Windows\System32\odbcad32
Here’s a solid, realistic troubleshooting story based on a genuine pain point with the PostgreSQL ODBC driver on Windows 7 32-bit. The Ghost in the 32-Bit Pipeline
It was 2018, and I was maintaining a legacy production line reporting system for a mid-sized manufacturing plant. The core database was PostgreSQL 9.6 running on a Linux server. The front-end was a vintage Windows 7 Professional 32-bit machine in the quality control lab. On this machine ran an ancient Excel 2010 VBA macro that pulled defect data every 15 minutes, generated charts, and printed them to a network label printer.
The VBA macro threw error -2147467259 (Unspecified error) at the conn.Open line. The data source name (DSN) was configured in User DSN using the PostgreSQL ANSI(x64) driver. Except… Windows 7 32-bit doesn’t have an x64 driver. That was my first clue something was very wrong.