Subject | Re: [IBO] table access rights |
---|---|
Author | Rick Roen |
Post date | 2006-01-16T12:40:56Z |
Thank you Helen,
RequestLive is the key I was looking for. I already bundle
privileges into rolls, I just didn't understand the purpose of
RequestLive.
If I understand correctly, I set RequestLive to true, omit the
xxxSQL statements and then IBO will calculate them as required or
throw an exception when the user tries to update/insert/delete.
Rick
RequestLive is the key I was looking for. I already bundle
privileges into rolls, I just didn't understand the purpose of
RequestLive.
If I understand correctly, I set RequestLive to true, omit the
xxxSQL statements and then IBO will calculate them as required or
throw an exception when the user tries to update/insert/delete.
Rick
> >it so. If
> >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
> you set RequestLive to true (it's not the default) then IBOconstructs your
> xxxSQL statements for you. If you create custom SQL for yourdataset then
> you make it unconditionally updatable. If the user doesn't havethe
> privileges, you get the error.updatable ones
>
> >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-
> for others, then roles can be very handy. Package up privilegesinto roles
> and then assign only roles to users (no user-bound privs at all).available for
>
> The role will then be required for login and you will have it
> conditioning what you do with your datasets. If you restrictyour use of
> custom SQL to only those ops for which the xxxSQL statements can'tbe
> calculated, e.g. joined or unioned sets, selectable SPs, thenyou'll make
> everything so much easier, since the only conditional thing you'llhave to
> be concerned about is RequestLive!
>
> Helen
>