As we've seen in the previous lesson, functions are incredible useful in SQL. Now we're going to learn how we can build our own functions that work just like the system ones. This can get a little complex, but it's well worth understanding.

SQL Server stores some special values in a function. A function is kind of like a stored procedure that runs in place and returns data that you need before processing the rest of the statement. You might see them in place of columns, in a where clause or anywhere else where you might see a variable or a literal value.

Errors! Every programmer hates them but they are a fact of life. Up until now we've treated errors like something that just shouldn't happen. The truth is, SQL is a pretty solid language that doesn't have near as many error-causing events as other languages. This is thanks to how explicit you have to be with everything you do in SQL. It cuts down on errors.

In the last lesson we learned how to control our SQL transactions. However, we really need to know how to fit this into a stored procedure to take full advantage of it. We’re going to pick up where we left off in the last lesson and add transactions, commits and rollbacks to our existing TransferMoneyToSavings stored procedure.

You might have been asking yourself, "Isn't there a way to hit Undo in SQL Server?" It's a good and valid question. It's very easy to screw things up in a computer program, so why isn't there an undo feature to SQL server?

One of the most curious things about SQL server is that it keeps its own system data in the same kind of database format and schema that you as the end user utilizes. The ability to look into the system’s database is very useful to developers. Being able to programmatically examine your things like a list of databases existing on the server or even the individual columns within serves lots of useful purposes.

SQL Server is a powerful system. There is a lot going on under the hood that we can't see and don't know about. Today, we're going to look at some of the commands that we can use to take a look at what's going on outside our individual SQL session.

In a previous lesson we learned how to use the IF and THEN statements to direct the flow of logic in our application. However, sometimes the change in logic might only have to do with a column or a variable. Additionally, we sometimes need to make a decision based on the contents of a column on each row. Consider the following example.

In this lesson, you will learn how to format the text and numbers.

In our last lesson, we developed a stored procedure that does some pretty cool things. It combines a lot of concepts we've learned thus far and even gives the user some feedback about what's happening. However, there are still some things we could do to make it work a little better.