Message-Id: <199805120751.JAA24248@gate.va.fh-ulm.de>
From: "Olaf Mittelstaedt" <mstaedt@va-sigi.va.fh-ulm.de>
Organization: Verwaltung FH Ulm
To: interfaces postgres <pgsql-interfaces@postgresql.org>
Date: Tue, 12 May 1998 09:50:22 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: NEW ODBC DRIVER
Priority: normal
In-reply-to: <35574688.C434D15@insightdist.com>

> > 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.
> >
> 
> 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?

When migrating tables from Access 2.0 to an SQL Server (Informix,
Interbase or PostgreSQL) I'm using INT4 to simulate boolean values
(0=False, -1=True), all Access queries using boolean columns will
work as before with native Access tables:

"... WHERE (b=True);"     selects all rows with column b == -1
"... WHERE (b=False);"    selects all rows with column b == 0
"... WHERE (b is Null);"  selects all rows with column b == NULL

Of course you can't issue queries like "...where (b = true);" on the 
UNIX side.

Regards,
Olaf
--
Olaf Mittelstaedt - IuK - mittelstaedt@fh-ulm.de
Fachhochschule Ulm  Prittwitzstr. 10   89075 Ulm
Tel.: +49 (0)731-502-8220             Fax: -8270

 Tertium non datur.