Thanks Helen,
I do understand that, but I need to know what properties in TIB_Query I need
to attend to.
I had (obviously) the misconception, that I would just need to set the
Readonly property to false to make them not attempt to update. But this
appears not to be the case. There are other properties I need to set to make
them truly read-only, or rather to stop them doing things which would cause
exception at the server when the role does not have the permission normally
granted.
Do I have to delete the UpdateSQL from queries to force them to not prepare
the UpdateSQL? This seems like a lot of internal machinations to achieve
this.
Alan

-----Original Message-----
From: Helen Borrie [mailto:helebor@...]
Sent: Saturday, 5 April 2003 11:33 AM
To: IBObjects@yahoogroups.com
Subject: RE: [IBO] Roles & Permissions


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




___________________________________________________________________________
IB Objects - direct, complete, custom connectivity to Firebird or InterBase
without the need for BDE, ODBC or any other layer.
___________________________________________________________________________
http://www.ibobjects.com - your IBO community resource for Tech Info papers,
keyword-searchable FAQ, community code contributions and more !

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/