Message-Id: <35574688.C434D15@insightdist.com>
Date: Mon, 11 May 1998 14:42:16 -0400
From: Byron Nikolaidis <byronn@insightdist.com>
Mime-Version: 1.0
To: Sbragion Denis <infotecn@tin.it>
Cc: "Jose' Soares Da Silva" <sferac@bo.nettuno.it>,
	interfaces postgres <pgsql-interfaces@postgreSQL.org>,
	"Jackson, DeJuan" <djackson@cpsgroup.com>, Hannu Krosing <hannu@trust.ee>
Subject: Re: [INTERFACES] Re: NEW ODBC DRIVER
References: <Pine.LNX.3.96.980511131010.1267A-100000@proxy.bazzanese.com>
	<3.0.5.32.19980511181524.007efe40@MBox.InfoTecna.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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