> > 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.
>
> Of course: if you want maximum flexibility, you should code. Is this new for
> a programmer or engineer?

Ok Claudio; a framework should help avoid repeating huge amounts of code
in common situations. I thought that was a common situation, so a
smarter solution could be thought about. I didn't mean one doesn't have
to code, just concentrate on application code rather than data access
methodology, which is the realm of the framework.

> The point is: IBO has events in case the text
> properties aren't enough. Those that want IBO guessing the rights on the db
> server should take extra steps.

Do you agree that the following:

- I have a data entry form with a "live" query. Possibly many of these
forms.
- I have some users which can insert and edit but not delete data.
- I have some users which can do anything.
- I have some users ...
- I want to do all my user right management on the db server itself.
- I want a user which is not enabled to do (say) delete receive an error
message when he actually tries to delete, while allowing him to browse,
insert and edit.

is a common situation?
If it is, then maybe IBO should favor the development of such a thing as
easy as possible. If not, any solution that requires additional
components and code is acceptable (and the one you proposed is quite
good).
Regards
--
____
_/\/ando