Perhaps what he could do is create an event for the OnGetCanEdit (spelling?)
and then return false if the username is PUBLIC. I believe this will
prevent it from investigating any further to see if there is the ability to
edit and it should avoid attempting to prepare the edit statement. I wish
the server would defer raising an exception until they actually attempted to
execute an update, but such is life.

I could also make IBO trap the permission exception and simple flag the
dataset as read only and silently move on. Seems to me we have discussed
this at length in the past and I remained in favor of seeing the exception
because at least the developer knows what is going on and they can quickly
do something about it.

Jason Wharton

> -----Original Message-----
> From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]On
> Behalf Of Helen Borrie
> Sent: Wednesday, April 27, 2005 1:28 AM
> To: IBObjects@yahoogroups.com
> Subject: Re: [IBO] problem with permissions
>
>
>
> 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