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

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

> > 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 don't know if you plan to query system tables to see if some user is
> > allowed to modify data. How did you expected this to happen? Black

magic?

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

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

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com