Most of the articles that I presented so far for database development have been centered around the exact Microsoft T-SQL syntax to perform a certain operation. At the University of Rhode Island, I learnt how to program in Pascal before typing in my first ANSI SQL statement. In short, I will always be some type of developer in my heart.
However, many people do not come from a computer science and math background. The SQL Server Management Studio (SSMS) has menus and dialog boxes to achieve many of the same results.
Today, I am going to continue the series of articles that will recreate the [AUTOS] sample database while demonstrating how common T-SQL tasks in my script can be done with SSMS. I will be going over sections 1F to 1H in the sample code.
Security in Microsoft SQL Server is based upon the idea that principals are given rights to securables. Principals in the most basic sense are server logins and database users.
Securables are any object such as table, view, function, procedure, and etc in which a database user can be GRANTED, DENIED, or REVOKED rights.
Please see the MSDN permissions hierarchy diagram below.
Our task today is to add two server logins named [AUTOS_USER] which has read rights to the database and [AUTOS_ADMIN] which has read & write rights to the database.
To create a new server login, find the logins node under server security in the object explorer. Right click and select New Login.
First, lets take a look at the detailed choices that need to be made for the [AUTOS_USER].
Make sure the radio button for SQL Server Authentication is selected. Enter the correct login name and password. Make sure the password options are unselected since we do not want to enforce password policy, enforce password expiration or make the user change the password at next login. Last but not least, make sure the default database is [AUTOS].
We now supplied enough information for SSMS to create a server login (CREATE LOGIN).
Find the user mapping page on the right side of the new login dialog box.
Map the new login to the [AUTOS] database as a user. As a default, the user will be in the public database role. Add the user to the db_datareader role and map the user to the [ACTIVE] schema. This can be done by entering the correct schema name or using the search boxes to bring up a list of schemas.
We now supplied enough information for SSMS to create a database user (CREATE USER).
Second, we need to repeat the same detailed choices for the [AUTOS_ADMIN] server login.
We need to repeat the same detailed choices for the [AUTOS_ADMIN] database user.
The only changes are a default schema of [STAGE] and a additional database role of db_datawriter.
Let’s take a look at the results of our hard labor.
Go to the Logins node under Server Security in the object explorer. Expand the logins node to see all the members. Both the [AUTOS_ADMIN] and [AUTOS_USERS] server login do exist.
To find out if we created our database users correctly, drill into the [AUTOS] database in the object explorer pane. Go to the Users node under database Security. Expand the users node to see all the members. Both the [AUTOS_ADMIN] and [AUTOS_USERS] database users do exist.
To complete our test of designing users with SSMS, we need to drop the database user then server login.
Find the [AUTOS_USER] database user under the logins node in the object explorer. Right click and select delete. The delete object dialog box will appear. Selecting the OKAY button will remove the database user.
I will leave deleting the [AUTOS_USER] server login as an exercise for you to-do.
In summary, we can do many of the Data Definition Language (DDL) tasks that can be done in T-SQL. The cool script button shows you what SQL Server Management Studio (SSMS) will use for code to accomplish a particular task. Next time, I will be talking about creating user defined tables with SSMS.