T-Sql 101

I showed how identity columns are a special type of constraint. They can be  int or bigint. Both work just fine. What you might need to know though, is the last value inserted automatically by SQL Server.

@@IDENTITY

For a long time, SQL Server only had a single option for this. It was the @@IDENTITY value.

The problem was that it could give you a value different to what you were looking for. The most common situation where this happened is if a trigger was set up. An INSERT trigger says when somebody does an insert, after it’s finished, execute this command as well. But what if that code in the trigger inserted a row somewhere else, perhaps to audit the inserts. The problem is that @@IDENTITY would return back the value from the second INSERT, not the one that you thought it was returning.

2025-03-20

In the previous post, I talked about how you could add default values for columns.

One special type of default value is called an IDENTITY constraint. These columns are one way to achieve automatic numbering in a column. There are many pros and cons about using these but at this point, I want to make sure you know how to use them.

The main difference from other columns is that you don’t put them in your INSERT statements. In fact, unlike other types of default constraint, you cannot just put the values in there. It will raise an error.

2025-03-18

Default constraints allow us to automatically provide values for columns when:

• we don’t supply them ourselves
• they are marked as NOT NULL so they are required

When you’re building an INSERT statement, you don’t have to give values for all columns. Columns that are declared as NULL aren’t mandatory, so you don’t have to supply those columns at all. Those columns can just be NULL.

But if you have a column that is declared as NOT NULL, so it requires a value, but you haven’t supplied it in the INSERT statement, then a default constraint can provide the value. This is configured as part of the table definition, or added as a constraint later by altering the table definition.

2025-03-16

Prior to SQL Server 2008, we could only insert a single row at a time. SQL Server 2008 added the ability to have multiple rows of data in the VALUES clause.

Each row is created from what are typically called row constructors. In the example above, I’m inserting 3 rows into the Cinema Groups table. The syntax allows for up to 1000 rows to be inserted at once.

Before you get to that number of rows though, you might exceed the maximum allowable length for a T-SQL statement, if you have a lot of columns, each with a lot of data. The maximum length of a statement is in theory 2GB but most people run into the batch size limit of 65536 * network packet size or about 268MB, first. Either way, it’s a lot of data in a single statement, and running into these limits is uncommon.

2025-03-14

To insert new rows into a table, you will mostly use the INSERT statement.

In the example above, I’ve inserted one row into the dbo.CinemaGroups table. There are a few aspects to this statement.

First, you should always use two-part names for the table i.e., use dbo.CinemaGroups not just CinemaGroups.

Second, there is an optional INTO keyword for INSERT statements. You can say INSERT INTO dbo.CinemaGroups. While I’m generally pretty pedantic about these things, I can’t see any value that the word INTO adds here and I don’t use it. (Worth noting that other dialects of SQL like the one in Access, insist that it’s there).

2025-03-12

There are times that you need to be able to query the database and its internal structures rather than querying the user tables.

In the example above, I’ve asked for details of all the databases, and then for details of all the schemas in the current database, followed by details for all the tables and columns in the current database.

These are a well-designed set of system views that are easy to work with. They are often referred to as catalog views. You can even see all of them as part of querying sys.views.

2025-03-10

It’s also possible to create the command dynamically before you execute it.

In the example above, I’ve set a number of different parts of a SQL statement into variables, and then used them to construct a complete SQL statement that I’ve then executed. I just have to create a valid SQL statement as a string.

Warning

While this might seem really, really convenient, and it can be incredibly useful, it is something you need to be extraordinarily careful with. One of the problems with this is that it can easily open you up to what’s called SQL injection attacks.

2025-03-08

In T-SQL, the way we execute a stored procedure is to use the EXECUTE statement. We can write it as EXECUTE or as EXEC. You’ll almost always see it written as EXEC.

In the first example above, I’ve executed a stored procedure called dbo.GetCinemaChanges. Note that I’ve included the dbo schema in the name of the procedure. For procedures like this, you should always include the schema name.

The procedure also takes one parameter called @CurrentDate and set it to the 28th February 2012.

2025-03-06

Stored procedures are prepackaged groups of T-SQL statements. They can also be written in other languages, but most of the time they’ll be written in T-SQL.

There are pros and cons with using stored procedures.

In the example shown, I use the EXEC statement to execute a stored procedure called SDU_Tools.ListAllDataTypesInUse.

Parameters

The procedure also takes a number of parameters. By using different parameters values, I can change the behaviour of the stored procedure.

2025-03-04

I mentioned earlier that CTEs can be used to clean up or tidy more complicated queries. You will find people though, who really don’t like them at all. My aim here isn’t to argue for or against them, as it’s a complex topic, but to make sure you know how to write queries with them, and more importantly, to be able to read queries that use them. At this point, I want you to understand the syntax.

2025-03-02