While writing code in a Query Window, you should always know what database you are working on, otherwise you may add code to the wrong database. To programmatically specify the current database, type the USE keyword followed by the name of the database. The formula to use is:

USE DatabaseName;

Here is an example:

USE GovernmentStatistics;

Some of the windows that display databases, like the SQL Server Management Studio, don't update their list immediately if an operation occurred outside their confinement. For example, if you create a database in the query windows, its name would not be updated in the Object Explorer. To view such external changes, you can refresh the window that holds the list.

In SQL Server Management Studio, to update a list, you can right-click its category in the Object Explorer and click Refresh. Only that category may be refreshed. For example, to refresh the list of databases, in the Object Explorer, you can right-click the Databases node and click Refresh.

A namespace is a technique of creating a series of items that each has a unique name. For example, if you start creating many databases, there is a possibility that you may risk having various databases with the same name. If using a namespace, you can isolate the databases in various namespaces. In reality, to manage many other aspects of your database server, you use namespaces and you put objects, other than databases, within those namespaces. Therefore, a namespace and its content can be illustrated as follows:

Notice that there are various types of objects within a namespace.

Within a namespace, you can create objects as you wish. To further control and manage the objects inside of a namespace, you can put them in sub-groups called schemas. Therefore, a schema is a group of objects within a namespace. This also means that, within a namespace, you can have as many schemas as you want:

Notice that, just like a namespace can contain objects (schemas), a schema can contain objects also (the objects we will create throughout our lessons).

To manage the schemas in a namespace, you need a way to identify each schema. Based on this, each schema must have a name. In our illustration, one schema is named Schema1. Another schema is named Schema2. Yet another schema is named Schema_n.

A schema is an object that contains other objects. Before using it, you must create it or you can use an existing schema. There are two types of schemas you can use, those built-in and those you create. When Microsoft SQL Server is installed, it also creates a few schemas. One of the schemas is called sys.

