<wackyphill@yahoo.com> wrote in message
news:1103334538.943609.119930@z14g2000cwz.googlegr oups.com...
> OK, (understand I'm just beginning SQL Server, but am an experienced
> programmer) now what would the accessGranted() have to return? Would it
> return like a string that fills in the where clause or something else?

It'd allow you to specify the columns people get returned from the query.
Do you need to vary them as well?
Because.... that's something I'd recommend avoiding if you can.

>
> I'm not sure what is allowed and what's not.
> And thanks everyone for the input I've received I really appreciate it.

I like simple designs myself.
I can understand them.
When they go wrong I can fix em easier.

When I've had similar issues I prefer to have users in (windows) groups and
associate SQL security at that level.
People join and leave, it's not my problem. Whoever looks after the windows
security changes that stuff.
With vb.net you can tell what group they're in and hide the button leads to
specific screens by setting visible=false.
I would imagine similar functionality is available in other GUIs, or you
could use sql and write a stored procedure returned the group and call that
instead.

Usually where people are allowed to work with one bit of data and not
another it's because their team ( or whatever ) raises those orders ( or
whatever) and no other team does. Maybe there's another manager or whatever
team deals with the lot and over-rides this....
But generally there's something you can associate with an order (say).
So...
I'd stick a team ( or whatever ) field on some significant table or tables.
Write the team in there as it's created.
Associate the windows group with that team - either directly on a 1:1 basis
or indirectly via a table ( which'd allow for the financial director to see
everything ).
And that'd pretty much be that.

You can work out the windows group in the gui and pass to the stored
procedure or in the stored procedure.
Watch out for jobs in the latter case.

HTH.
--
Regards,
Andy O'Neill