At 01:46 PM 27/04/2005 +0600, you wrote:

>Hi All,
>
>I have users with read only permission on some tables by PUBLIC user.
>GRANT SELECT ON MYTABLE TO PUBLIC;
>
>And I have users with full access to table.
>GRANT ALL ON MYTABLE TO OPERATORS;
>(OPERATORS is a role)
>
>When read-only user execute statement for example "select MYTABLE_ID from
>MYTABLE"
>from any database tool it's ok! Whey allow him to select records from
>the table and just disallow to edit or insert the table.
>
>With IBO I found little problem.
>Wnen statement "select MYTABLE_ID from MYTABLE" assigned to IB_Query
>and EditSQL property present with my custom update statement
>i recieve "no permission for update/write access to column MYTABLE_ID"
>on IB_Query.Open.
>No one try to edit any records.
>When I clear EditSQL before IB_Query.Open it's work fine.
>RequestLive, ReadOnly and PreventEditing properties can't help in this
>case.
>
>I understand I, can leave out what problem by clearing EditSQL property
>in all my IB_Queries when user role is not OPERATORS.
>But I think it isn't best way.
>
>Please consider this strange behavior.

It is not strange behaviour at all. By making a dataset "live" you are
telling the system that the logged-in user is to have the rights to write
to the table. IBO correctly refuses to allow the non-privileged user to
access the set as a live set.

You can safely put your custom EditSQL, InsertSQL and DeleteSQL back. What
you should do instead is to check the user privileges at connect time and
set a flag indicating whether the role has the needed privileges. When the
dataset is created, check this flag and set RequestLive accordingly. If
RequestLive is False, the I/U/D buttons on the UpdateBar will be disabled
automatically.

Helen