Latest ODBC Driver "unstable"

It looks like the latest build of the PostgreSQL ODBC driver has
problems. I have an application on Windows in .NET that I have been
developing for some time using the ODBC drivers. Until recently I used
the packaged installer to install 7.3.2 version of the driver. This is very
stable with no unexpected problems.

Backend is PostgreSQL 7.4.3 on Fedora Core 2

Recently I installed the latest build (7.5.02) and immediately began to
experience ramdom crashes in my ASP.NET applications and .NET
Windows apps.

Dropping back to the 7.3.2 build all the problems went away. I have
done several tests ONLY changing the ODBC driver and the results are
consistent.

Initially it looks like random buffer overflows/memory scribbling
problems. Occasionally I get error messages from the driver with
random bits of text on the end of the message. In .NET the ODBC
Driver reports errors with a title of "Postgresql %s %s". Either someone
has done something recently with buffer copying or it is the result of
going Unicode-build only.

I am not doing anything with cursors, just straightforward connect,
execute, fetch, disconnect stuff. .NET puts lots of capability calls and
datatype query for resultset calls of course. Looking at ODBC trace
output I see no bad behaviour. The driver just crashes and takes the
program with it sometimes.

I also transfer data from SQLServer to PostgreSQL using DTS and the
postgres ODBC driver. Using build 7.3.2 I get no problems at all. Using
build 7.5.02 I get reports from SQLServer (DTS) like "Critical Error" and
"data exception" at random points during the transfers.

Unfortunately I don't currently have the tools to debug the driver. I will
supply any information that I can, but given that this is Windows, there
ain't a lot.

Given that 8.0 is trying to make it into Windows, an unstable ODBC
driver is going to taint the excellent efforts of the server porting.

Given also that there is no-one to fix these problems it may be better to
revert to a tried and trusted stable version (7.3.2) until this can get
looked into.

Cheers,
Gary.