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
|
Список | 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 по дате отправления: