At 11:26 AM 16/01/2006 +0000, you wrote:

>D7 IBO4.5B FB1.5
>
>I'm getting ready to deploy some new software and have a question
>about table access rights in TIB_Query components (and related
>components like TIB_Cursor).
>
>Say I have a "CUSTOMER" table with the following setup:
>
>SQL: Select * from CUSTOMER order by NAME
>EditSQL: Update CUSTOMER ...
>InsertSQL: Insert into CUSTOMER ...
>DeleteSQL: Delete from CUSTOMER...
>
>If I log into the DB as a user who is allowed Edit, Insert and
>Delete rights there is no problem. If the user does not have rights
>I get a GDS error 335544352 "no permission to update/write". I think
>IBO is preparing the EditSQL and others which triggers this error.
>
>I tried to set the TIB_Query with PreventEditing = True etc. and
>even setting ReadOnly = True, but neither stopped IBO from preparing
>the statements.
>
>If I delete the EditSQL etc. statement before opening the table
>there is no problem since there is nothing to prepare.

Therein lies your problem. No dataset is "live" unless you make it so. If
you set RequestLive to true (it's not the default) then IBO constructs your
xxxSQL statements for you. If you create custom SQL for your dataset then
you make it unconditionally updatable. If the user doesn't have the
privileges, you get the error.

>Is this what I have to do, or is there a better way to manage user
>access?

If you need to have updatable sets for some users and non-updatable ones
for others, then roles can be very handy. Package up privileges into roles
and then assign only roles to users (no user-bound privs at all).

The role will then be required for login and you will have it available for
conditioning what you do with your datasets. If you restrict your use of
custom SQL to only those ops for which the xxxSQL statements can't be
calculated, e.g. joined or unioned sets, selectable SPs, then you'll make
everything so much easier, since the only conditional thing you'll have to
be concerned about is RequestLive!

Helen