No fixes here, but what it sounds like is that Access is using it's own
BOOL type to represent the BOOL in PostgreSQL. Access' BOOL type can't
be null, it can only be true or false, y or n, -1 or 0 depending on how
you want it displayed. So, it's translating NULL's into it's default of
false.
-DEJ
> -----Original Message-----
> From: Byron Nikolaidis [SMTP:byronn@insightdist.com]
> Sent: Monday, May 11, 1998 1:42 PM
> To: Sbragion Denis
> Cc: Jose' Soares Da Silva; interfaces postgres; Jackson, DeJuan;
> Hannu Krosing
> Subject: Re: [INTERFACES] Re: NEW ODBC DRIVER
>
> Sbragion Denis wrote:
>
> > Hello,
> >
> > At 08.35 11/05/98 -0400, Byron Nikolaidis wrote:
> > >As for the BOOL problem, I tried to return it as a SQL_BOOL, but
> Access
> > >displayed it as 0=FALSE, and (-1)=TRUE. Why does TRUE translate to
> a -1, I
> > >have no idea. But for that reason, I chose to make it a character
> type
> > >instead.
> >
> > This is an MS brain damage implementation of Booleans. It is used
> this way
> > starting from MS Access 1.0 up to VB 5.0. I don't know why MS
> decided to
> > use this convention in the early MS Access 1.0 age but for
> compatibility
> > reason they had to retain it up to the most recent version of their
> > development programs.
> >
> >
>
> OK,
>
> I'm gonna make it an option. But, as I mentioned before, there are
> some
> weirdnesses with Access. Here's another weird thing with the way it
> handles
> NULL SQL_BIT columns.
>
> If I have my Postgres bool column, and it contains a NULL, Access
> automatically
> displays it as "0". Then if I try to update the record, it uses the
> "0" in the
> where clause. Well guess what, no records are updated because the "0"
> doesn't
> match the NULL in the record, and you get this ugly message about a
> user
> conflict!
>
> When BOOLS are handled as character data, this doesnt happen of
> course.
>
> Anybody got any ideas about this?
>
> Byron
>
