Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
Beginning Microsoft SQL Server 2008 ... - S3 Tech Training Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
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
- Page 58 and 59: Chapter 1: RDBMS Basics: What Makes
- Page 60 and 61: Chapter 2: Tools of the Trade 22 My
- Page 62 and 63: Chapter 2: Tools of the Trade ❑ S
- Page 64 and 65: Chapter 2: Tools of the Trade 26 Ke
- Page 66 and 67: Chapter 2: Tools of the Trade 28 Th
- Page 68 and 69: Chapter 2: Tools of the Trade 30 lo
- Page 70 and 71: Chapter 2: Tools of the Trade 32 3.
- Page 72 and 73: Chapter 2: Tools of the Trade 34 Fi
- Page 74 and 75: Chapter 2: Tools of the Trade Figur
- Page 76 and 77: Chapter 2: Tools of the Trade Note
- Page 78 and 79: Chapter 2: Tools of the Trade bcp i
- Page 81 and 82: 3 The Foundation Statements of T-SQ
- Page 83 and 84: asic SELECT statement. Fire up the
- Page 85 and 86: Now let’s try taking a little bit
- Page 87 and 88: very few of your tables will have s
- Page 89 and 90: Operator Example Usage Effect ALL,
- Page 91 and 92: Chapter 3: The Foundation Statement
- Page 93 and 94: WHERE SalesOrderID IN (43660, 43670
- Page 95 and 96: AVG This one is for computing avera
- Page 97 and 98: efore, but remove the two AS keywor
- Page 99 and 100: You’ll get a result that is a bit
- Page 101 and 102: What if we want to place conditions
- Page 103 and 104: Let’s say, for example, that we w
- Page 105 and 106: Chapter 3: The Foundation Statement
- Page 107: City varchar(20) NOT NULL, State ch
- Page 111 and 112: And sure enough, we get back the on
- Page 113 and 114: Chapter 3: The Foundation Statement
- Page 115 and 116: Chapter 3: The Foundation Statement
- Page 117: Chapter 3: The Foundation Statement
- Page 120 and 121: Chapter 4: JOINs 82 returned is in
- Page 122 and 123: Chapter 4: JOINs 84 Using an INNER
- Page 124 and 125: Chapter 4: JOINs 86 Uh, oh — this
- Page 126 and 127: Chapter 4: JOINs How It Works Unlik
- Page 128 and 129: Chapter 4: JOINs If we were to look
- Page 130 and 131: Chapter 4: JOINs 92 What I’m tryi
- Page 132 and 133: Chapter 4: JOINs 16 Mountain-500 Si
- Page 134 and 135: Chapter 4: JOINs 96 Let’s use thi
- Page 136 and 137: Chapter 4: JOINs 98 vendor. We’re
- Page 138 and 139: Chapter 4: JOINs 100 Somehow, we lo
- Page 140 and 141: Chapter 4: JOINs Try It Out FULL JO
- Page 142 and 143: Chapter 4: JOINs Every time I teach
- Page 144 and 145: Chapter 4: JOINs JOIN Sales.Special
- Page 146 and 147: Chapter 4: JOINs Figure 4-1 As alwa
- Page 148 and 149: Chapter 4: JOINs 110 CREATE TABLE U
- Page 150 and 151: Chapter 4: JOINs There are two diff
- Page 152 and 153: Chapter 5: Creating and Altering Ta
- Page 154 and 155: Chapter 5: Creating and Altering Ta
- Page 156 and 157: Chapter 5: Creating and Altering Ta
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