At 03:08 PM 16/01/2006 +0000, you wrote:

>D7, IBO4.5B FB1.5
>
>This is a followup to my prior post regarding table access rights.
>
>Helen pointed out that I should use RequestLive = True and let IBO
>calculate the xxxSQL statements on the fly.
>
>This does work ok, however not when I have specific column access
>set in RDB$PRIVILEGES.
>
>EX: table Contacts has Update rights for various individual fields
>and none for others when the client role is WAREHOUSE.
>
>When logged in as roll = WAREHOUSE I can open the table now and
>browse, but when I try to edit ANY field I get a GDS error
>335544352 "no permission..." error on one of the non-editable fields.
>
>When I look at the SQL monitor the Update statement includes all the
>fields in the table including the ones for which there is no Update
>privilege.
>
>So my assumption is that IBO checks for table access for UPDATE, but
>not for any particular column rights when it creates an xxxSQL
>statement.
>
>I can't see from the monitor how IBO is querying the RDB$PRIVILEGES
>to find the access rights.
>
>If I want individual field access, do I just need to take over the
>xxxSQL statements in the code?

You'll need conditional code that assigns properties according to the
logged-in role. Sorry if I didn't make that clear enough.

IBO doesn't query the privileges table: the exception occurs when the
database engine receives a DML request that is not allowed by
privileges. If it is happening when you put the dataset into an editing
mode, but before you call Post, then check that you are not using
PessimisticLocking!

If you have some roles that are allowed to update some fields but not
others then your conditional code will have to take care of this as
well; and it will also have to apply custom xxxxSQL properties that
exclude the forbidden fields from any update requests.

Helen