Voice of the DBA

Tag: T-SQL

  • SQL Server Truncate Table Permissions

    I saw a note recently where someone asked what permissions were needed for a user to execute TRUNCATE TABLE. In previous versions we needed ownership of the table or DBO level permissions. I had thought this was changed in SQL 2005 to require just the CONTROL permission.

    However when I checked the TRUNCATE Books Online page, I found this: The minimum permission required is ALTER on table_name. TRUNCATE TABLE permissions default to the table owner, members of the sysadmin fixed server role, and the db_owner and db_ddladmin fixed database roles, and are not transferable. However, you can incorporate the TRUNCATE TABLE statement within a module, such as a stored procedure, and grant appropriate permissions to the module using the EXECUTE AS clause.

    Alter permissions is the minimum?!?!!?

    That sounded fishy, so I did this. First I created a new user, with no permissions other than public. My user was, appropriately, MyTestUser.

    Next I created a table and granted permissions:

    CREATE TABLE TRLC 
(
  est_no varchar(10) default ' '
, right_no int default 0
)
GO

INSERT TRLC SELECT 'Test', 1

GRANT CONTROL ON TRLC TO MyTestUser

    I then opened up another Query Window and changed the connection to use MyTestUser. This user only had CONTROL permissions and nothing else. A quick test showed that this user could indeed clear out the table. This:

    TRUNCATE TABLE dbo.TRLC

    executed without error.

    I think Books Online needs an update, and I’ll submit a note to that team to clarify this.

  • Common SQL Server Mistakes

    This presentation is designed to cover some of the basic mistakes that I find people making quite often when working with SQL Server. It is a mix of development and administrative items, designed to help beginners get a grounding in those skills that often cause the most problems in SQL Server.

    The talk is 75 minutes.

    Slide Decks:

  • Insert_Identity Permissions

    Despite my joking with Aaron Bertrand on Twitter that his suggestion on Connect got voted down because he’s Canadian, I think he has a great point with a hole in Books Online. He wrote a nice blog on the item, and it’s one you ought to consider voting up if you agree.

    I voted it up, and I think this is the type of half-*ssed documentation that is strewn throughout Books Online. While it’s a great document, and has a lot of information, it’s not always clear what is meant, and there are often holes. Most items have permissions listed, but not all, and even those that do are not clearly written or even correct.

    In my mind, the ability to change the identity values on a table ought to be either explicitly a permission that is given to users (GRANT IDENTITY_INSERT on xx to yy) or it ought to be included with the INSERT permission. There isn’t really anything here that’s altering a schema. It’s an insert permission for a user, that explicitly needs to put in a value, perhaps to close a sequence, or fix a failed insert. There’s no reason to require any elevated permission for this action.

    In any case, having the documentation clearer, even if it doesn’t behave as I’d expect it, is something I think is worth voting for.

  • More Triggers

    In the old days of T-SQL, back when we wrote “CREATE TRIGGER …. FOR INSERT” we could only have one insert/update/delete trigger for each table. Eventually SQL Server allowed us to have multiple triggers, and even have some control over in what order the triggers fired.

    Triggers are often hidden objects that confound DBAs who aren’t aware they exist. It’s not easy to tell when a table has a trigger on it, and since we don’t often use triggers, it’s not the first place people look when something strange happens.

    However triggers are useful, and it seems that there are many people using them. For this Friday, I wanted to ask how people implement triggers in their applications.

    Do you prefer one trigger for each table action or multiple triggers?

    I’m curious what’s the 80 in your 0/20 rule for triggers. Should all update actions be handled in one trigger? Or should there be one trigger for business logic  and a separate one for auditing? I’m not sure it matters a lot for performance, but I can see that it might be easier to manage and track fewer triggers. The flip side is that something like auditing can be handled with one trigger, and business logic with another: a clean separation.

    Triggers aren’t usually my first solution to a problem, but I do think there is value in using them. However I don’t see a lot of guidance about how to best implement them, so I’m hoping your answers today will help.

    Steve Jones