This action might not be possible to undo. Are you sure you want to continue?
To get the most out of this tutorial, you should have a copy of SQL Server installed on your computer (preferably SQL Server 2000), so that you can go through the examples yourself. If you don't have a copy, that's OK - you should still be able to gain an understanding of what SQL Server is and what's involved in using it. This tutorial consists of the following lessons: 1. About SQL Server 2. SQL Server - Enterprise Manager 3. SQL Server - Create a Database 4. SQL Server - Create a Table 5. SQL Server - Adding Data 6. SQL Server - SQL Query Analyzer 7. SQL Server Views 8. SQL Server Stored Procedures 9. SQL Server Security 10. SQL Server - Create a Login 11. SQL Server - DTS 12. SQL Server Agent 13. SQL Server Agent Jobs 14. SQL Server - Service Manager 15. SQL Profiler 16. SQL Server - Summary
1. About SQL Server
Microsoft SQL Server is a Relational Database Management System (RDBMS) designed to run on platforms ranging from laptops to large multiprocessor servers. SQL Server is commonly used as the backend system for websites and corporate CRMs and can support thousands of concurrent users. SQL Server comes with a number of tools to help you with your database administration and programming tasks.
SQL Server is much more robust and scalable than a desktop database management system such as Microsoft Access. Anyone who has ever tried using Access as a backend to a website will probably be familiar with the errors that were generated when too many users tried to access the database! Although SQL Server can also be run as a desktop database system, it is most commonly used as a server database system. Server Database Systems Server based database systems are designed to run on a central server, so that multiple users can access the same data simultaneously. The users normally access the database through an application.
2. Enterprise Manager
Enterprise Manager is the main administration console for SQL Server.
Enterprise Manager enables you to create database objects (such as databases, tables, views etc), you can configure user accounts, you can set up scheduled tasks, transfer data between databases, and more.
You can use Enterprise Manager to connect to as many databases on as many servers as you like. You can group these servers by configuring a "server group". The above screenshot has one server group called "SQL Server Group". This is the default name SQL Server gives to the initial server group. For each server group, you can add any number of servers. And, for each server, you can add any number of databases. Most of the tasks performed with Enterprise Manager are initiated either from the top menu, or by right-clicking on an icon/object.
3. Create a Database
One of the first things we should look at with SQL Server/Enterprise Manager is how to create a database. System Databases If you've only just installed SQL Server, you might notice that some databases have already been created. These are system and sample databases.
Stores system level information such as user accounts, configuration settings, and info on all other databases.
This database is used as a template for all other databases that are created.
Used by the SQL Server Agent for configuring alerts and scheduled jobs etc
Holds all temporary tables, temporary stored procedures, and any other temporary storage requirements generated by SQL Server.
This database can be used for training purposes, and is based on a book publishing company.
This database can be used for training purposes, and is based on a fictitious company called "Northwind Traders".
We will now create another database for our own use. Creating a New Database 1. Right click on the "Databases" icon and select "New Database...":
2. Name your database and click "OK":
Your New Database You will now notice your new database appears under the "Databases" section of Enterprise Manager. Your new database is based on the "Model" database. The Model database is a system database which is used as a template whenever a new database is created. If you use the left panel to navigate to your database and expand the tree, you will notice that your database already contains a number of objects. For example, it already contains tables, views, and stored procedures. These are system objects which provide information about the database.
Other Options We have just created a database using the default options. When we created the database, a "Data File" and a "Transaction Log" were created. They were created in the default location for our server. If we'd wanted to, we could have specified a different location for these files by using the "Data Files" tab and "Transaction Log" tab. We also could have changed specifications on whether to allow the file to grow automatically (as it stores more and more data), and if so, how that growth should be managed.
4. Create a Table
1. Ensuring you have the right database expanded, right click on the "Tables" icon and select "New Table...":
2. While you have this screen open, do the following: a. Using the values in the screenshot, complete the details in the "Column Name" column, the "Data Type" column, "Length" column, and "Allow Nulls" column. b. Make the IndividualId column an "identity column", by setting "Identity" to "Yes" (just use the same values as in the screenshot). Note that to set values in the bottom panel, you need to select the column name in the top panel first). This column is going to be an auto-number column - it will contain an incrementing number for each record that is created. c. Set the "Default Value" of the DateCreated column to (getdate()). (This will automatically insert the current date into that field for each new record). 7
What we are doing at this stage, is creating the column names, specifying the type of data that can be entered into them, and setting default values. Restricting the data type for each column is very important and helps maintain data integrity. For example, it can prevent us from accidentally entering an email address into a field for storing the current date. 3. Close the table by clicking the close icon , and when prompted, name your table:
Your New Table Now that you've created a new table, it will appear under your database in the "Tables" section
5. Adding Data
Using Enterprise Manager We can use Enterprise Manager to add data - all we need to do is open the table, then start typing.
1. To open the table, right click on the table you wish to open, and select "Open Table > Return all rows":
2. You can now start entering the data directly into your table.
Disadvantages of Entering Data Directly to your Table The above method is fine if you only have a small amount of data to enter or update. If you have a lot of data to enter, this could become very tedious. Also, if you have multiple 10
environments (for example, a development environment, staging environment, and production environment), with duplicate databases configured in each environment, you will need to reenter the same data into each environment. When you're first learning SQL Server, this may not be a major concern. However, in an environment such as described, entering data directly into the table becomes quite inefficient. A Better Method - SQL Scripts In most cases, you will probably find it more efficient to write a SQL script. Using a script enables you to re-enter the data as many times as you like. If you need to rebuild your database for any reason, you can simply run your script to enter the data. If you have multiple environments, once again you can run your script against each environment. Once you get used to writing and running scripts, you will probably find it quicker than entering data directly into the table. Database Driven Websites When you create a database driven website, you actually write SQL scripts to insert data into the database. You also use SQL scripts to read data, update data, and delete data. These SQL scripts can be placed directly into your website code (PHP, ColdFusion etc), or they can be stored in the database as Stored Procedures or Views.
6. SQL Query Analyzer
The SQL Query Analyzer is the main interface for running SQL queries against your database. You can use the SQL Query Analyzer to create and run adhoc scripts, or you can create SQL scripts and save them for later use. Accessing SQL Query Analyzer You can open Query Analyzer from Enterprise Manager by clicking Tools > Query Analyzer.
SQL Query Analyzer looks like this:
Tip: Before you open Query Analyzer, use Enterprise Manager to navigate to the database you'd like to work with. That way, Query Analyzer will open using that database. Object Browser SQL Query Analyzer also has an "Object Browser" that you can use to browse and edit tables, views, and stored procedures. The Object Browser also displays a list of common SQL Server functions and their parameters. To open the Object Browser, press F8. Alternatively, you can click the Object Browser icon on the toolbar. Another way of showing the Object Browser is to go Tools > Object Browser > Show/hide. The Object Browser displays to the left of your workspace. 12
Writing Queries You are now ready to write SQL queries against your database. You can use this interface to create database objects (such as databases, tables, views etc), insert data into a database table, select data, update data, delete data. The following screen shot shows an example of using a SQL 'select' statement to select data from a database :
When I started creating the above example, I forgot the name of the table that I wanted to select data from. That wasn't a problem. All I needed to do was navigate through the Object Browser until I saw the names of the tables in the left pane. When I saw the table I needed, I simply clicked and dragged it onto the workspace area (and releasing the mouse in the right spot). This is quite a nice feature of Query Analyzer/Object Browser as it can save you time. As you can see, the results of the query are displayed in the bottom panel.
In SQL Server, a view is a pre-written query that is stored on the database. A view consists of a SELECT statement, and when you run the view, you see the results of it like you would when opening a table. Some people like to think of a view as a virtual table. This is because a view can pull together data from multiple tables, as well as aggregate data, and present it as though it is a single table. Benefits of Views A view can be useful when there are multiple users with different levels of access, who all need to see portions of the data in the database (but not necessarily all of the data). Views can do the following:
• • •
Restrict access to specific rows in a table Restrict access to specific columns in a table Join columns from multiple tables and present them as though they are part of a single table Present aggregate information (such as the results of the COUNT function)
Creating a View You create a view by using the CREATE VIEW statement, followed by the SELECT statement. CREATE VIEW ViewName AS SELECT ... Example: CREATE VIEW "Alphabetical list of products" AS SELECT Products.*, Categories.CategoryName 14
FROM Categories INNER JOIN Products ON Categories.CategoryID = Products.CategoryID WHERE (((Products.Discontinued)=0)) Modifing a View You can modify an existing view by using using ALTER instead or CREATE. Example: ALTER VIEW "Alphabetical list of products" AS SELECT Products.*, Categories.CategoryName FROM Categories INNER JOIN Products ON Categories.CategoryID = Products.CategoryID WHERE (((Products.Discontinued)=0)) Running a View You run a view by using a SELECT statement. SELECT * FROM "Alphabetical list of products" Running the above view results in this:
8. Stored Procedures
Stored procedures are a powerful part of SQL Server. They can assist programmers and administrators greatly in working with the database configuration and its data. A stored procedure is a precompiled group of Transact-SQL statements, and is saved to the database (under the "Stored Procedures" node). Programmers and administrators can execute stored procedures either from the Query Analyzer or from within an application as required. Transact-SQL, which is based on SQL, is the programming language used to interface between applications and their databases. Transact-SQL is a relatively easy language to learn and I highly recommend becoming familiar with it. Benefits of Stored Procedures Here are some key benefits in using stored procedures:
Explanation of benefit
You can write a stored procedure once, then call it from multiple places in your application.
Stored procedures provide faster code execution and reduce network traffic.
Faster execution: Stored procedures are parsed and optimized as soon as they are created and the stored procedure is stored in memory. This means that it will execute a lot faster than sending many lines of SQL code from your application to the SQL Server. Doing that requires SQL Server to compile and optimze your SQL code every time it runs.
Reduced network traffic: If you send many lines of SQL code over the network to your SQL Server, this will impact on network performance. This is especially true if you have hundreds of lines of SQL code and/or you have lots of activity on your application. Running the code on the SQL Server (as a stored procedure) eliminates the need to send this code over the network. The only network traffic will be the parameters supplied and the results of any query.
Users can execute a stored procedure without needing to execute any of the
statements directly. Therefore, a stored procedure can provide advanced database functionality for users who wouldn't normally have access to these tasks, but this functionality is made available in a tightly controlled way.
Creating a Stored Procedure You create stored procedures in the Query Analyzer using the CREATE PROCEDURE statement, followed by the code that makes up the stored procedure. CREATE PROCEDURE StoredProcedureName AS ... The following code creates a stored procedure called "MyStoredProcedure": CREATE PROCEDURE MyStoredProcedure AS SET ROWCOUNT 10 SELECT Products.ProductName AS TenMostExpensiveProducts, Products.UnitPrice FROM Products ORDER BY Products.UnitPrice DESC Once you run this code in the Query Analyzer, the stored procedure is created and appears under the "Stored Procedures" node. Modifying a Stored Procedure If you need to modify an existing stored procedure, you simply replace the CREATE with ALTER. ALTER PROCEDURE MyStoredProcedure AS ... Running a Stored Procedure You can run a stored procedure by using EXECUTE or EXEC. For example, to run the above stored procedure, type the following: EXEC MyStoredProcedure If the stored procedure has spaces in its name, enclose it between double quotes: EXEC "My Stored Procedure" 17
If your stored procedure accepts any parameters, they are placed after the procedure name: EXEC MyStoredProcedure @ParameterName="MyParameter" The following screenshot shows the results of running a stored procedure called "SalesByCategory" and passing it a parameter of "Beverages":
Parameters A parameter is a value that your stored procedure uses in order to perform it's task. When you write a stored procedure, you can specify the parameters that need to be supplied from the user. For example, if you write a stored procedure to select the address details about an individual, your stored procedure needs to know which individual to select. In this case, the user can provide an IndividualId or UserId to tell the stored procedure which individual to look up. System Stored Procedures
SQL Server includes a large number of system stored procedures to assist in database administration tasks. Many of the tasks you can perform via Enterprise Manager can be done via a system stored procedure. For example, some of the things you can do with system stored procedures include:
• • • • • • •
configure security accounts set up linked servers create a database maintenance plan create full text search catalogs configure replication set up scheduled jobs and much more.
SQL Server has a number of security features that assist database administrators in maintaining their database in a secure way. You can see the areas of security by expanding the "Security" folder within Enterprise Manager.
SQL Server allows you to configure users and roles for anyone who needs to access SQL Server or any of its databases and their objects. Typically, you will have a database administrator who has access to everything. Then you will have users with varying levels of access, depending on the tasks they're allowed to perform. Doing this can prevent inexperienced users from wreaking havoc on your database environment. Imagine if one morning you came to work, only to find that someone had accidentally deleted your main database! In Enterprise Manager, you can use SQL Server Security section to restrict the tasks that each user can perform. If you have many users, you can assign them a role. Roles enable you to assign the same access rights across many users. Instead of assigning permissions against an individual user (or 'login'), you assign them against a role. You can then add users/logins into that role. More about logins in later. Server Roles Server roles are available for various database administration tasks. Not everyone should be assigned to a server role. In fact, only advanced users such as database administrators should be assigned a server role. Here are the server roles defined in SQL Server during setup:
Can perform any task in SQL Server.
Can set server-wide configuration options, can shut down the server.
Can manage linked servers and startup procedures.
Can manage logins and database permissions, read logs, change passwords.
Can manage processes running in SQL Server.
Can create, alter, and drop databases.
Can manage disk files.
Can execute BULK INSERT statements.
As you can see, some of these roles allow very specific tasks to be performed. If you don't have many technical users, it's likely that you'll only use one or two of these roles (including sysadmin). Linked Servers The Linked Servers option allows you to connect to another instance of SQL Server running on a different machine, perhaps remotely in a different city/country. This can be useful if you need to perform distributed queries (query a remote database). Setting up a linked server is quite straight forward in Enterprise Manager, all you need is details of the remote server, and the database that you need to query.
In the above example, "Data Source" is the name of the SQL Server machine, "Catalogue" is the name of the database. You can also configure options in the other two tabs depending on your requirements. Remote Servers The Remote Servers option allows you to execute a stored procedure on another instance of SQL Server without establishing another connection. The Remote Servers option is only provided for backwards compatibility. If you need to execute stored procedures against a remote server, use a linked server.
10. Create a Login
In the previous lesson about SQL Server security, we learned that SQL Server allows for the creation of different logins for different users. These logins can be assigned to any number of roles, depending on the access that user is entitled to. In this lesson, we will walk through the steps in creating a login. To Create a New Login 1. Using Enterprise Manager, expand the "Security" option and right click on "Logins"
2. Click on "New Login"
Tip: You can bypass the above steps by clicking on the "New Login" icon menu
in the top
3. Complete the Login Properties in the "General" tab by providing a name for the login, choosing the Authentication method (providing a password if you choose "SQL Server Authentication"), and selecting the database to use as a default. If you don't choose
language, it will use the default for the current installation of SQL Server.
4. Click the "Server Roles" tab if you need to apply any server-wide security privileges.
5. Click the "Database Access" tab to specify which databases this login is allowed to access. By default, the login will be assigned to the "Public" role, which provides the login with basic access. If the login needs more access in one or more databases, it can be assigned to another role with greater privileges. Note that these roles are "Database Roles" and are different to the Server Roles in the previous tab. Server Roles are for administering the SQL Server. Database Roles are created within each database and specify what the login can do within that database.
You may occasionally find yourself in the situation where you need to transfer a lot of data into your SQL Server database from another database or spreadsheet. Or, perhaps you need to export data from your database into another database or spreadsheet. In SQL Server, DTS makes this an easy task. DTS (Data Transformation Services) is a set of graphical tools that allows you to transfer data between disparate sources into one or more destinations. DTS Tools SQL Server DTS includes the following tools, which enable you to create, schedule, and execute DTS packages.
Enables you to transfer data to and from a SQL Server database.
Enables you to build complex DTS packages containing workflow and eventdriven logic. The DTS Designer can also be used to modify packages created with the DTS Import/Export Wizard.
DTS Run utility
Allows you to schedule and run a DTS package.
Allows you to run DTS packages from the command prompt and schedule them using batch files.
DTS Query Designer
A graphical user interface that allows you to build SQL queries.
Importing and Exporting Data The following steps demonstrate how you can use the Import/Export Wizard to import data into your SQL Server database from another data source.
1. Using Enterprise Manager, right click on the "Data Transformation Services" node and select All Tasks > Import Data...
2. Click "Next >"
3. Select the Data Source - this is the file/database that contains the data we want to import. In this example, we are importing data from a Microsoft Access database, so we use the "Microsoft Access" option. We also specify the file name of the Access
database as well as username and password if required.
4. Select the Destination - this is the file/database that we want to import data into. In this example, we are importing data to our SQL Server database called "MyDatabase". We are also using Windows Authentication, but we could just have easily used one of the
user accounts on our SQL database.
5. Choose whether to copy one or more tables or to use a query to specify the data to transfer. In this example, we are going to copy a table and all its data.
6. Select the table (or views) that you'd like to copy, and the name of the destination table. In this example, we'll use the default (a table will be created using the same name and data types as the source table). You also have the option of clicking on "Transform" to change the column properties of the destination table. For example, you can change column names, data types, size etc. For now, we'll just leave it as is.
7. Specify when to run this DTS package and whether to save it or not. In this example, we are going to run the package now. We have also chosen to save the DTS package.
8. Because we have chosen to save this package, we need to specify details about the DTS package.
9. Finally, we get to finish (and run) the DTS package!
10. And now, let's see if our DTS import was successful...
Well, now that we know our DTS import was successful, we can take a look at the table that was created. We can also have a look at our saved DTS package.
Our DTS Package We can locate the DTS package under the "Local Packages" node. By right clicking on the package, we can modify it using the "Design Package" option, run it using "Execute Package", and schedule it using "Schedule Package".
DTS Designer By selecting "Design Package" (see above screenshot), you can modify your saved DTS package using the DTS Designer. DTS Designer allows you to apply tasks, workflow and event driven logic against your DTS package. Here's what the DTS Designer looks like:
12. SQL Server Agent
The SQL Server Agent is a service that lets you configure scheduled tasks and system alerts. SQL Server Agent runs continuously in the background as a Windows Service. The SQL Server Agent is made up of the following components:
SQL jobs consist of one or more steps to be executed. Each step consists of a SQL statement. SQL Agent Jobs can be scheduled to run at specified times or at specified intervals.
SQL Alerts consist of a set of actions to occur when a specific event occurs (such as when a particular error occurs, or the database reaches a defined size). Alerts can include sending an email to the administrator, paging the administrator, or running a job to fix the problem.
Operators are people who can address problems with SQL Server. Operators can be identified through their network account or their email identifier. These are usually the people who alerts are sent to.
SQL Agent Configuration Behind the scenes, SQL Agent Job definitions are specified in the msdb database. You might remember the msdb database from a previous lesson. It is a system database that is created when you first install SQL Server. You don't really need to know that in order to use the SQL Agent Service though. You can configure SQL Server Agent jobs, alerts and operators via Enterprise Manager. Applications that use SQL-DMO or Transact-SQL with a standard database API can also do this, but for now, we'll stick with Enterprise Manager. Starting the SQL Server Agent You can start and stop the SQL Server Agent Service via Enterprise Manager, the Windows Services console, or via the SQL Server Service Manager. More on the Service Manager later, but for now, you should know that you need to have the SQL Server Agent Service running before any scheduled jobs can be run or alerts can sent. To start the SQL Server Agent Service via Enterprise Manager, right click on the "SQL Service Agent" node, and click "Start":
Now that SQL Server Agent is running, any jobs or alerts that you create will automatically run when they're supposed to.
13. SQL Server Agent Jobs
Now that you know that the SQL Server Agent Service is responsible for ensuring any scheduled jobs are run at the specified time, let's create a SQL Server Agent Job. Creating a SQL Server Agent Job 1. From the "SQL Server Agent" node, right click on the "Jobs" node, and select "New Job":
2. Complete the details in the "General" tab:
3. Complete the details in the "General" tab:
4. From the "Steps" tab, click "New"
5. Complete the details for this step. In this example, we are using the dtsrun utility to execute a DTS package:
6. From the "Schedules" tab, click "New Schedule"
7. Give this schedule a name and specify the schedule type:
8. If you need to set a recurring schedule, click "Change" (from the previous screen) and complete the details:
Your SQL Agent Job has now been set up and is ready to run every morning at 2am, but don't forget to check that the SQL Server Agent Service is running!. Modifying your SQL Agent Job You can view your SQL Agent Job under the "Jobs" node. If you need to modify your SQL Agent Job, you can do so by right clicking on the job, then selecting "Properties". You can also run your job (by selecting "Start Job"), view its history, disable it, and more.
Is the SQL Server Agent Running? By looking at the screen shot above, I can tell that the SQL Server Agent Service is not running. The icon is what gives it away. Here's what the icon should look like: Running Not Running The reason I'm re-iterating this is because I have been caught out so many times with this. It's so easy to create a SQL job that its so easy to forget to check whether the SQL Server Agent is even running. In a production environment, the SQL Server Agent will be running constantly. In a development environment, you may choose to disable it until you need to test it.
14. SQL Server Service Manager
SQL Server Service Manager is used to start, stop, and pause the various components on SQL Server. These components run as Windows services. The following services can be stopped/started/paused via the SQL Service Manager:
SQL Server service
Implements the SQL Server database engine. There is one SQL Server service for each instance of SQL Server running on the computer.
SQL Server Agent service
Implements the agent that runs SQL Agent jobs and alerts. There's one SQL Agent service for each instance of SQL Server running on the computer.
Microsoft Search service
Implements the full-text search engine. There is only one full-text search engine regardless of how many instances of SQL Server are running on the computer.
Manages distributed transactions. There is only one MSDTC service regardless of how many instances of SQL Server are running on the computer.
Implements the SQL Server Analysis Services. There is only one MSSQLServerOlAPService service regardless of how many instances of SQL Server are running on the computer.
Using the SQL Server Service Manager SQL Server Service Manager is a taskbar application. When SQL Server Service Manager is minimized, an icon appears in the taskbar.
To use the Service Manager, you can either right click on the icon, or double click on the icon. Right clicking provides a menu of options, double clicking maximizes the Service Manager for you to select your options.
15. SQL Profiler
SQL Profiler is a handy tool that enables you to monitor events within your SQL Server (or more specifically, a SQL Server instance). For example, you could use SQL Profiler to check the performance of a stored procedure. You could also use SQL Profiler to troubleshoot a problem that's occuring in your production environment. When using SQL Profiler, you can save the output to a "trace file" so that you can later analyze the events that occured during your trace. Accessing SQL Profiler To access SQL Profiler: 1. Open Enterprise Manager 2. Select Tools > SQL Profiler menu
Creating & Running A "Trace" To monitor activity with SQL Profiler, you create a "trace". A trace captures data based on activity at the time it is run. To create a trace: 1. Open SQL Profiler as demonstrated above 2. Select File > New > Trace...
3. Select the SQL Server you'd like to connect to, provide authentication details, then click OK
4. In Trace Name field, enter a name for the trace, then set the other trace properties as required. For now, just use the default settings
5. When you're ready to run the trace, click "Run". You will see something like this:
6. When you're ready to stop the trace, click the "stop trace" icon Explanation of the "Trace Properties" Screen In the previous steps, when we got to the "Trace Properties" screen (step 4), we used the default trace properties. You can change any of these properties as required. For example, you could save the trace output to a file or database table. You could also change the events, data columns, and/or filter the data presented in the trace. Following is a more detailed explanation of each tab on the Trace Properties screen.
The "General" Tab
The following table provides an explanation of the options on the General tab.
Provides a name for the trace.
Trace SQL server
This is the server you'd like to run the trace against.
This allows you to select a template to base the trace on. Templates provide you with a trace where the options from the Events, Data Columns, and Filters tabs are pre-configured. SQL Server includes a number of templates that you can use. SQLProfilerStandard is the default. The template you select will depend on the data you need from your trace. You can also create your own templates if
Trace file name
Allows you to provide the full path to a template.
Save to file
Allows you to save the trace output to a file.
Save to table
Allows you to save the trace output to a database table.
Enable trace stop time
Allows you to specify a date and time for the trace to stop.
The "Events" Tab The Events tab consists of event classes grouped by event categories. An event class is the column that describes the event produced by SQL Server. An event is an action generated within the SQL Server engine. Some examples of events include:
• • • • • • • •
Transact-SQL SELECT, INSERT, UPDATE, and DELETE statements Locks being acquired/released Stored procedures being started/stopped A login connection/failure/disconnection A cursor being opened Errors written to the event log A remote procedure call (RPC) batch status Security permission checks
Try adding/removing events to see how this affects the trace output.
The "Data Columns" Tab Data columns describe the data collected for each event class included in the trace. When you view the results of a trace, the data is presented within these data columns. Note that the data columns that are available will depend on the event classes selected. This is because the event class determines the type of data available. Also note that default data columns are selected automatically with all event classes.
The "Filters" Tab Filters allow you to filter the data collected by the event. This can help you eliminate data you're not interested in, so that you can concentrate on the data you are interested in. For example, if you're only interested in activity from one user, you can filter the trace to only that user.
16. SQL Server Summary
Congratulations for reaching the end of this SQL Server tutorial! SQL Server is a powerful application, and this tutorial has provided an overview of the main concepts involved in administering SQL Server. To recap briefly, we've:
• • • • • • •
created databases created database tables inserted data into those tables used the Query Analyzer to run a query created a login account created and executed a DTS package executed that same DTS package via a scheduled job 57
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.