Re: [INTERFACES] Re: NEW ODBC DRIVER

Поиск
Список
Период
Сортировка
От Byron Nikolaidis
Тема Re: [INTERFACES] Re: NEW ODBC DRIVER
Дата
Msg-id 35574688.C434D15@insightdist.com
обсуждение исходный текст
Ответ на Re: NEW ODBC DRIVER  ("Jose' Soares Da Silva" <sferac@bo.nettuno.it>)
Ответы Re: NEW ODBC DRIVER  ("Olaf Mittelstaedt" <mstaedt@va-sigi.va.fh-ulm.de>)
Список 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 по дате отправления:

Предыдущее
От: "Oliver Mueschke"
Дата:
Сообщение: subscribe
Следующее
От: Felix Morley Finch
Дата:
Сообщение: RE: [INTERFACES] Re: NEW ODBC DRIVER