Обсуждение: serious trouble with bool and Access

Поиск
Список
Период
Сортировка

serious trouble with bool and Access

От
Markus Wagner
Дата:
Hi,

we're in serious trouble with an application using BOOLs. We have boolean
attributes in a pg table, being represented as checkboxes in Access. Changing
these controls results in an error message "another user has changed the
data", or something like that.

We tried nearly everything. The mailing list archives gave hints to the pg
ODBC driver, the "bools as char" flag and so on. We tried with and without
this flag. Then, without it, the problem seemed to be solved. But we found
that now the data must have been changed several times in different records,
before the problem reappears.

Our current settings are "bools as char" off, "text as longvarchar" off. The
bools are normal BOOL attributes of size 1, as reported by pgaccess. We also
tried to change the table properties for the fields in Access, "display as
checkbox" and so on. We drag the fields from the field list into the form.
But also changing the ODBC-connected tables directly results in the same
error.

Isn't there a unique solution to that? Why are bools that critical?

Thank you very much,

Markus

Re: serious trouble with bool and Access

От
"Henshall, Stuart - WCP"
Дата:
Hi,
    As I've said previously, I took the cowards way out and just use
int2's to represent bools (0=False,-1=True) as this is the way MS Access
does it. You may be able create views which basically reflect the bools
to int2s. You would also need update and insert rules of course. You
would also need to create it as a table first with a primary key, then
create a select rule if you are trying to dynamicaly link tables.
    Alternatively I dredged this up from somewhere (can't remeber who
originally wrote it sorry):
DROP OPERATOR = (bool, int4);
DROP FUNCTION MsAccessBool (bool, int4);
CREATE FUNCTION MsAccessBool (bool, int4) RETURNS BOOL AS '
BEGIN
  IF $1 ISNULL THEN
    RETURN NULL;
  END IF;

  IF $1 IS TRUE THEN
    IF $2 <> 0 THEN
      RETURN TRUE;
    END IF;
  ELSE
    IF $2 = 0 THEN
      RETURN TRUE;
    END IF;
  END IF;
  RETURN FALSE;
END;
' LANGUAGE 'plpgsql';

CREATE OPERATOR = (
  LEFTARG = BOOL,
  RIGHTARG = INT4,
  PROCEDURE = MsAccessBool,
  COMMUTATOR = '=',
  NEGATOR = '<>',
  RESTRICT = EQSEL,
  JOIN = EQJOINSEL
);
Hope this helps,
- Stuart

> -----Original Message-----
> From: Markus Wagner [mailto:wagner@imsd.uni-mainz.de]
> Sent: 18 February 2002 07:00
> To: pgsql-odbc@postgresql.org
> Subject: serious trouble with bool and Access
>
>
> Hi,
>
> we're in serious trouble with an application using BOOLs. We
> have boolean
> attributes in a pg table, being represented as checkboxes in
> Access. Changing
> these controls results in an error message "another user has
> changed the
> data", or something like that.
>
> We tried nearly everything. The mailing list archives gave
> hints to the pg
> ODBC driver, the "bools as char" flag and so on. We tried
> with and without
> this flag. Then, without it, the problem seemed to be solved.
> But we found
> that now the data must have been changed several times in
> different records,
> before the problem reappears.
>
> Our current settings are "bools as char" off, "text as
> longvarchar" off. The
> bools are normal BOOL attributes of size 1, as reported by
> pgaccess. We also
> tried to change the table properties for the fields in
> Access, "display as
> checkbox" and so on. We drag the fields from the field list
> into the form.
> But also changing the ODBC-connected tables directly results
> in the same
> error.
>
> Isn't there a unique solution to that? Why are bools that critical?
>
> Thank you very much,
>
> Markus
>