Steve Jones - Editor (9/10/2010)
First, don't grant rights to a user. If there's one, he/she will be replaced, or you'll add someone else. Take 10sec and write
Create role MyDenyRole
Then I'd do a GRANT on the single table to that role
If the user doesn't have rights to the database, that's all that's needed. They don't get rights to other tables by default. If they have rights from another role, then you will need some DENY statements, and you'll have to handle that, or remove them from the other group/role.
DO NOT grant rights to public. It's a bad idea. If you have rights set on public, create another role, transfer rights, remove them from public.
First, I apologize - I failed to mention that this "user" is a native SQL service account, not a human. It will never change (unless I'm able to remove it at some point). Because of this, I believe the role is an unnecessary layer.
I agree in not doing anything with public. Trouble is, public already has read/write. As soon as a (new, naked) user account is added to the DB, it inherits read/write from public. It would make my life easier if public didn't come fully loaded.
Mike Hinds Lead Database Administrator1st Source BankMCP, MCTS