Re: [INTERFACES] Re: NEW ODBC DRIVER - Mailing list pgsql-interfaces

From Byron Nikolaidis
Subject Re: [INTERFACES] Re: NEW ODBC DRIVER
Date
Msg-id 35574688.C434D15@insightdist.com
Whole thread Raw
In response to Re: NEW ODBC DRIVER  ("Jose' Soares Da Silva" <sferac@bo.nettuno.it>)
Responses Re: NEW ODBC DRIVER  ("Olaf Mittelstaedt" <mstaedt@va-sigi.va.fh-ulm.de>)
List pgsql-interfaces
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



pgsql-interfaces by date:

Previous
From: "Oliver Mueschke"
Date:
Subject: subscribe
Next
From: Felix Morley Finch
Date:
Subject: RE: [INTERFACES] Re: NEW ODBC DRIVER