Row level security - View for all?

Hi there,
I am implementing row level security on a large database (at least I think i
t is large). It is enforced by adding which company submitted the row and w
hich company they are subitting to. The security is enforced by using views
to only return the rows th
e current user is allowed to see according to there user name. What they ca
n do with what they see is determined by which role they are assigned to.
What I am wondering is if I need a view for every table in the database? I
think to be completely secure that I do. But then I think that it is redun
dent as you can't really find anything in some tables without starting from
another. i.e. to find cert
ain attributes of an object you need to fuind the object first.
Any thoughts here would be appreciated,
DenisI am implementating row level security as well and made the decision to have
a view for every table for 2 reasons - simplicity and security. No one will
have direct access to any table - only through a view or stored proc. If y
ou establish a view for eve
ry table, there will be no confusion as to wether to reference a table or vi
ew - always refer to the view.
How are you doing the filtering of data on a per user basis in your view?
"Denis Crotty" wrote:

> Hi there,
> I am implementing row level security on a large database (at least I think it is l
arge). It is enforced by adding which company submitted the row and which company t
hey are subitting to. The security is enforced by using views to only return the ro
ws
the current user is allowed to see according to there user name. What they can do with what
they see is determined by which role they are assigned to.
> What I am wondering is if I need a view for every table in the database? I think
to be completely secure that I do. But then I think that it is redundent as you ca
n't really find anything in some tables without starting from another. i.e. to find
ce
rtain attributes of an object you need to fuind the object first.
> Any thoughts here would be appreciated,
> Denis|||That was my feeling as well for using a view for every table. I just was ba
lking as there are 40+ tables.
I filter by checking SUSER_SNAME() and then using the result in a look up ta
ble for what company they are with.
Denis
"Scott Shearer" wrote:

> I am implementating row level security as well and made the decision to have a vie
w for every table for 2 reasons - simplicity and security. No one will have direct a
ccess to any table - only through a view or stored proc. If you establish a view fo
r e
very table, there will be no confusion as to wether to reference a table or view - always re
fer to the view.[vbcol=seagreen]
> How are you doing the filtering of data on a per user basis in your view?
> "Denis Crotty" wrote:
>
s the current user is allowed to see according to there user name. What they can do with wh
at they see is determined by which role they are assigned to.[vbcol=seagreen]
certain attributes of an object you need to fuind the object first.[vbcol=seagreen]

Row Height Affected When Adding New Row

I am attempting to add a new row to a table. Every time I add the new row (doens't matter where) it has an effect on the height of the other rows in the table when displayed on screen (makes them taller). However the rows retain the required height when printed. I haven't any idea what might be causing this behaviour. The only explanation I can think of is that this is a bug.

I know it's a bit obscure but has anyone else come across this or have any idea what might be causing it?

After much trial and error I've discovered that for my particular reports that if I add a new row (to the Header say) and don't set the CanGrow property for the textboxes on that row to false then the rows in the detail expand (even though CanGrow is set to False). This is a bug in my book.

The reason for adding the new row is to insert a sub-report into the header of the table. The sub-report does not have a CanGrow property. Therefore I can't add it without affecting the other rows on the report. This is pretty annoying.

Mark