I know enough to be dangerous in that I have been using SQL Server 2005 by following examples from the code of others and using the help system. In reading your very enjoyable book I am being informed of a number of subtle and not so subtle bits that will make my work easier.

In using SQL I have been pretty lax about the use of case. I have found that "SELECT" and "select" work equally well. Further, that case has not seemed to matter in my work in referring to database objects.

In the AdventureWorks database case does seem to matter. The example at the bottom of p. 180 does not work since the column name is "ProductSubcategoryID" not "ProductSubCategoryID". I have not seen this in the databases I use.

Is there some setting for a given database that makes the case of object names important?

In a default installation of SQL Server the collation for the server and its databases is generally set to "SQL_Latin1_General_CP1_CI_AS" CP1 = Code Page 1, CI = Case Insensitive and AS = Accent Sensitive.
However, collation can be set at the database level:

CREATE DATABASE [BinaryDB] ON PRIMARY
( NAME = N'BinaryDB'
, FILENAME = N'D:\SQLData\BinaryDB.mdf' )
LOG ON
( NAME = N'BinaryDB_log'
, FILENAME = N'E:\SQLLog\BinaryDB_log.ldf')
COLLATE Latin1_General_BIN

and at the column level of a table:

CREATE TABLE MyBinarySortTable
(Column1 varchar(10) COLLATE SQL_Latin1_General_BIN)

If the database collation is set to a Binary collation or a Case-Sensitive collation like "SQL_Latin1_General_CP1_CS_AS" then all references to object names must be case-correct. From your post I would assume that your installation of AdventureWorks is case-sensitive. You can check this by looking at the Options page of Database properties in Management Studio or query the sys.databases system view:
SELECT name, collation_name FROM sys.databases

SQL commands are not case-sensitive regardless of the server collation so "select" and "where" will work just as well as "SELECT" and "WHERE" will.

There is a good description of the collation settings and their effect on data retrieval in Chapter two of the Beginning SQL Server 2008(2005) Administration books. (Shameless plug for another WROX Book <grin>)


Hope this helps!
-Dan Wood