I think you'll find you're suffering from other effects of the bug
described here:
http://gborg.postgresql.org/project/psqlodbc/bugs/bugupdate.php?996
The latest snapshot (8.00.0004) contains the fix. It worked for me, as
long as you don't use Memo field types.
If the installer doesn't seem to be removing/repairing/upgrading the
ODBC driver, check the version by inspecting the properties of
psqlodbc.dll in WINNT\system32. Just delete it or overwrite it with the
new version.
Regards
David
Marco Tamanti wrote:
>Before installing version 8.0.1 of postgresql on windows 2000 SP4, I was
>in this situation:
>
>postgresql 7.3.4 on a linux machine
>pgsqlodbc-07_03_0100
>Borland C++Builder 4 updated Pack 1.
>
>After installing postgresql-8.0.1 on the same machine where I run
>C++Builder, I've had a problem with varchar (or character varying):
>When I run applications built with c++builder I get the error
>"<ComponentName>: field '<fieldName>' not found.", where <ComponentName>
>and <fieldName> are appropriate values.
>With Database Explorer, I can see that all the information on the tables
>are correct and that the fields are there.
>If I enter an SQL statement "select * from tablename" the result does
>not contain varchar fields.
>If I do "select fieldname from tablename" where fieldname is a varchar
>field, I get the column with all empty values.
>
>Using pgadmin none of these problems appear. All queries are ok.
>
>
>The same problem appears even if I connect to the old postgres 7.3.4 on
>linux. This, after the installation of the 8.0.1 version.
>I've tried to reinstall Windows 2000, C++Builder (now version 5),
>pgsqlodbc-07_03_0200 and the old database 7.3.4 on linux was perfectly
>responding. After installing postgres 8.0.1 on windows the problem came
>out again.
>
>Even when I remove postgres 8.0.1 the problem persist.
>I suppose there's a problem on odbc driver, but I tried to install it
>again with no result. I tried to reinstall C++Builder and no result
>again.
>
>Anyone with the same problem? Any solution?
>
>I'm using SQL_ASCII coding. Most of testing has been done on a
>varchar(50) field, not null, storage extended.
>
>
