Subject | Re: [IBO] How to set readonly flag from grant on dataset fields |
---|---|
Author | Helen Borrie |
Post date | 2004-08-02T23:43:05Z |
At 02:51 PM 2/08/2004 +0000, you wrote:
rdb$user_privileges at application startup and creating a structure in
memory, e.g. two stringlists, that the application could read before
creating the datasets and/or (because you are not using native IBO) the
controls.
You would need to have very exact knowledge of how the privileges were set
up, to know what to query, since it is between "hard" and "impossible" to
manage SQL privileges without a properly-designed scheme. You would need to
supply a very specific tool to limit the kinds of privileges that the end
user DBA could set up and to ensure that the hierarchy of ownership could
not be broken. I have no idea how you would control things if the DBA
decided to "roll his own".
The logic would be quite horrendous and the application overhead at startup
would be significant.
On the other hand, if a user attempts to update columns that she doesn't
have privileges for, the server will throw an exception. Your application
can intercept these exceptions and simply handle them. An example of the
strategy would be to catch the exceptions as they occur, revert the
modified column to its original value and resubmit the request. You could
collect these incidents into a data structure and, finally, when the commit
succeeds or fails totally, deliver a message to the user regarding the
read-only fields.
Helen
>HiI have no idea what you mean by this! :-)
>
>I use TIBOTable in Delphi 5 with Firebird 1.5, sometimes with
>automatic fields definition and most of the time with permanent
>fields (best of all would have been : automatic fields definition
>with some permanent one !).
>As I would allow end user DBA to set granting on columns, I wonderI think it would be *possible* to do this, by querying the table
>how to have automatic setting on field definition depending of
>grants (first of all read-only flag set)
rdb$user_privileges at application startup and creating a structure in
memory, e.g. two stringlists, that the application could read before
creating the datasets and/or (because you are not using native IBO) the
controls.
You would need to have very exact knowledge of how the privileges were set
up, to know what to query, since it is between "hard" and "impossible" to
manage SQL privileges without a properly-designed scheme. You would need to
supply a very specific tool to limit the kinds of privileges that the end
user DBA could set up and to ensure that the hierarchy of ownership could
not be broken. I have no idea how you would control things if the DBA
decided to "roll his own".
The logic would be quite horrendous and the application overhead at startup
would be significant.
On the other hand, if a user attempts to update columns that she doesn't
have privileges for, the server will throw an exception. Your application
can intercept these exceptions and simply handle them. An example of the
strategy would be to catch the exceptions as they occur, revert the
modified column to its original value and resubmit the request. You could
collect these incidents into a data structure and, finally, when the commit
succeeds or fails totally, deliver a message to the user regarding the
read-only fields.
Helen