At 03:01 PM 5/04/2003 +1000, you wrote:

>Thanks Helen,
>I do understand that, but I need to know what properties in TIB_Query I need
>to attend to.

It all depends on what you want to achieve...

Cycle through all of your datasets and set RequestLive False on the simple
ones (those that you don't have custom SQL for). This will prevent the
user from putting any of these dataset into edit, insert or delete at all.

For those that have custom SQL, and for any button-driven DML, intercept
whatever event causes a dataset's mode to change to anything but dssSearch
or dssBrowse and call a procedure that enforces one of these states. For
example, for a scrollable dataset you can jump into the AfterScroll event,
call inherited, and then set the dataset state to what you want. As for DML
queries, just don't even let them be prepared.

You can call SysUtils.Abort on anything.

>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.

It depends what you set to ReadOnly. You can make all of the transactions
ReadOnly and this will propagate to any statements in the transaction. You
can make the datasets ReadOnly, causing an error to be thrown if the user
tries to edit, insert or delete anything. You can pick up the error and
silence it by calling SysUtils.Abort. You can achieve the same by setting
the datasources read-only, and you shouldn't get the exceptions then,
either. You can set specific columns to ReadOnly with various extensions
like NOEDIT and NOSEARCH if that's what you need. The flakiest thing to do
is to set the controls to ReadOnly and do nothing about the read-only-ness
of the underlying data. The rest is a matter of deciding how you want to
implement the read-only interface.

>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.

There isn't some magic bullet that will make your database aware of which
user or role logged in, absent a client request. If your application lets
through operations that the role or user doesn't have privileges for, there
will be a privileges exception. At the ugliest level, you could just catch
privilieges exceptions in the OnError events and "eat" them with
SysUtils.Abort. But it's really much friendlier to prevent unprivileged
operations from being requested at all.

>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.

You could if you wanted to. It's very simple: you could just cycle
through all the TIB_Dataset objects and set their custom SQL properties to
Nil. You have a lot of choices. You don't have to do them all. Just do
what you need to achieve the effect you want.

Helen