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