Jason,

> > maybe he expects to get an error message when the user tries to update,
> > not before. This way, he can deploy a single application and rely on
> > GRANT/REVOKE only to customize the access.
>
> That is essentially how it works except that I consider it as they have
> tried when they access the CanInsert, CanEdit and CanDelete properties. Not
> when they are actually attempting to perform a post. You see, I prepare the
> DML statements as late as I can while also allowing me to examine which
> columns are included in the statement so I know which columns to make read
> only if they are not included in the appropriate DML statement.

Understood; I didn't know of that smart processing of read-only columns.

> This means that I need to Prepare them prior to the actual Post of the
> modifications.

I thought you just needed to parse them.

> > > IBO prepares the statement in advance, for efficiency.
> >
> > If the statements are prepared every time they are needed, this would
> > surely be inefficient. A better solution would maybe be to prepare each
> > statement the first time it is needed; this would solve the problem and
> > also help reduce resource usage, I think. Dunno if it is easily doable,
> > though.
>
> It is not inefficient as you are suggesting. Once the statement is prepared
> it remains prepared until the dataset itself is Unprepared. Or, until the
> InsertSQL, EditSQL, etc. statement is changed. Then I have to reprepare it.

I should have written "if the statements *were* prepared...". Anyway,
you've cleared things out in the previous paragraph.

> > In the current situation, you are *forced* to query the system tables if
> > you want to deploy the same application to different categories of
> > users; I wouldn't do it; your solution will certainly work but it's
> > cumbersome and leads to multiplication by 4 of the number of data access
> > components needed in the application.
>
> No, not at all. If done right this should be that big of a deal. One query
> and you should have all the information that you need.

I don't understand; I was referring to Claudio's proposed solution of
putting 3 additional IB_DSQL components in the picture, plust fiddling
with a couple of event handlers. That's what I thought was cumbersome.

> > At the very least, an event that signals a prepare error, whose handler
> > gets passed the kind of statement (edit, insert, update...) could help.
> > I'm curious to know what Jason thinks about this one.
>
> My idea that I think suites this particular situation best is if in the
> process of evaluating the value of the CanInsert, CanEdit and CanDelete
> there is a permissions error to simply return false and not interrupt the
> program flow with the exception or even a message at all. My only hesitation
> to introducing such a feature is that I think this will be a source of
> people losing a lot of time trying to make something editable by fiddling
> around in the code before realizing that it is because of their permissions
> in the database.

You are right to worry; in addition, this will change the behaviour and
introduce an incompatibility. I'd just let those methods raise an
exception but only if a certain event-handler (OnEditSQLPrepareError or
such) hasn't set a var RaiseException parameter to False. The handler
should get the exception object (or equivalent information) as well.
This way, things will continue to work as always, and if I need custom
behaviour I just implement a custom event handler.
You could also do what you have suggested, but in that case I'd also
introduce a boolean property to switch to the new behaviour.
Regards
--
____
_/\/ando