Re: ms-access and booleans ?

Jeff Eckermann wrote:

>--- Andreas <maps(dot)on(at)gmx(dot)net> wrote:
>
>
>>I Access I get an Error:
>>ODBC-Call failed.
>>Error: Operator doesn't exist: boolean = integer
>>(#7)
>>
>>In the System-DSN I have
>>Bool as Char : NO
>>True is -1 : YES
>>
>>
>
>You should have success by playing with these
>settings. I use different settings, but that is a
>historical matter. I believe that the ODBC driver
>handling of booleans for MS Access has been optimized
>somewhat in recent releases. Probably just setting
>"bool as char" to true will do it. But I admit that I
>haven't played with these lately, not wanting to mess
>up a working setup.
>
>

No way :(
The problem lies in the way a SELECT is handled by Access.

I have a test table with a bool-column called "bol".

Access generates :
SELECT test1.*
FROM test1
WHERE (((test1.bol)=True));

Trying this Access throws an error which says there is no comparison
function between boolean and integer.

In contrast pgAdmin as well as psql run the same query without complaints.
Both show the bool-column as t or f.
Access would display 0 / -1.

Interestingly I can enter TRUE or FALSE into the table view of this
table within Access.
TRUE gets translated to -1 and FALSE to 0.
Even 1 gets translated to -1.

But no way I could use the bool-column in an Access query as criterium,
if not "bool as char" is set.
Then I can query bol = "t"
On the other hand "bool as char" breaks the Access check boxes.
Initially they show the bool-values correctly but if I try to set a
checkbox to TRUE I get an error that the value was too big for the
column. I guess "-1" doesn't fit into PG's BOOLEAN which is CHAR(1) as
far as I know.

Live s*cks I tell ya. =8-}