At 27.04.2005 15:21, you wrote:

> At 02:54 PM 27/04/2005 +0600, you wrote:

>>I wrote:
>>"RequestLive,

> RequestLive needs to be set to False. Now that I come to think of the
> logic behind RequestLive, it's not considered at all when you have custom
> XXXSQL. That means you DO have to apply the XXXSQL properties
> conditionally, so as to eliminate the chance of their presence overriding
> RequestLive false.

> Another alternative is not to make the dataset updatable at all, but to
> implement independent methods (use TIB_DSQL components) for the write
> operations and make them available conditionally in your code.

>>ReadOnly and PreventEditing properties can't help in this case."

> No, because they are client-side properties only.

>>RequestLive is False
>>ReadOnly is True
>>PreventEditing is True
>>Any values combination all of them gives error, if assigned EditSQL and user
>>don't has permission.
>>What's the problem!

> Just get your designing hat on and work out the simplest formula to cater
> for the conditions that you want to cover.


>>Anyway, let suppose what user has permission to delete records
>>but hasn't permission to edit them.
>>RequestLive I MUST set to True.

> No. In that case, you would need to separate the Delete operation from the
> dataset, by placing the DML for the Delete operation in its own DSQL object
> and making it an independent method.

>>Why I get "no permission for update/write access to column ......"
>>error when I even don't dare to edit something.

> Because you have created a conflict situation between the user permissions
> and the dataset. The more complicated your conditions, the more things you
> will have to take care of. There is no magic bullet here. In short, if you
> have to manage conditional permissions in your applications, you have write
> conditional code to handle them.

> If you have a fairly simple situation where one role can do anything, while
> another role can only read, then consider conditionally setting the
> transaction read-only.

> Under some more complex conditions, you could make your own "magic bullet",
> by intercepting the permissions exceptions and handling them, by simply
> cancelling the operation and delivering a user-friendly message to the
> status bar.

> Helen

I cope with my task.
As say Alan "IBO tries to prepare the statements even when requestlive
of false".
For a while I choose easyest way - EditSQL.Clear for some Queries, depending of
role.
All works fine.

Many thanks,
Ramil