Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Beginning Microsoft SQL Server 2008 ... - S3 Tech Training Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

cdn.s3techtraining.com
from cdn.s3techtraining.com More from this publisher
17.06.2013 Views

Chapter 3: The Foundation Statements of T-SQL 70 For your first insert, we’ll eliminate the optional column list and allow SQL Server to assume we’re providing something for every column: INSERT INTO Stores VALUES (‘TEST’, ‘Test Store’, ‘1234 Anywhere Street’, ‘Here’, ‘NY’, ‘00319’); As stated earlier, unless we provide a different column list (we’ll cover how to provide a column list shortly), all the values have to be supplied in the same order as the columns are defined in the table. After executing this query, you should see a statement that tells you that one row was affected by your query. Now, just for fun, try running the exact same query a second time. You’ll get the following error: Msg 2627, Level 14, State 1, Line 1 Violation of PRIMARY KEY constraint ‘PK__Stores__1387E197’. Cannot insert duplicate key in object ‘dbo.Stores’. The statement has been terminated. Why did it work the first time and not the second? Because this table has a primary key that does not allow duplicate values for the StoreCode field. As long as we changed that one field, we could have left the rest of the columns alone and it would have taken the new row. We’ll see more of primary keys in the chapters on design and constraints. So let’s see what we inserted: SELECT * FROM Stores WHERE StoreCode = ‘TEST’; This query yields us exactly what we inserted: StoreCode Name Address City State Zip --------- ------------ ----------------------- -------------------- ----- ----- TEST Test Store 1234 Anywhere Street Here NY 00319 (1 row(s) affected) Note that I’ve trimmed a few spaces off the end of each column to help it fit on a page neatly, but the true data is just as we expected it to be. Now let’s try it again with modifications for inserting into specific columns: INSERT INTO Stores (StoreCode, Name, City, State, Zip) VALUES (‘TST2’, ‘Test Store’, ‘Here’, ‘NY’, ‘00319’); Note that on the line with the data values we’ve changed just two things. First, we’ve changed the value we are inserting into the primary key column so it won’t generate an error. Second, we’ve eliminated the value that was associated with the Address column, since we have omitted that column in our column list. There are a few different instances where we can skip a column in a column list and not provide any data

for it in the INSERT statement. For now, we’re just taking advantage of the fact that the Address column is not a required column — that is, it accepts NULLs. Since we’re not providing a value for this column and since it has no default (we’ll see more on defaults later on), this column will be set to NULL when we perform our INSERT. Let’s verify that by rerunning our test SELECT statement with one slight modification: SELECT * FROM Stores WHERE StoreCode = ‘TST2’; Now we see something a little different: StoreCode Name Address City State Zip --------- ----------- --------------- ------- -------- ------ TST2 Test Store NULL Here NY 00319 (1 row(s) affected) Notice that a NULL was inserted for the column that we skipped. Note that the columns have to be nullable in order to do this. What does that mean? Pretty much what it sounds like: It means that you are allowed to have NULL values for that column. Believe me, we will be discussing the nullability of columns at great length in this book, but for now, just realize that some columns allow NULLs and some don’t. We can always skip providing information for columns that allow NULLs. If, however, the column is not nullable, then one of three conditions must exist, or we will receive an error and the INSERT will be rejected: ❑ The column has been defined with a default value. A default is a constant value that is inserted if no other value is provided. We will learn how to define defaults in Chapter 7. ❑ The column is defined to receive some form of system-generated value. The most common of these is an IDENTITY value (covered more in the design chapter), where the system typically starts counting first at one row, increments to two for the second, and so on. These aren’t really row numbers, as rows may be deleted later on and numbers can, under some conditions, get skipped, but they serve to make sure each row has its own identifier. ❑ We supply a value for the column. Just for completeness, let’s perform one more INSERT statement. This time, we’ll insert a new sale into the Sales table. To view the properties of the Sales table, we can either open its Properties dialog as we did with the Stores table, or we can run a system-stored procedure called sp_help. sp_help will report information about any database object, user-defined data type, or SQL Server data type. The syntax for using sp_help is as follows: EXEC sp_help To view the properties of the Sales table, we just have to type the following into the Query window: EXEC sp_help Sales; Chapter 3: The Foundation Statements of T-SQL 71

Chapter 3: The Foundation Statements of T-<strong>SQL</strong><br />

70<br />

For your first insert, we’ll eliminate the optional column list and allow <strong>SQL</strong> <strong>Server</strong> to assume we’re providing<br />

something for every column:<br />

INSERT INTO Stores<br />

VALUES<br />

(‘TEST’, ‘Test Store’, ‘1234 Anywhere Street’, ‘Here’, ‘NY’, ‘00319’);<br />

As stated earlier, unless we provide a different column list (we’ll cover how to provide a column list<br />

shortly), all the values have to be supplied in the same order as the columns are defined in the table. After<br />

executing this query, you should see a statement that tells you that one row was affected by your query.<br />

Now, just for fun, try running the exact same query a second time. You’ll get the following error:<br />

Msg 2627, Level 14, State 1, Line 1<br />

Violation of PRIMARY KEY constraint ‘PK__Stores__1387E197’. Cannot insert duplicate<br />

key in object ‘dbo.Stores’.<br />

The statement has been terminated.<br />

Why did it work the first time and not the second? Because this table has a primary key that does not<br />

allow duplicate values for the StoreCode field. As long as we changed that one field, we could have left<br />

the rest of the columns alone and it would have taken the new row. We’ll see more of primary keys in<br />

the chapters on design and constraints.<br />

So let’s see what we inserted:<br />

SELECT *<br />

FROM Stores<br />

WHERE StoreCode = ‘TEST’;<br />

This query yields us exactly what we inserted:<br />

StoreCode Name Address City State Zip<br />

--------- ------------ ----------------------- -------------------- ----- -----<br />

TEST Test Store 1234 Anywhere Street Here NY 00319<br />

(1 row(s) affected)<br />

Note that I’ve trimmed a few spaces off the end of each column to help it fit on a page neatly, but the<br />

true data is just as we expected it to be.<br />

Now let’s try it again with modifications for inserting into specific columns:<br />

INSERT INTO Stores<br />

(StoreCode, Name, City, State, Zip)<br />

VALUES<br />

(‘TST2’, ‘Test Store’, ‘Here’, ‘NY’, ‘00319’);<br />

Note that on the line with the data values we’ve changed just two things. First, we’ve changed the value<br />

we are inserting into the primary key column so it won’t generate an error. Second, we’ve eliminated the<br />

value that was associated with the Address column, since we have omitted that column in our column list.<br />

There are a few different instances where we can skip a column in a column list and not provide any data

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!