How bout a view that can select from a stored procedure.
This would allow you to put whatever logic you wish into the stored procedure.
With the view triggers you can make the view updateable.
With extra global variables you can manipulate the view however you wish
(base it on time of day, role, user name, ip address etc)

From what I understand, this would be the easiest and most flexible approach.

You give each client access to the view, not the table.

best regards

Dalton

On Friday 04 May 2001 13:31, you wrote:
> I've got a persistent client who's been bugging me for a solution
> for a specific security problem. He's got a web application with
> a bunch of clients none of which are allowed to see each other's
> data. The standard way of handling this, of course, is to add a
> conjunct to the "where" clause where appropriate. He's not happy
> that he has to trust his programmers to do the right thing under
> all circumstance, and wants a system solution.
>
> After coming with with all sorts of unsatisfactory solutions, I
> eventually came up with the idea of a per-table compile time
> trigger. The trigger would be fired during compilation of any
> database statement referencing the table. The trigger would
> have access to the environment (login account, active roles,
> connection attributes) and could abort the compilation ("bad
> dog!"), add a conjunct ("and client = 'xyzzy'), or let the
> compilation go.
>
> So far, sounds cool. The next question is "what else is this
> good for" (which is polite way to say what corners are the users
> like to paint themselves into). For example, the compile time
> trigger could be used to track the frequency that various queries
> are compiled and/or prepared.
>
> Any thoughts?
>
> [Yeah, I know it is unblessed by the decoder ring set.]
>
> Jim Starkey
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/