I've used this scheme before. I wouldn't expect any performance issue with those number.

>BTW if you are at Whilfest this year I'll miss you. None of us are going. You'd recognize me because I hogged your time after a couple of your sessions last year.

Too bad that you can't make GLGDW.

-Mike

>Thanks, Mike.
>
>This looks like something to try. It looks less cumbersome than my scheme and it still keeps the security formula in one location. Are there performance issues I need to be aware of? Say on a Main table with 50,000+ records, and 30 users?
>
>BTW if you are at Whilfest this year I'll miss you. None of us are going. You'd recognize me because I hogged your time after a couple of your sessions last year.
>
>Regards,
>
>>I was just thinking that if you passed in the name of the logged-in user to the stored procedure, you could encapsulate your security within a table-value function and join it against your tables to implement row-oriented security:
>>
>>

>>CREATE PROCEDURE getContacts
>> @loginUser int
>>AS
>>
>>SELECT ...
>>FROM
>> contact c
>> INNER JOIN dbo.fn_visibleContacts(@loginUser) vc ON vc.contactid = c.contactid
>>

>>
>>I've used this before and it works well.
>>
>>-Mike
>>