Catálogo de publicaciones - libros

The text for this chapter is not the most fluid, but the information contained will be very useful as you start using SQL Server. Each section we have covered contains a great deal of useful and pertinent information, and rereading the chapter and maybe even trying out different ideas based on the basics demonstrated will give you a stronger understanding of what is happening.

The main areas of focus were error handling and joining tables to return results. Take time to fully understand what is happening and how you can use these two features.

So we are coming toward the end of the book, and you are well primed with T-SQL knowledge of what you can achieve within stored procedures and functions. In Chapter 13, we take a look at triggers, and all you have learned with programming T-SQL can also be applied there as well.

Subqueries are one of the most commonly used areas of T-SQL, but common table expressions are also useful, so knowing these areas well will enable you to move forward at a rapid pace. Combine this knowledge with the functionality covered in Chapter 11, especially when working with JOINs, and you should start to see how powerful T-SQL can be at working with time-based data.

One last piece of advice: if a query starts becoming very complex, you may find that it starts performing badly. We don’t look at performance of queries within this book, although we have discussed indexes and how they can help your query perform better. Always take a step back and think, “Would this work better as two queries where the first query creates a subset of data?” Writing the most complex of queries that processes all the data in one pass of the data may not always be the best answer.

DML triggers should be seen as specialized and specific stored procedures set up to help your system with maintaining data integrity, cascading updates throughout a system, or enforcing business rules. If you take out the fact that there are two system tables, INSERTED and DELETED, and that you can check what columns have been modified, then the whole essence of a trigger is that it is a stored procedure that runs automatically when a set data-modification condition arises on a specific table.

DDL triggers will be built mainly for security or reporting of system changes to compliance departments and the like. With the EventData() XML information available to a trigger, a great deal of useful information can be inspected and used further.

Coding a trigger is just like coding a stored procedure with the full control of flow, error handling, and processing that is available to you within a stored procedure object.

The aim of this chapter was to demonstrate how a trigger is fired, and how to use the information that is available to you within the system to update subsequent tables or to stop processing and rollback the changes.

The DML triggers built within this chapter have demonstrated how to use the virtual tables, as well as how to determine whether a column has been modified. The DDL triggers built have demonstrated how you can trap events and determine what has been changed either within a database or a server.

This brings us to the end of , demonstrating how to report on the data within the example we have been building up throughout the book. There has been an overview of how reporting services works and is architected, and we have seen an overview of building a simple report and previewing the results. The next move for you would be to read (Apress, 2005; ISBN 1590594770) and also (Apress, 2005; ISBN 1590595661).