The sys schema contains a list of some of the objects that exist in your system. One of these objects is called databases (actually, it's a view). When you create a database, its name is entered in the databases object using the same name you gave it.

To access the schemas of a database, in the Object Explorer, expand the Databases node, expand the database that will hold or own the schema, and expand the Security node.

To create a schema, right-click Schemas and click New Schema...

This would open the Schema - New dialog box. In the Schema Name text box, enter a one-word name. Here is an example:

After providing a name, you can click OK.

We will see a practical example of creating a schema in Lesson 7.

Inside of a schema, two objects cannot have the same name, but an object in one schema can have the same name as an object in another schema. Based on this, if you are accessing an object within its schema, you can simply use its name, since that name would be unique. On the other hand, because of the implied possibility of dealing with objects with similar names in your server, when accessing an object outside of its schema, you must qualify it. To do this, you would type the name of the schema that contains the object you want to use, followed by the period operator, followed by the name of the object you want to use. From our illustration, to access the Something1 object that belongs to Schema1, you would type:

Schema1.Something1

A permission is an action that a user is allowed to perform, or is prevented from performing, on a database or on one of its objects.

Many server operating systems and database environments use the word "right" for permission. In our lessons, we will use both words interchangeably. That is, for the rest of our lessons, the words "right" and "permission" will mean the exact same thing.

Microsoft SQL Server provides two first broad categories of permissions: physical and virtual. The physical permission has to do with who has physical access to the computer or the room where it is located (who can open it, who can shut it down, etc). We are not concerned with physical permissions in these lessons. For the rest of our lessons, the permissions have to do with how to electronically connect to the server and what a user can do with it.

Microsoft SQL Server provides various levels of security and therefore permissions are managed on different levels.

In order to do something on the server or one of its objects, a user must be given the permission. This is also referred to as granting a permission. To grant permissions, the account you are using must have the ability to do so. This means that, before granting permissions, you must log in with an account that has its own right permissions. You can grant permissions visually or with code.

To visually grant one or more permissions on the server, in the Object Explorer, right-click the name of the server and click Properties. In the left frame of the Server Properties dialog box, click Permissions. In the Logins or Roles list, click the name of the user. In the bottom list, use the options in the Grants column:

The basic formula to programmatically grant one or more permissions on a server is:

GRANT Permission TO Login

You start with the GRANT keyword followed by the name of the permission. After the permission, type TO, followed by the login name you want to grant the permission to. Here is an example:

USE master;
GO
GRANT CREATE ANY DATABASE
TO operez;
GO

If you want to grant more than one permission, separate their names with commas. Here is an example:

GRANT CREATE ANY DATABASE, SHUTDOWN
TO operez;
GO

If you want to grant the same permission(s) to more than one account, list them, separated by commas. Here is an example:

GRANT CREATE ANY DATABASE, ALTER ANY LOGIN
TO pkatts, gdmonay;
GO

1. In the Object Explorer, right-click the top node (the name of the computer) and click Properties...
2. In the left frame, click Permissions
3. In the Logins or Roles list, click pkatts
4. In the Permissions list, in the Grant column, click the check box that corresponds to Create Any Database.
   Make sure Connect SQL is selected
    
   
5. Still in the Permissions for pkatts section, in the Grant column, click the check boxes that correspond to Alter Any Connection, Alter Any Database, and Alter Any Login
    
   
6. Click OK
7. On the task bar, click Start -> Switch User
8. Log in with the pkatts account
9. On the task bar, click Start -> (All) Programs -> Microsoft SQL Server -> SQL Server Management Studio
10. Make sure the Authentication is set to Windows Authentication and that the pkatts account is selected as as the User Name.
    Click Connect
11. In the Object Explorer, expand the Databases node
12. Right-click Databases and click New Database...
13. In the Name, type Beauty Salon and click OK.
    Notice that the database has been created.
14. On the task bar, click Start -> Log off
15. Re-log in as the account you were using before

To primary permission a person needs in Microsoft SQL Server is to be able to connect to the server. This is also the default permission. After all, if a person cannot establish a connection to the server, what's the point? When you create a new user account, it is automatically given the right to connect to the server. Otherwise, you can deny it if you want.

As opposed to granting rights, you can prevent a user from doing something on the server, on a database, or on an object. This is referred to as denying a permission.

To visually deny one or more permissions on the server, in the Object Explorer, right-click the name of the server and click Properties. In the left frame, click Permissions. In the Logins or Roles list, click the name of the user. Use the options in the Deny column.

The basic formula to programmatically deny one or more permissions on a server is:

DENY Permission1,Permission2, Permission_n
TO Login1, Login2, Login_n

Here is an example:

DENY CREATE ANY DATABASE
TO rkouma;
GO

1. In the Object Explorer, right-click the name of the computer and click Properties...
2. In the left frame, click Permissions
3. In the Logins or Roles list, click operez
4. In the Permissions list, in the Deny column, click the check box that corresponds to Create Any Database
    
   
5. Click OK
6. In the Object Explorer, right-click RealEstate1 and click Properties
7. In the left frame, click Permissions
8. In the Users or Roles section, click Orlando
9. In the Permissions for Orlando section, in the Deny column, click the check box that corresponds to Connect
    
   
10. Click OK
11. On the task bar, click Start -> (All) Programs -> Microsoft SQL Server -> SQL Server Management Studio
12. Set the Authentication to SQL Server Authentication
13. In the Login name, type operez and press Tab
14. In the password, type P@ssword1
15. Click Connect
16. In the Object Explorer, expand the Databases node
17. Click the + button of MotorVehicleAdministration. Notice that you can expand it
18. Still in the Object Explorer, click the + button of RealEstate1.
    Notice that you receive an error
     
    
19. Click OK on the message box
20. Close Microsoft SQL Server
21. Restart it and login with an account that has administrative rights using the Windows Authentication
22. Click Connect
23. In the Object Explorer, right-click MotorVehicleAdministration and click Delete
     
    
24. In the Delete Object dialog box, click OK
25. On the Standard toolbar, click the New Query button
26. To delete a database, type:
    

    DROP DATABASE RealEstate1;
    GO
    drop database [beauty salon];
    GO

27. Press F5 to execute the statement
28. Close Microsoft SQL Server
29. When asked whether you want to save, click No

There are many issues you need to keep in mind in order to rightfully manage permssions. This is because permissions are somehow interconnected. This means that granting one permission may not work if another right is not given or denied to the same user.

There are so many permissions in Microsoft SQL Server that we cannot explain all of them. Instead, you can check the documentation to see a list of all of them. Still, some permissions are used regularly and are of primary importance:

• Connect: Obviously the primary right you need to give a user is the ability to connect to a Microsoft SQL Server database. If you want to permanently or temporarily block access of the server to a user, you can deny the Connect permission
• Create Any Database: By default, users are able to create new databases on the server as long as they have access to it. The Create Any Database permission allows a user to create a new database. If you want a user to only be able to use existing databases created by other people such as the database administrator(s), you should deny this right
• Alter Any Database: Even if you prevent a user from creating new databases, he can still change something in the existing databases. To prevent such actions, you should deny this right
• Alter Any Login: This permission allows a user (the user who receives this right) to change the login account of another user. This right should be granted only to database administrators

Besides granting or denying permissions to an account, you can give an account the ability to grant or deny permissions to another account. To do this visually, open the Database Properties for the database you want to work on. In the Users or Roles section, select the user. In the Persmissions, use the check boxes in the With Grant column.

The formula to programmatically give an account the ability to grant or deny permissions to other accounts is:

GRANT Permission1,Permission2, Permission_n
TO Login1, Login2, Login_n
WITH GRANT OPTION

This follows the same formula as the GRANT we saw earlier. You must just add the WITH GRANT OPTION expression.

Consider the following SQL statement:

DENY CREATE ANY DATABASE
TO rkouma;
GO

When this code has been executed, if the TO user logs in and tries creating a database, he would receive an error:

Revoking a permission consists of either denying a permission that was previously granted or granting a permission that was previously denied. To visually do this, open the Properties dialog box of the database (or the object) on which the permission was managed.

To programmatically revoke a permission, the formula to follow is:

REVOKE [ GRANT OPTION FOR ] <permission> [ ,...n ]  
    { TO | FROM } <database_principal> [ ,...n ] 
        [ CASCADE ]
    [ AS <database_principal> ]

<permission> ::=  permission | ALL [ PRIVILEGES ]

<database_principal> ::= Database_user 
    | Database_role 
    | Application_role 
    | Database_user_mapped_to_Windows_User 
    | Database_user_mapped_to_Windows_Group 
    | Database_user_mapped_to_certificate 
    | Database_user_mapped_to_asymmetric_key 
    | Database_user_with_no_login

Start with the REVOKE keyword followed by the permission(s). This is followed by either TO or FROM and the login name of the account whose permission must be managed. Here is an example:

/*
DENY CREATE ANY DATABASE
TO rkouma;
GO
*/

REVOKE CREATE ANY DATABASE
TO rkouma;
GO

Revoking a permission doesn't give that same permission. Imagine a user with a newly created account didn't have the permission to create new databases. If you deny that person the ability to create new databases, that denial becomes effective. If you revoke the permission, you are asking the server to restore the status of that person with regards to that particular right. That doesn't give that user the permission. The above code doesn't give the user the right to create new databases. If you want the user to have a right, you must explicitly grant the permission. Consider the following code:

REVOKE CREATE ANY DATABASE
TO rkouma;
GO

GRANT CREATE ANY DATABASE
TO rkouma;
GO

This restores the user's denial for creating new databases, then grants the permission to that user. This time, the user has the right to create new databases.