At 01:45 AM 5/04/2003 +1000, you wrote:

>Norman,
>it may well work, if the role in fact, still has grant all permissions. but
>if the role does not have all permissions, IBO appears to try to prepare
>editable statements.

....

>I don't quite undestand this

If you want your *app* to behave one way for a role with one set of
permissions and another for a role with a different set, just code this
into your app. I generally have a property that can be seen
application-wide, that is set at login. If it is just a "do/don't do"
situation, I hard-code the behaviour according to the property. With more
roles, you probably need to define a set of constants and test them during
your FormCreates. At that point, you can set up the tables/datasets/column
objects' attributes accordingly.

You have more work to do with the TDataset comps than with the native IBO,
because the TDatasource controls have more "attitude" than the native
controls. The latter will just behave according to the data attributes,
whereas the former tend to have behaviours that are allowed regardless of
the data attributes.

>It kind of defeats setting permissions on the server at
>all if all the protection is set on the client. And if this users role still
>needs all the server permissions, what would stop them logging on as the
>other role?

All that the server permissions do is guard the gates. The server has no
idea at all of what is going on in the client until the client submits a
request. It also does not deliver to the client a set of rules pert. to
the privileges. That's the way client/server is. It is completely
context-free with respect to any client application. Its job is to apply
the rules when presented with a request...

Helen