Overview of Installing SQL Server 2000

Microsoft® SQL Server™ 2000 Setup creates a new installation of SQL Server 2000 or upgrades an earlier version. Before installing or upgrading to SQL Server 2000 it is recommended that you review the following topics.

Topic | Description
Preparing to Install SQL Server 2000 | Lists steps to take before running SQL Server 2000 Setup
SQL Server 2000: Editions and Components | Presents an overview of the editions of SQL Server 2000, installation options, and components
Upgrading an Existing Installation of SQL Server | Outlines options for upgrading to SQL Server 2000 from an earlier version

For more information, see related topics in the table below.

To install | See
SQL Server 2000 (typical installation of the relational database engine, client tools, and client connectivity components) | How to install SQL Server 2000 (Setup)
SQL Server 2000 client tools only (includes management tools and client connectivity components, no server required) | How to install client tools only (Setup)
SQL Server 2000 connectivity only (installs only the client connectivity components, no other options) | How to install connectivity only (Setup)
A named instance or multiple instances of SQL Server 2000 | How to install a named instance of SQL Server 2000 (Setup)
A SQL Server 2000 virtual server for failover clustering | Before Installing Failover Clustering
Analysis Services | Installing Analysis Services
English Query | Installing English Query


Preparing to Install SQL Server 2000

Before installing Microsoft® SQL Server™ 2000, consider the following:

  • Be sure the computer meets the system requirements for Microsoft SQL Server 2000. For more information, see Hardware and Software Requirements for Installing SQL Server 2000.

  • Back up your current installation of Microsoft SQL Server if installing SQL Server 2000 on the same computer.

  • If installing a failover cluster, disable NetBIOS on all private network cards before running SQL Server Setup. For more information, see Before Installing Failover Clustering.

  • Review all SQL Server installation options and be prepared to make the appropriate selections when running Setup. For more information about editions and components, see SQL Server 2000: Editions and Components.

  • If you plan to install SQL Server to a location other than the default file locations, see File Paths for SQL Server 2000.

  • If using an operating system with Regional settings other than English (United States), or if customizing character set or sort order settings, review topics on collation settings. For more information, see Collation Options for International Support.
Before Running SQL Server 2000 Setup

Before running Setup:

  • Create one or more domain user accounts if installing SQL Server 2000 on a computer running Microsoft Windows NT® or Microsoft Windows® 2000, and you want SQL Server 2000 to communicate with other clients and servers. For more information, see Creating Security Accounts.

  • Log on to the operating system under a user account that has local administrative permissions, or assign the appropriate permissions to the domain user account.

  • Shut down all services dependent on SQL Server. This includes any service using ODBC, such as Microsoft Internet Information Services (IIS).

  • Shut down Microsoft Windows NT Event Viewer and registry viewers (Regedit.exe or Regedt32.exe).


Hardware and Software Requirements for Installing SQL Server 2000

The minimum hardware and software requirements for running Microsoft® SQL Server™ 2000 are listed in the following tables.

Hardware Requirements

This table shows hardware requirements for installing Microsoft SQL Server 2000 or SQL Server client management tools and libraries.

Hardware | Minimum requirements
Computer | Intel® or compatible Pentium 166 MHz or higher.
Memory (RAM)1 | Enterprise Edition: 64 MB minimum, 128 MB or more recommended Standard Edition: 64 MB minimum Personal Edition: 64 MB minimum on Windows 2000, 32 MB minimum on all other operating systems Developer Edition: 64 MB minimum Desktop Engine: 64 MB minimum on Windows 2000, 32 MB minimum on all other operating systems
Hard disk space2 | SQL Server database components: 95 to 270 MB, 250 MB typical Analysis Services: 50 MB minimum, 130 MB typical English Query: 80 MB Desktop Engine only: 44 MB
Monitor | VGA or higher resolution 800x600 or higher resolution required for the SQL Server graphical tools
Pointing device | Microsoft Mouse or compatible
CD-ROM drive | Required

1 Additional memory may be required, depending on operating system requirements.
2 Actual requirements will vary based on your system configuration and the applications and features you choose to install.

Note Microsoft SQL Server 2000 does not have a hardware compatibility list (HCL). If your computer meets the minimum requirements listed in the preceding table, SQL Server 2000 software works on the hardware certified for use with the Microsoft Windows® operating system. For more information about hardware certified for use with the Windows operating system, see the Microsoft Windows Hardware Compatibility List at Microsoft Web site.

Operating System Requirements

This table shows the operating systems that must be installed to use the various editions or components of Microsoft SQL Server 2000.

SQL Server edition or component | Operating system requirement
Enterprise Edition | Microsoft Windows NT Server 4.0, Microsoft Windows NT Server Enterprise Edition 4.0, Windows 2000 Server, Windows 2000 Advanced Server, and Windows 2000 Data Center Server. Note that Microsoft Windows 2000 Server (any version) is required for some SQL Server 2000 features.
Standard Edition | Microsoft Windows NT Server 4.0, Windows 2000 Server, Microsoft Windows NT Server Enterprise Edition, Windows 2000 Advanced Server, and Windows 2000 Data Center Server.
Personal Edition | Microsoft Windows Me, Windows 98, Windows NT Workstation 4.0, Windows 2000 Professional, Microsoft Windows NT Server 4.0, Windows 2000 Server, and all the more advanced Windows operating systems.
Developer Edition | Microsoft Windows NT Workstation 4.0, Windows 2000 Professional, and all other Windows NT and Windows 2000 operating systems.
Desktop Engine | Microsoft Windows Me, Windows 98, Windows NT Workstation 4.0, Windows 2000 Professional, Microsoft Windows NT Server 4.0, Windows 2000 Server, and all the more advanced Windows operating systems.
Client Tools Only | Microsoft Windows NT 4.0, Windows 2000 (all versions), Windows Me, and Windows 98.
Connectivity Only | Microsoft Windows NT 4.0, Windows 2000 (all versions), Windows Me, Windows 98, and Windows 95.

Note Microsoft Windows NT® Server 4.0, Service Pack 5 (SP5) or later must be installed as a minimum requirement for all SQL Server 2000 editions.

SQL Server 2000 is not supported on Windows NT 4.0 Terminal Server.

For installations of SQL Server 2000 Personal Edition or Desktop Engine on Windows 98 computers without a network card, Windows 98 Second Edition is required.

Internet Requirements

This table shows Internet requirements related to using Microsoft SQL Server 2000.

Component | Requirement
Internet software | Microsoft Internet Explorer 5.0 is required for all installations of Microsoft SQL Server 2000, as it is required for Microsoft Management Console (MMC) and HTML Help. A minimal install is sufficient, and Internet Explorer is not required to be the default browser. Exception to the Internet Explorer 5.0 requirement: If using the Connectivity Only option and not connecting to a server that requires encryption, Microsoft Internet Explorer 4.01 with Service Pack 2 is sufficient.
Internet Information Services | If writing XML applications, see System Requirements for the IIS Virtual Directory Management for SQL Server Utility.

Network Software Requirements

Microsoft Windows NT, Windows 2000, Windows Me, Windows 98, and Windows 95 have built-in network software. Additional network software is required only if you are using Banyan VINES or AppleTalk ADSP. Novel NetWare IPX/SPX client support is provided by the NWLink protocol of Windows Networking.

Note TCP/IP must be enabled at the operating system level before installing SQL Server 2000. For more information, see Network Libraries.

Supported Clients

Microsoft SQL Server 2000 supports the following clients: Windows NT Workstation, Windows 2000 Professional, Windows 98, Windows 95, Apple Macintosh®, OS/2, and UNIX. Macintosh, OS/2, and UNIX do not support the SQL Server graphical tools and require ODBC client software from a third-party vendor.

Considerations for Other Microsoft Products

The following Microsoft products require Service Release or Service Packs to operate correctly with SQL Server 2000.

Access 2000

Microsoft Access 2000 requires the installation of either Microsoft Office 2000 Service Release 1 (SR1) or Access 2000 SR1 to operate correctly with SQL Server 2000. If running an earlier version of Access 2000, you cannot test automatic data processing (ADP) applications against SQL Server 2000. You cannot access database diagrams, stored procedures, table designs, or view designs.

Other issues to be addressed in a future Access Service Release:

  • When you run Access 2000 with SR1, you can test ADP applications. You can also alter database diagrams, stored procedures, table designs, or view designs, but you cannot save any changes. A future Access Service Release will allow limited ability to save changes.

  • The Access 2000 Create Database Wizard cannot successfully create a SQL Server 2000 database. You can work around this by first creating the database using SQL Server Enterprise Manager, and then creating an ADP for the database using the Project (Existing Database) option on the New dialog box in Access 2000.

  • The Access 2000 Upsizing Wizard does not support upsizing to SQL Server 2000. You can work around this by using Data Transformation Services in the Enterprise Manager to import your MDB database file into SQL Server. You can then rename your MDB tables and create linked tables to the resulting SQL Server database with the same names as your original MDB table names.
Visual Studio 6.0

When you run Microsoft Visual Studio® 6.0, you cannot access database diagrams, stored procedures, table designs, or view designs in SQL Server 2000. Visual Studio 6.0 Service Pack 4 allows you to alter database diagrams, stored procedures, table designs, or view designs, but you cannot save them. A future Visual Studio Service Pack will allow a limited ability to save changes.

The SQL Server 2000 tools cannot access database diagrams saved using the design tools in Visual Studio 6.0 until you have modified the dtproperties table in the database. For more information, see Backward Compatibility.

See Also

Editions of SQL Server 2000

SQL Server 2000: Editions and Components

Operating Systems Supported by the Editions of SQL Server 2000


SQL Server 2000: Editions and Components

SQL Server 2000 editions include the Enterprise Edition, the Standard Edition, the Personal Edition, the Developer Edition, and the Evaluation Edition.

Note The Microsoft SQL Server 2000 Personal Edition replaces the Microsoft SQL Server version 7.0 Desktop Edition. To install client tools only, you can use the Personal Edition, which is also available when you purchase the Standard and Enterprise Editions of SQL Server 2000.

When you select SQL Server 2000 Components on the opening screen, three options appear on the Install Components screen:

Install Database Server

Starts SQL Server Setup, with screens for selecting installation options.

Install Analysis Services

Installs Analysis Services on computers processing OLAP cubes. For more information, see Installing Analysis Services.

Install English Query

Installs English Query on computers running English Query applications. For more information, see Installing English Query.

Choosing Components and Options to Install

You may have a database server, an Internet server, or require a database on a client computer. If running database client/server applications you may or may not require a database on your computer. You may need tools to administer a database server, or you may want to run applications that access an instance of SQL Server. Installation choices for these and other SQL Server configurations are described in the following paragraphs.

Installing SQL Server on a Database Server

If installing a database server, install either SQL Server 2000 Enterprise Edition or SQL Server 2000 Standard Edition. If installing a personal database on your workstation, install SQL Server 2000 Personal Edition. These installations typically include the database engine, the client database management tools, and the client connectivity components.

On a database server, you can install a default instance of SQL Server 2000 relational database engine. You can also install one or more named instances of the SQL Server 2000 database engine. Other than specifying an instance name, the setup choices are similar to those for installing a default instance.

When installing an instance of SQL Server 2000, you must specify whether you want the instance to use failover clustering. For more information, see Before Installing Failover Clustering.

Using SQL Server with Client/Server Applications

For a computer running database client/server applications, such as Microsoft Visual Basic® applications that connect directly to an instance of SQL Server, you have several options:

  • If you require a personal database on your client computer, install the Personal Edition of SQL Server. This setup typically installs the client tools and client connectivity components along with the database engine.

  • If you do not require a database on your computer, but need to administer an instance of SQL Server on a database server, or plan to develop SQL Server applications, install the option for Client Tools Only. This option includes the client connectivity components. For more information, see How to install client tools only (Setup).

  • If you want to only run applications that access instances of SQL Server on database servers, install the connectivity only components. For more information, see How to install connectivity only (Setup).
Using SQL Server with an Internet Server

On an Internet server, such as a server running Microsoft Internet Information Services (IIS), you typically install the SQL Server 2000 client tools. Client tools include the client connectivity components used by an application connecting to an instance of SQL Server. In addition, the client tools include the utility for configuring the virtual roots needed for applications to access SQL Server through URLs.

After installing the SQL Server client tools, you configure the virtual roots that support accessing an instance of SQL Server through a URL. For more information about configuring the virtual roots, see Using IIS Virtual Directory Management for SQL Server Utility.

Note Although you can install an instance of SQL Server on a computer running IIS, this is typically done only for small Web sites that have a single server computer. Most Web sites have their middle-tier IIS system on one server or cluster of servers, and their databases on a separate server or federation of servers. For more information about federations, see Federated SQL Server 2000 Servers.

If some of the Web pages on an Internet server use English Query, you would also install that component.

Other SQL Server Components
  • For distributing SQL Server 2000 with applications, use the SQL Server 2000 Desktop Engine, a stand-alone database engine that independent software vendors can package with their applications. For more information, see Distributing SQL Server Applications Overview.

  • Note The Desktop Engine has no graphical user interface and is not related to the SQL Server 7.0 Desktop Edition.

In addition to the major components and editions shown on the Install SQL Server 2000 Components screen, other editions of SQL Server 2000 are available: SQL Server 2000 Developer Edition, SQL Server 2000 Windows CE Edition, and the SQL Server 2000 Enterprise Evaluation Edition. For more information, see Features Supported by the Editions of SQL Server 2000.

See Also

Editions of SQL Server 2000

Operating Systems Supported by the Editions of SQL Server 2000


Installing English Query

English Query is a development tool that works with Microsoft® SQL Server™ 2000. Using English Query, you can create applications that allow users to query a SQL Server database or an Analysis Services database in English. For example, users can ask, "How many widgets were sold in Washington last year?" instead of using the SQL statements:

SELECT sum(Orders.Quantity) FROM Orders, Parts
WHERE Orders.State='WA'
   AND Datepart(Orders.Purchase_Date,'Year')='1999'
   AND Parts.PartName='widget'
   AND Orders.Part_ID=Parts.Part_ID

When you install English Query, English Query is added to the Microsoft SQL Server program group on the Start menu. English Query contains these shortcuts:

  • English Query Books Online

  • English Query Tutorials

  • Microsoft English Query

If English Query is not installed with Microsoft SQL Server 2000, the Help system will access English Query Books Online, Eqdoc.chm, instead of SQL Server Books Online, SQL80.col. However, both documentation files contain essentially the same material about English Query and both provide context-sensitive (F1) Help for English Query. Regardless of the installation scenario, English Query Books Online is available from the English Query program group.

Installation Requirements for English Query are:

  • Microsoft Windows® 95, Microsoft Windows 98, or Microsoft Windows NT® version 4.0 or later

  • 40 MB of free disk space

  • Microsoft Internet Explorer 5.0 or later

To install English Query

SQL Setup

SQL Setup

See Also

English Query Overview


Installing Analysis Services

Microsoft® SQL Server™ 2000 Analysis Services includes a powerful server for the construction and analysis of multidimensional data.

To install Analysis Services

SQL Setup

SQL Setup

See Also

Analysis Services Overview


Setting up Windows Services Accounts

On the Microsoft® Windows NT® and Microsoft Windows® 2000 operating systems, Microsoft SQL Server™ and SQL Server Agent are started and run as Windows services. These services appear in the list of installed services in the Services dialog box, available using Windows Control Panel. The table shows each service name and the term used to refer to the default and named instances of SQL Server, as displayed in the Services dialog box.

Service | Name | Term for default instance | Term for named instance
Microsoft SQL Server | SQL Server | MSSQLSERVER | MSSQL$InstanceName
Microsoft SQL Server Agent | SQL Server Agent | SQLSERVERAGENT | SQLAgent$InstanceName

For Microsoft SQL Server™ and SQL Server Agent to run as services in Windows, they must be assigned a Windows user account. Typically, both SQL Server and SQL Server Agent are assigned the same user account, either the local system or domain user account. However, you can customize the settings for each service during the installation process. For more information about how to customize account information for each service, see Services Accounts.

The Microsoft Search service (full-text search) must always run under the local system account.

Note Microsoft Windows 98 does not support Windows services; instead, SQL Server simulates the SQL Server and SQL Server Agent services. It is not required that you create user accounts for these simulated services.

Using the Local System Account

The local system account does not require a password, does not have network access rights in Windows NT 4.0 and Windows 2000, and restricts your SQL Server installation from interacting with other servers.

Using a Domain User Account

A domain user account uses Windows Authentication, that is, the same user name and password used to connect to the operating system is also used to connect to SQL Server. A domain user account is typically used because many server-to-server activities can be performed only with a domain user account, for example:

  • Remote procedure calls.

  • Replication.

  • Backing up to network drives.

  • Heterogeneous joins that involve remote data sources.

  • SQL Server Agent mail features and SQL Mail. This restriction applies if using Microsoft Exchange. Most other mail systems also require clients (the SQL Server and SQL Server Agent services) to be run on accounts with network access.

Note Several servers running SQL Server can share the same user account. When setting up replication, it is recommended that a Publisher and all its Subscribers share the same service account for the SQL Server service.

Requirements for Domain User Account

All domain user accounts must have permission to:

  • Access and change the SQL Server directory (\Program Files\Microsoft SQL Server\Mssql).

  • Access and change the .mdf, .ndf, and .ldf database files.

  • Log on as a service.

  • Read and write registry keys at and under:
    • HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer.
      -or- for any named instance: HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server.

    • HKEY_LOCAL_MACHINE\System\CurrentControlset\Services\MSSQLServer.
      -or- for any named instance: HKEY_LOCAL_MACHINE\System\CurrentControlset\Services\MSSQL$Instancename.

      HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Perflib.

In addition, a domain user account must be able to read and write corresponding registry keys for these services: SQLAgent$InstanceName, MSSearch, and MSDTC.

This table shows additional permissions required for certain functionality.

Service | Permission | Functionality
SQL Server | Network write privileges | Write to a mail slot using xp_sendmail.
SQL Server | Act as part of operating system and replace a process level token | Run xp_cmdshell for a user other than a SQL Server administrator.
SQL Server Agent | Member of the Administrators local group | Create CmdExec and ActiveScript jobs belonging to someone other than a SQL Server administrator. Use the autorestart feature. Use run-when-idle jobs.
SQL Server | Member of local Power Users or local Administrators group | Add and delete SQL Server objects in the Windows 2000 Active Directory.

Changing User Accounts

To change the password or other properties of any SQL Server–related service after installing SQL Server, use SQL Server Enterprise Manager. If your Windows password expires and you change it, be sure to also revise the SQL Server services settings in Windows. For more information, see Changing Passwords and User Accounts.

See Also

Creating Security Accounts

Planning Security

Services Accounts


File Paths for SQL Server 2000

In Microsoft® SQL Server™ 2000, the default location for the installed SQL Server files has changed. For the default instance of SQL Server, the default directory for both program and data files is \Program Files\Microsoft SQL Server\Mssql. You can specify a file path other than the default for both program and data files.

Shared Tools are installed by default at \Program Files\Microsoft SQL Server\80\Tools. This folder contains files shared by all instances of SQL Server 2000, both default and named. Tools include SQL Server Books Online, Dev Tools, and other components.

Setup also installs files in the Microsoft Windows® system directory. The system file location cannot be changed.

SQL Server Program File Location

The SQL Server program files are located in \Program Files\Microsoft SQL Server\Mssql\Binn.

The program file location is the root directory where Setup creates the folders that contain program files and files that typically do not change as you use SQL Server. Although these files are not read-only, the folders do not contain data, log, backup files, or replication data; therefore, the space requirements for these files should not increase as SQL Server is used.

Note Program files cannot be installed on a removable disk drive.

SQL Server Data File Location

The SQL Server data files are located in \Program Files\Microsoft SQL Server\Mssql\Data.

The data file location is the root directory where Setup creates the folders that contain database and log files, as well as directories for the system log, backup, and replication data. Setup creates database and log files for the master, model, tempdb, msdb, pubs, and Northwind databases. The SQL Server data file path should be located on a drive that has space available for these files to grow.

Note Data files cannot be installed on a file system using compression.

Specifying File Paths

In SQL Server 2000, due to multiple instance options, the instance name is used in addition to the user-specified location for program and data files. For tools and other shared files, however, instance names are not required.

Default Instance File Path for Program and Data Files

For the default instance of SQL Server, the default SQL Server directory name (Mssql) is used as the default instance name, along with the directory you specify.

For example, if you specify that the SQL Server default instance be installed at D:\MySqlDir, the file paths are:

  • D:\MySqlDir\Mssql\Binn (for program files)

  • D:\MySqlDir\Mssql\Data (for data files)
Named Instance File Path for Program and Data Files

For any named instances, the given name of the instance is used with the directory specified.

For example, if you specify that the instance named MyInstanceA be installed at D:\MySqlDir, the paths are:

  • D:\MySqlDir\MSSQL$MyInstanceA\Binn (for program files)

  • D:\MySqlDir\MSSQL$MyInstanceA\Data (for data files)

See Also

File Locations for Multiple Instances of SQL Server

Locating Directories and Files


Upgrading an Existing Installation of SQL Server

You can upgrade from earlier versions to Microsoft® SQL Server™ 2000, and also perform upgrade operations once SQL Server 2000 is installed. Upgrades to SQL Server 2000 from SQL Server version 6.5 and from SQL Server version 7.0 are different operations. SQL Server 6.5 databases (and related information) are converted to SQL Server 2000 formats. An installation of SQL Server 7.0 is overwritten by SQL Server 2000, unless a named instance configuration is installed, allowing SQL Server 7.0 to remain intact.

After an initial installation of SQL Server 2000, other upgrade options are available. If using more than one instance of SQL Server 2000, you can upgrade one instance by adding components, and have different component sets for multiple instances.

Upgrading from SQL Server 7.0 to SQL Server 2000

You can overwrite your existing installation of SQL Server 7.0 by installing a default instance of SQL Server 2000. You can also keep your installation of SQL Server 7.0 intact by installing a named instance of SQL Server 2000. Both operations are performed using the following procedure.

To upgrade from SQL Server 7.0 to SQL Server 2000

SQL Setup

SQL Setup

Upgrading Databases from SQL Server 7.0

Instead of a full upgrade from SQL Server 7.0 to SQL Server 2000, which overwrites SQL Server 7.0, you can upgrade SQL Server 7.0 databases and associated meta data. For more information, see Upgrading Databases from SQL Server 7.0 (Copy Database Wizard).

Upgrading from SQL Server 6.5 to SQL Server 2000

After installing Microsoft® SQL Server™ 2000, you can upgrade your SQL Server version 6.5 server configuration and databases using the SQL Server Upgrade Wizard. In this process, SQL Server 6.5 information and data is transferred to a SQL Server 2000 installation. The SQL Server 6.5 installation remains intact on the computer. It can be removed, or kept on the computer and used in a version switch configuration with SQL Server 2000.

Note If you plan to keep SQL Server 6.5 installed alongside an instance of SQL Server 2000 (for version switching purposes), SQL Server Service Pack (SP5) must be applied to SQL Server 6.5 before installing SQL Server 2000.

SQL Server 6.0 to SQL Server 2000 (no direct upgrade)

To upgrade from SQL Server 6.0 to SQL Server 2000, you have two options:

  • Use the SQL Server Upgrade Wizard provided with SQL Server version 7.0 to upgrade from SQL Server 6.0 to SQL Server 7.0, and then use Setup to upgrade from SQL Server 7.0 to SQL Server 2000.

  • Convert the SQL Server 6.0 data to SQL Server 6.5, and then convert the SQL Server 6.5 data to SQL Server 2000.

Note Both data conversions are performed using the SQL Server Upgrade Wizard, although different versions of the Upgrade Wizard are used. The SQL Server 7.0 Upgrade Wizard can upgrade SQL Server 6.0 or SQL Server 6.5 databases to SQL Server 7.0 databases. In SQL Server 2000, the Upgrade Wizard is used only for upgrades from SQL Server 6.5 to SQL Server 2000.

Version and Edition Upgrades

Each of the editions of Microsoft® SQL Server™ 2000 (SQL Server 2000 Enterprise Edition, SQL Server 2000 Standard Edition, SQL Server 2000 Personal Edition, and SQL Server 2000 Developer Edition) comes with its own compact disc and is installed separately.

You can add to the feature set of your installation of Microsoft SQL Server by performing a version and edition upgrade at the same time. For example, if you have purchased Microsoft SQL Server 2000 Standard Edition, you can upgrade from SQL Server 7.0 Desktop Edition to SQL Server 2000 Standard Edition.

Upgrade options between versions and editions of SQL Server are shown in the table.

Installed Version | Can upgrade to
SQL Server 7.0 Desktop Edition1 | SQL Server 2000 Personal Edition SQL Server 2000 Standard Edition
SQL Server 7.0 Standard Edition | SQL Server 2000 Standard Edition SQL Server 2000 Enterprise Edition
SQL Server 7.0 Enterprise Edition | SQL Server 2000 Enterprise Edition
SQL Server 2000 Developer Edition | SQL Server 2000 Enterprise Edition
SQL Server 2000 Standard Edition | SQL Server 2000 Enterprise Edition
SQL Server 2000 Personal Edition | SQL Server 2000 Standard Edition
SQL Server 2000 Enterprise Evaluation Edition2 | SQL Server 2000 Personal Edition SQL Server 2000 Standard Edition SQL Server 2000 Enterprise Edition SQL Server 2000 Developer Edition

  1. SQL Server 7.0 Desktop Edition has been replaced by the SQL Server 2000 Personal Edition; however, you can still perform this type of version and edition upgrade.

  2. When upgrading from SQL Server 2000 Enterprise Evaluation Edition, you cannot upgrade to a SQL Server 2000 failover cluster.

Upgrade options also depend on the operating system used. For more information, see Operating Systems Supported by the Editions of SQL Server 2000.

Upgrading Editions and Components within SQL Server 2000

You can add functionality while upgrading from one edition of SQL Server 2000 to another, and have the option to add components during this upgrade. For example, if you upgrade from the SQL Server 2000 Personal Edition to the SQL Server 2000 Standard Edition, you can install additional components during the upgrade process.

To perform an edition upgrade within SQL Server 2000

SQL Setup

SQL Setup

Adding Components to an instance of SQL Server 2000

You can add components to an existing installation of SQL Server 2000 by selecting the instance of SQL Server to which you want to add features. This method allows you to have different component sets for the default instance and for any named instances.

To add components to an instance of SQL Server 2000

SQL Setup

SQL Setup

See Also

Upgrading to SQL Server 2000: Overview

Existing Installation Options

Select Components

Upgrading to a SQL Server 2000 Failover Cluster

Upgrading Databases from SQL Server 6.5 (Upgrade Wizard)


Basic Installation Options

This section describes basic installation options for SQL Server 2000. Upgrading an existing installation, or creating a new installation on either a local or remote computer is considered a basic installation option.

For more information about cluster maintenance, performing an unattended setup, or rebuilding the registry, see Advanced Installation Options.


Entering Information in Basic Setup Screens

Microsoft® SQL Server™ 2000 Setup provides basic and advanced options. There are two options for a local installation:

  • Create a new or additional installation

  • Upgrade, remove, or add components to an existing installation

If you choose the upgrade option, you have many other choices available. For more information, see Existing Installation Options. In addition, you can select advanced options. For more information about your initial setup choices, see Installation Selection.

For a basic, local installation, select the option for creating a new or additional installation. After entering user and product identification (ID) information in subsequent screens, choose the components to include in this installation of SQL Server 2000. You can select to install either connectivity only, client tools only (which includes connectivity components), or the complete server and client tools option. For more information, see Installation Definition.

If you choose to install the SQL Server relational database with both server and client tools, select either a named instance or the default instance of SQL Server 2000. For more information, see Instance Name.

After selecting the default instance, or choosing to create a named instance, the standard setup type selection screen is presented. For more information, see Setup Type: Typical, Minimum, or Custom.

Other options may be presented while running Setup, depending on the specifics of your system and installation.

See Also

Upgrading an Existing Installation of SQL Server

Multiple Instances of SQL Server


Computer Name

The Computer Name dialog box in Setup allows you to install Microsoft SQL Server 2000 on your local computer, on a remote computer, or on a virtual server.

All options for installing and upgrading are available on the local computer. Advanced options, including registry rebuild, unattended installation, and upgrading to a cluster are not available on a remote installation. If you are running Setup on a clustered computer, the Virtual Server option is available.

Options

Local Computer

By default, the name in the edit box is the local machine name, that is, the computer on which Setup is running. For a local installation, accept the default and click Next.

Note If you are installing tools only, Local Computer will be the only option available on this dialog box.

Remote Computer

Enter a computer name for a remote installation, or click Browse to locate the remote computer.

Virtual Server

Enter the name of a new or existing Virtual SQL Server to manage.

This option is available only when Microsoft Cluster Service (MSCS) is detected on an Windows NT or Windows 2000 Enterprise operating system.

Browse

Click the Browse button to locate a remote computer.

This button is available only when the Remote Computer option is selected.

See Also

Installing a Remote Configuration

Installing a Virtual Server Configuration

Before Installing Failover Clustering

Creating a Failover Cluster


Installation Selection

The Installation Selection screen is an initial screen in Microsoft® SQL Server™ Setup, where you select among three options for running the installation program.

Options

Create a new instance of SQL Server, or install Client Tools

Creates a new installation of SQL Server 2000; either a default or named instance. In addition, this option allows you to install only client tools using the compact disc for any edition of SQL Server 2000, on any operating system other than Microsoft Windows® 95.

Upgrade, remove, or add components to an existing instance of SQL Server

Allows you to upgrade, remove, or add components to an existing instance of SQL Server. Existing instances include installations of earlier versions (SQL Server version 6.5 and SQL Server version 7.0) as well as instances of SQL Server 2000. For more information, see Existing Installation Options.

Advanced Options

Select advanced options for cluster maintenance, unattended setup, and registry rebuild.

See Also

Multiple Instances of SQL Server

Upgrading an Existing Installation of SQL Server

Advanced Installation Options


Existing Installation Options

The Existing Installation Options Setup screen includes choices for working with upgrades from previous versions of Microsoft® SQL Server™, as well as upgrades to SQL Server 2000 components. Options that do not apply to your specific setup do not appear on the screen.

Options

Add components to your existing installation

Allows you to add components to an existing installation of SQL Server 2000.

Uninstall your existing installation

Removes an installation (default or named instance) of SQL Server 2000 from your computer. The instance to remove is specified in the Instance Name screen.

Upgrade your existing installation

This option is available for use with existing installations of SQL Server 7.0 and SQL Server 2000. Depending on the version, edition, and component makeup of your existing installation, selecting this option starts the process for one of the following upgrades:

  • Upgrade from SQL Server 7.0 to SQL Server 2000. (If you cannot upgrade client tools, see Upgrade Issues below.)

  • Add components to an existing installation of SQL Server 2000. For example, you may have purchased a SQL Server version with more features, or need to install certain components.

Note Upgrades from SQL Server 6.5 to SQL Server 2000 are run using the SQL Server Upgrade Wizard, available on the SQL Server Start menu.

Upgrade your existing installation to a clustered installation

This option is a step in the process of upgrading from a clustered installation of SQL Server 6.5 or SQL Server 7.0 to a clustered installation of SQL Server 2000. First, the earlier version of SQL Server is upgraded to SQL Server 2000. Next, the existing SQL Server 2000 installation can be upgraded to a cluster. For more information, see Upgrading to a SQL Server 2000 Failover Cluster.

Upgrade Issues
  • On a computer running SQL Server 7.0 client tools only, you may encounter the following message when you choose to upgrade your existing installation: "The default instance detected is not able to be upgraded. Please select New Install to upgrade your tools." This issue can occur if you have installed the SQL Server 7.0 client tools by choosing Custom in the Setup Type dialog box, and then by selecting tools in the components dialog box. In this situation, the existing client tools installation of SQL Server 7.0 cannot be upgraded due to registry issues. Instead, you must re-install SQL Server, by selecting Create a new instance of SQL Server, or install Client Tools.

  • You can upgrade a beta version of SQL Server 2000 to the final version of the product by using the option to upgrade your existing installation. If you are performing such an upgrade on a computer or a cluster containing multiple instances, you must first close all instances of SQL Server before upgrading.

See Also

Upgrading from SQL Server 7.0 to SQL Server 2000

Upgrading an Existing Installation of SQL Server

Select Components


Installation Definition

Use the Installation Definition screen to select the components to include in this installation of SQL Server 2000. If you select Client Tools Only or Connectivity Only, Setup proceeds and no additional choices are required, unless you select components when installing client tools. If you choose to install Server and Client Tools, additional setup screens will appear.

Options

Client Tools Only

Installs only the client relational database management tools. Included in this option are the client tools for administering SQL Server and the client connectivity components. In addition, this option allows you to select other components to install. For more information, see How to install client tools only (Setup).

Server and Client Tools

Installs both server and client tools to create a relational database server with administrative capabilities. Selecting Server and Client Tools presents the full range of additional setup options.

For more information about performing a typical installation of a default instance of the database engine, including all client and connectivity components, see How to install SQL Server 2000 (Setup).

Note This option is not available if you are installing client tools using a compact disc for an edition of SQL Server that is not supported by your computer's operating system.

Connectivity Only

Installs only the relational database client connectivity components, including MDAC 2.6 (Microsoft Data Access Components), a requirement for connecting to SQL Server 2000 named instances. This option provides connectivity tools only, with no choice of client tools or other components. For more information, see How to install connectivity only (Setup).

See Also

Management Tools

Server Components

Client Connectivity


User Information

The User Information Setup screen prompts you to supply your name and company name. These fields are required.

When installing on a network, be sure to supply the name of a user responsible for using or administering the server.

See Also

Setting Up Windows Services Accounts


Instance Name

Use this screen to add and maintain instances of Microsoft® SQL Server™ 2000.

Options

Default

  • When selected, a default instance of SQL Server 2000 is installed. Click Next to proceed with the install process.

  • When cleared, you can install or maintain a named instance of SQL Server 2000.

Note If this check box is not enabled, Setup has detected a default instance of SQL Server on this computer. The default instance could be an installation of SQL Server 6.5, SQL Server version 7.0, or it could be the default instance of SQL Server 2000, already installed. Only one installation of SQL Server, any version, can be the default instance at any one time. For more information, see Multiple Instances of SQL Server.

Instance Name

Enter a new instance name, or the name of the instance to maintain. Review and follow the rules for instance names.

Important It is recommended that instance names be kept to less than 10 characters. Instance names can appear in the user interface of various SQL Server and system tools; shorter names are more readable.

Instance Naming Rules

  • An instance name is not case-sensitive.

  • An instance name cannot be the terms Default or MSSQLServer.

  • Instance names must follow the rules for SQL Server identifiers and cannot be reserved keywords.

  • Instance names are limited to 16 characters.

  • The first character in the instance name must be a letter, an ampersand (&), an underscore (_), or a number sign (#). Acceptable letters are those defined by the Unicode Standard 2.0, which includes Latin characters a-z and A-Z, in addition to letter characters from other languages.

  • Subsequent characters can be:
    • Letters as defined in the Unicode Standard 2.0.

    • Decimal numbers from either Basic Latin or other national scripts.

    • The dollar sign ($), a number sign (#), or an underscore (_).
  • Embedded spaces or special characters are not allowed in instance names. Neither is the backslash (\), a comma (,), a colon (:), or the at sign (@).

Warning Only characters that are valid in the current Microsoft Windows® code page can be used in instance names in SQL Server 2000. If a Unicode character not supported under the current code page is used, an error occurs.

See Also

Working with Instances and Versions of SQL Server

Working with Named and Multiple Instances of SQL Server 2000

Naming Conventions for Instances of SQL Server 2000

Reserved Keywords


Backward Compatibility

New Information - SQL Server 2000 SP3.

The topics in this section describe changes included in SQL Server 2000 Service Pack 3 (SP3).

Topic | Description
Backward Compatibility for Full-Text Search/Microsoft Search | Provides backward compatibility details for Full-Text Search/Microsoft Search in SP3
Backward Compatibility for Multiserver Administration | Provides backward compatibility details for master/target server configurations in SP3
Backward Compatibility for Cross-Database Ownership Chaining | Provides backward compatibility details for cross-database ownership chaining in SP3


Backward Compatibility for Full-Text Search/Microsoft Search

New Information - SQL Server 2000 SP3.

The Microsoft Search catalog format is upgraded in Microsoft SQL Server 2000 Service Pack 3 (SP3) to improve consistency in the rank values returned by queries using the CONTAINSTABLE and FREETEXT full-text predicates.

Upgrading the Microsoft Search catalog format requires that all full-text catalogs be rebuilt. The rebuild is performed automatically when Microsoft Search service starts, immediately after SP3 setup completes, and may be a time- and resource-intensive process. During the rebuild, full-text functionality may be only partially available.

Note The rebuild operation only occurs the first time that any instance of SQL Server 2000 on the computer is upgraded to Service Pack 3. If several instances of SQL Server 2000 exist on the same computer, all catalogs from all instances of SQL Server are rebuilt to the new format, not just the full-text catalogs associated with the instance of SQL Server that is being upgraded to SP3.

After SP3 is installed, the system event logs will contain messages stating that the catalogs were corrupt, were of an older version, and had to be rebuilt. Microsoft Search rebuilds these catalogs and upon completion returns another message about the success or failure of the rebuild operation.

If the catalog rebuild process does not complete successfully, the system event log will contain a message that the crawl stopped or failed. Crawl is the process of rebuilding and repopulation of the full-text catalogs. When the message states that a crawl failed, drop and recreate all full-text catalogs.

Here is an example of a log that illustrates these messages:

Event Type:   Information
Event Source:   Microsoft Search
Event Category:   Search Service
Event ID:   1003
Date:      7/24/2002
Time:      5:26:51 PM
User:      N/A
Computer:   FTS8
Description:
The Search service has started.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type:   Information
Event Source:   MssCi
Event Category:   None
Event ID:   4138
Date:      7/24/2002
Time:      5:26:51 PM
User:      N/A
Computer:   FTS8
Description:
Content index corruption detected in component CI-RcovStorageObj1 in catalog e:\ft\SQL0000800005\Build\Indexer\NlFiles. Stack trace is
  0x01045027
  0x0104BE13
  0x010469E0
  0x0104D0CD
  0x01048477
  0x013BCE70
  0x013B9D9F
  0x013BA645
  0x009F4251
  0x009F450D
  0x0138CE4C
  0x0138E1D0
  0x00A32783
  0x00A2247A
  0x00A99965
  0x00AA5BDC
  0x77E8758A

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type:   Error
Event Source:   Microsoft Search
Event Category:   Indexer
Event ID:   7039
Date:      7/24/2002
Time:      5:26:51 PM
User:      N/A
Computer:   FTS8
Description:
The Content Index for project <SQLServer SQL0000800005> cannot be loaded. Error: c0041821 - The content index data on disk is for the wrong version.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type:   Information
Event Source:   Microsoft Search
Event Category:   Gatherer
Event ID:   3041
Date:      7/24/2002
Time:      5:26:51 PM
User:      N/A
Computer:   FTS8
Description:
Project <SQLServer SQL0000800005> is being reset.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type:   Information
Event Source:   Microsoft Search
Event Category:   Gatherer
Event ID:   3018
Date:      7/24/2002
Time:      5:26:53 PM
User:      N/A
Computer:   FTS8
Description:
The end of crawl for project <SQLServer SQL0000800005> has been detected. The Gatherer successfully processed 0 documents totaling 0K. It failed to filter 0 documents. 0 URLs could not be reached or were denied access.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

For more information, see Knowledge Base article Q327217.

Types of Upgrade

To minimize the impact of a rebuild on database operations, consider the following variations to the upgrade process:

Default upgrade

A default upgrade takes place automatically after SP3 setup finishes. Use the default upgrade if the total size of all full-text catalogs is less than 100,000 rows and there are ample system resources available after SP3 setup.

Side-by-side upgrade

A side-by-side upgrade helps avoid significant periods in which full-text functionality will not be fully available during the rebuild process. This upgrade also minimizes resource usage after the upgrade to SP3. Use side-by-side upgrade if the total size of all full-text catalogs being upgraded is greater than 100,000 rows and the rebuild process may take up to an hour or more, depending on available hardware and system resources. For a complete side-by-side upgrade, all catalogs from all instances of SQL Server 2000 on the computer should be included. For more information, see Side-by-Side Upgrade, below.

Manual upgrade

A manual upgrade minimizes resource usage following upgrade to SP3 by allowing full-text catalogs to be added and populated during off-peak periods. However, the total amount of catalog downtime while manually rebuilding full-text catalogs may be greater than for a side-by-side upgrade. Perform a manual upgrade when it is more important for the server to be available soon after the SP3 upgrade, than it is for the full-text catalogs. For more information, see Manual Upgrade, below.

Side-by-Side Upgrade

A side-by-side upgrade requires a production computer and a backup development computer. The production computer is the computer running the instance of SQL Server to be upgraded; the backup development computer contains a replica of the production computer.

Before you upgrade, back up all SQL Server databases on the production computer. This backup will be used to create an image of the production computer on the development computer. For more information on creating and maintaining a development computer, see "Using Standby Servers" in SQL Server 2000 Books Online.

In addition, if change tracking is enabled on the production computer, disable background index update and any other scheduled updates. Leave intact any scheduled full or incremental populations.

To perform a side-by-side upgrade

  1. Restore the previously created database backup to the development computer. Ensure that the database identifiers are the same between the production computer and the development computer. For more information on how to move, copy, and back up full-text catalog folders and files, search the Knowledge Base.

  2. Because a database backup does not include full-text catalogs, execute the following system stored procedure for each full-text catalog so that the catalogs are created and populated on the development computer.
    EXEC sp_fulltext_catalog 'fulltext_catalog_name', 'rebuild'
GO
EXEC sp_fulltext_catalog 'fulltext_catalog_name', 'start_full'
GO
  3. Apply SP3 to the development computer to upgrade the full-text catalog data.

  4. When the rebuild process completes on all full-text catalogs on the development computer, copy these full-text catalogs to a secure location on the production computer.

    Important Do not overwrite existing full-text catalogs that are in the production computer at this time.

    For more information on how to move, copy, and back up full-text catalog folders and files, search the Knowledge Base.

  5. Apply SP3 to the production computer. After the upgrade to SP3 is complete, stop the Microsoft Search service.

    If the automatic rebuilding of the catalogs has started, stop the process for each catalog by executing the following system stored procedure.

    EXEC sp_fulltext_catalog 'fulltext_catalog_name', 'stop'
GO
  6. On the production computer, replace existing catalogs with the rebuilt catalogs that were copied from the development computer.

  7. Start the Microsoft Search service.

    If change tracking is enabled on the production computer, manually update change tracking on all full-text enabled tables by executing the following system stored procedure.

    EXEC sp_fulltext_table '%tablename%', 'update_index'
GO

    You do not need to rebuild any full-text catalog. In addition, if you turned off background index update or scheduled updates before starting the side-by-side upgrade, turn on these options.

Manual Upgrade

A manual upgrade selectively rebuilds full-text catalogs separately from the upgrade to SP3.

Before you upgrade an instance of SQL Server on the production computer to SP3, execute the following system stored procedures and record the result set.

EXEC sp_help_fulltext_catalogs
EXEC sp_help_fulltext_columns

You will use the information returned by these stored procedures when you recreate full-text catalogs following the upgrade.

To perform a manual upgrade

  1. Drop all full-text indexed tables and full-text catalogs, in that order, using the sp_fulltext_table and sp_fulltext_catalog system stored procedures, respectively.

  2. Perform a full backup of SQL Server data.

  3. Apply SP3. During the setup process, ignore the warning message that all full-text catalogs will be rebuilt. (You already dropped these catalogs.)

  4. Recreate all full-text catalogs using the sp_fulltext_catalog system stored procedure.

  5. Add all previously indexed tables and columns to their original full-text catalogs, and start a full population on all full-text catalogs.

  6. For more information, see Knowledge Base article Q327217.


Backward Compatibility for Multiserver Configurations

New Information - SQL Server 2000 SP3.

Multiserver administration is the process of automating administration tasks across multiple instances of SQL Server. Use multiserver administration if you manage two or more servers and you want to centralize maintenance tasks.

In SQL Server 2000 SP3, the SQL Server Agent service account does not need to be a Windows administrator, unless you need to use the SQL Server Agent Proxy Account. The SQL Server Agent service account must be a member of the sysadmin fixed server role.

With multiserver administration, you must have at least one master server and at least one target server. A master server distributes jobs to and receives events from target servers. A master server stores the central copy of job definitions for jobs that run on target servers. Target servers connect periodically to their master server to update their list of jobs to perform. If a new job exists, the target server downloads the job and disconnects from the master server. After the target server completes the job, it reconnects to the master server and reports the status of the job.

Before you apply SP3, you must complete several steps to upgrade your SQL Server 2000 master/target server configuration. The changes that are introduced with SP3 are not compatible with SQL Server 7.0 target servers, or with any servers not running SQL Server 2000 SP3. This is a change from the original SQL Server 2000 functionality.

To upgrade your master/target server configuration

  1. Create a new master server (MSX) account on your master server. This is to prepare the target server or servers (TSX) for the upgrade. To do this, run the following commands.
    --Option A: Windows Authentication
EXEC sp_grantlogin 'DOMAIN\user'
--Option B: SQL Server Authentication – see detailed explanation below
EXEC sp_addlogin 'MSXAccount', 'MSXAccountPassword', 'msdb'
GO
USE msdb
GO
EXEC sp_adduser 'MSXAccount'
GO
EXEC sp_addrolemember 'TargetServersRole', 'MSXAccount'
GO

    You have the following options when choosing an MSX account:

    • Windows Authentication. This is the most secure option, as passwords do not need to be stored, and SQL Server and SQL Server Agent can be configured without local Windows administrator rights.

    • SQL Server Authentication. This requires the SQL Server Agent service accounts to have local Window administrator rights. The reason for this is that SQL Server stores the user name and password as an LSA (local security authority) secret, and access is restricted to local Windows administrators. You may create an account for all target servers, or one account per target server.

    Do not specify a SQL Server Agent probe account (<machine_name>_msx_probe_login). As part of the upgrade to SP3, SQL Server removes the old probe accounts because the target servers no longer use them.

  2. Upgrade your target servers to SP3 one at a time. (Before you apply the service pack, see Step 3 for more information about timing your upgrade.)

  3. To minimize downtime, run the extended stored procedure xp_sqlagent_msx_account on each target server shortly after the SP3 update is completed. For more information, see xp_sqlagent_msx_account below.

  4. Apply SP3 to your master server. The SP3 setup program removes the old _msx_probe accounts, as the target server(s) will not use these accounts any more. If an account own SQL Agent jobs, the account will not be removed, and you need to change the owner of the job(s) to another user and manually remove these accounts. If you want to continue to use the old _msx_probe account(s) that own SQL Agent jobs, you may need to change the password of the _msx_probe account.

SP3 includes a new extended stored procedure that allows you to configure the account that the SQL Server Agent target server uses to download instructions from an master server. This account is known as the MSX account or master server account.

xp_sqlagent_msx_account

The xp_sqlagent_msx_account extended stored procedure sets or retrieves the SQL Server Agent MSX account user name and password to or from the LSA (local security authority) secrets on the target server. Execute permissions of this extended stored procedure are restricted to the securityadmin fixed server role.

SQL Server Agent must be running to execute this extended stored procedure. In addition, if the account specified is a SQL Server login, SQL Server Agent must have local Windows administrator rights. The reason for this is that SQL Server Agent stores the user name and password as an LSA secret, and access is restricted to local Windows administrators.

Syntax

xp_sqlagent_msx_account

{N'GET' |

N'SET' | N'DEL', N'MSX_domain_name', N'MSX_username', N'MSX_password'

}

Arguments

N'GET'

Retrieves the current SQL Server Agent MSX account. N'GET' is an nvarchar with no default. The password is not reported for security reasons.

N'SET'

Sets the account to be used as the SQL Server Agent MSX account. Use the MSX_username, and MSX_password parameters to specify the account to use as the SQL Server Agent MSX account. N'SET' is an nvarchar with no default.

N'DEL'

Deletes the SQL Server Agent MSX account.

MSX_domain_name

Reserved for future use.

MSX_username

The name of the Windows account to be used as the SQL Server Agent MSX account. Specify an empty string for this parameter and MSX_password to select Windows security. In this case, the SQL Server Agent service account credentials are used to log on to the MSX server. MSX_username is an nvarchar with no default.

MSX_password

The password for the SQL Server account specified in MSX_username. Specify an empty string for this parameter and the MSX_username to select Windows security. In this case, the SQL Server Agent service account credentials are used to log in to the MSX server. MSX_password is an nvarchar with no default.

Note Parameters for xp_sqlagent_msx_account must be specified in order. Named parameters cannot be used.

Return Code Values

0 (success) or 1 (failure)

When xp_sqlagent_msx_account fails and returns 1, SQL Server generates an error message with information about the error.

Result Sets

If a SQL Server Agent MSX account has been set, xp_sqlagent_msx_account returns a result set with the following information when you specify N'GET'.

Column | Data type | Description
domain | sysname | N/A. Reserved for future use.
username | sysname | Account used as the SQL Server Agent MSX account.

If a SQL Server Agent MSX account has not been set, or if N'SET' is specified, no result set is returned.

Permissions

Execute permissions for xp_sqlagent_msx_account default to members of the securityadmin fixed server role.

Examples
  1. Retrieve the currently assigned SQL Server Agent MSX account

This example retrieves the account currently assigned for use as the SQL Server Agent MSX account.

EXEC master.dbo.xp_sqlagent_msx_account N'GET'
  2. Set the SQL Server Agent MSX Account to use Windows Authentication

This example sets the SQL Server Agent MSX account to use Windows Authentication.

EXEC master.dbo.xp_sqlagent_msx_account N'SET',
   N'',  -- Reserved for future use
   N'',  -- MSX_username
   N''  -- MSX_password
C. Set the SQL Server Agent MSX account to use SQL Server Authentication

This example sets the SQL Server Agent MSX account to Ralph and specifies a password.

EXEC master.dbo.xp_sqlagent_msx_account N'SET',
   N'',  -- Reserved for future use
   N'Ralph',  -- MSX_username
   N'RalphPwd'  -- MSX_password
D. Delete the SQL Server Agent MSX account

This example deletes the SQL Server Agent MSX account. This means that SQL Server Agent defaults to Windows integrated security authentication.

EXEC master.dbo.xp_sqlagent_msx_account N'DEL'

SQL Server now checks to ensure that the Agent job owner has permission to append or overwrite a file. This happens in three ways:

  • If the job owner is a member of the sysadmin fixed server role, the job can be written to the server.

  • If the job owner is a Windows user, SQL Server tests to see if the user has permission to write to the server.

  • If the job owner is a SQL Server user, SQL Server tests the SQL Server Agent proxy account for permission to write to the server. If the proxy account has not been set, no log will be written.

In all cases, jobs are written with SQL Server Agent credentials, but SQL Server now tests to ensure the user has permission to write to the server. Errors will appear in the job history, but the job steps will not fail if the log file cannot be written.


Backward Compatibility for Cross-Database Ownership Chaining

New Information - SQL Server 2000 SP3.

SQL Server 2000 SP3 provides new options for configuring cross-database ownership chaining. The following information will help you determine whether to apply the default SP3 cross-database ownership chaining behavior during Setup, or override the changes and retain pre-SP3 cross-database ownership chaining behavior. In addition, this topic provides information about configuring support for cross-database ownership chaining after installation.

Ownership Chaining

All database objects have owners. When an object--such as a stored procedure, view, or user-defined function--references other objects and the calling and the called objects are owned by the same user, an ownership chain is established. SQL Server uses the ownership chain to determine how to check permissions.

When the same user owns the source object (the view, stored procedure, or user-defined function) and all target objects (underlying tables, views, or other objects), the ownership chain is said to be unbroken. When the ownership chain is unbroken, SQL Server checks permissions on the source object but not on the target objects.

Ownership chaining simplifies security management by allowing users to grant permissions on views, stored procedures, and user-defined functions instead of on individual objects in the database. For example, a user who owns several tables can create a view that includes data from the tables. The user can then grant permissions on the view instead of on the individual tables.

Cross-Database Ownership Chaining

Cross-database ownership chaining occurs when a source object depends on objects in other databases.

A cross-database ownership chain works in the same way as ownership chaining within a database, except that an unbroken ownership chain is based on all the object owners being mapped to the same login account.

Therefore, in a cross-database ownership chain, if the source object in the source database and the target objects in the target databases are owned by the same login account, SQL Server does not check permissions on the target objects.

For example, if two databases are owned by the same login account, the dbo users in these databases are mapped to the same login account. If cross-database ownership chaining is enabled for these databases, source objects in the dbo schema can access target objects in the dbo schema of both databases.

Risks Associated with Cross-Database Ownership Chaining

Ownership chaining within a database is a useful application design technique; however, Microsoft does not recommend cross-database ownership chaining because of security risks. These risks are due to the actions that highly-privileged users can perform:

  • Database owners and members of the db_ddladmin or db_owners database roles can create objects owned by other users. These objects can potentially target objects in other databases. This means that if you enable cross-database ownership chaining, you must fully trust these users with data in all databases.

  • Users with the CREATE DATABASE permission can create new databases and attach existing databases. If cross-database ownership chaining is enabled, these users can access objects in other databases from newly created or attached databases.

Even though Microsoft recommends turning off cross-database ownership chaining for maximum security, there are some environments where you can fully trust your highly-privileged users; for applications in those environments, you can enable cross-database ownership chaining at the database or instance level.

Setup Dialog Box Options

Use the following information to determine whether to select or clear the Enable cross-database ownership chaining for all databases check box:

  • When the box is cleared, SQL Server 2000 SP3 Setup applies a change that, by default, turns off cross-database ownership chaining for all user databases. After installation, you can turn on cross-database ownership chaining for individual user databases using the db_option system stored procedure. This cross-database security enhancement enables you to configure which databases can be accessed from within other databases.

  • If you select the check box, you are overriding the security enhancement and choosing to allow cross-database ownership chaining for all databases. Selecting the check box therefore exposes your system to the security risks described above.

Regardless of which option you choose during Setup, you can later modify server and database support for cross-database ownership chaining.

Configuring Cross-Database Ownership Chaining After Installation

If, after running Setup, you need to change the cross-database ownership chaining configuration, use the new options in the sp_configure and sp_dboption stored procedures:

  • Configure cross-database ownership chaining support for the instance of SQL Server with the new Cross DB Ownership Chaining option of sp_configure. When this option is set to 0, you can control cross-database ownership chaining at the database level using sp_dboption. When this option is set to 1, you cannot restrict cross-database ownership chaining, which is the pre-SP3 behavior.

    If you change this option, include the RECONFIGURE option to reconfigure the instance without having to restart it. For example, use the following command to allow cross-database ownership chaining in all databases:

    EXEC sp_configure 'Cross DB Ownership Chaining', '1'; RECONFIGURE
  • Configure cross-database ownership chaining at the database level with the new db chaining option of sp_dboption. When this option is set to false, the database cannot participate in cross-database ownership chaining as either the source or target database. When this option is set to true, the database can participate in a cross-database ownership chain. By default, this option is false for all user databases after you apply SP3.

    The following command turns on cross-database ownership chaining for the Northwind database:

    EXEC sp_dboption 'Northwind', 'db chaining', 'true'

    You cannot turn off cross-database ownership chaining for the master, tempdb, and msdb databases. You cannot turn on cross-database ownership chaining for the model database, which is used as a template for user databases.

    The effects of sp_dboption are manifested only when the sp_configure Cross DB Ownership Chaining option is set to 0.

See Also

Using Ownership Chains

sp_configure

Setting Configuration Options

sp_dboption


Error Reporting (SQL Server)

New Information - SQL Server 2000 SP3.

Microsoft® SQL Server™ error reporting is turned off by default. Enable it during installation through SQL Server Setup, or after installation through the SQL Server Enterprise Manager Server Properties dialog box. Enabling it during SQL Server Setup allows error reporting for the SQL Server database engine and SQL Server Agent.

If you enable this feature, SQL Server will be configured to automatically send a report to Microsoft if a fatal error occurs in the SQL Server database engine or SQL Server Agent. Microsoft uses error reports to improve SQL Server functionality, and treats all information as confidential.

Information about the error will be sent over a secure (https) connection to Microsoft, where it will be stored with limited access. Alternatively, this information can be sent to your own Corporate Error Reporting server. See this Microsoft Web site for more information about setting up a Corporate Error Reporting server.

  • The error report contains the following information:

  • The condition of SQL Server when the problem occurred.

  • The operating system version and computer hardware information.

  • Your Digital Product ID, which could be used to identify your license.

  • Your computer's IP network address.

  • Information from memory or file(s) of the process that caused the error.

Microsoft does not intentionally collect your files, name, address, e-mail address, or any other form of personal information. The error report may, however, contain customer-specific information from the memory or file(s) of the process that caused the error. Although this information could potentially be used to determine your identity, Microsoft does not use this information for that purpose.

For the Microsoft error reporting data collection policy, see this Microsoft Web site.

After you have enabled error reporting and a fatal error has occurred, you may see a response from Microsoft in the Windows Event log that points to a Microsoft Knowledge Base article on a particular error. A response may look similar to this example:

Source = MSSQLServerOlapServicesDW

EventID = 1010

data = http://support.microsoft.com/support/misc/kblookup.asp?id=.

To disable error reporting for the SQL Server database engine and SQL Server Agent, go to SQL Server Properties (General Tab) in Enterprise Manager and clear the Enable the error reporting feature checkbox.


Error Reporting (Analysis Services)

New Information - SQL Server 2000 SP3.

Microsoft® SQL Server™ error reporting is turned off by default. Enable it during installation through Analysis Services Setup, or after installation through the Analysis Manager Server Properties dialog box. Enabling it during Analysis Services Setup allows error reporting for Analysis Services.

If you enable this feature, SQL Server will be configured to automatically send a report to Microsoft if a fatal error occurs in Analysis Services. Microsoft uses error reports to improve SQL Server functionality, and treats all information as confidential.

Information about the error will be sent over a secure (https) connection to Microsoft, where it will be stored with limited access. Alternatively, this information can be sent to your own Corporate Error Reporting server. See this Microsoft Web site for more information about setting up a Corporate Error Reporting server.

  • The error report contains the following information:

  • The condition of SQL Server when the problem occurred.

  • The operating system version and computer hardware information.

  • Your Digital Product ID, which could be used to identify your license.

  • Your computer's IP network address.

  • Information from memory or file(s) of the process that caused the error.

Microsoft does not intentionally collect your files, name, address, e-mail address, or any other form of personal information. The error report may, however, contain customer-specific information from the memory or file(s) of the process that caused the error. Although this information could potentially be used to determine your identity, Microsoft does not use this information for that purpose.

For the Microsoft error reporting data collection policy, see this Microsoft Web site.

After you have enabled error reporting and a fatal error has occurred, you may see a response from Microsoft in the Windows Event log that points to a Microsoft Knowledge Base article on a particular error. A response may look similar to this example:

Source = MSSQLServerOlapServicesDW

EventID = 1010

data = http://support.microsoft.com/support/misc/kblookup.asp?id=.

To disable error reporting for Analysis Services, go to Server Properties in Analysis Manager and clear the Enable the error reporting feature checkbox.


Setup Type: Typical, Minimum, or Custom

When you install the Microsoft® SQL Server™ 2000 Enterprise Edition, SQL Server 2000 Standard Edition, or SQL Server 2000 Personal Edition, SQL Server Setup offers three installation types in the Setup Type dialog box. In addition, you can modify the installation location for both program and data files in this dialog box.

Options

Typical

Installs all of SQL Server using the default installation options. This installation is recommended for most users.

Minimum

Installs the minimum configuration necessary to run SQL Server. This installation is recommended for users who have computers with minimum available disk space.

Custom

Installs SQL Server and allows you to change any or all of the default options. Use a custom installation to select components and subcomponents, or to change settings for collations, services accounts, authentication, or network libraries.

Destination Folders

The default installation location is C:\Program Files\Microsoft SQL Server\, for both program and data files.

Program files

Click Browse to select another installation location for the SQL Server program files.

Data files

Click Browse to select another installation location for the SQL Server data files.

Caution It is recommended that program files not be installed on a cluster disk, so that future upgrades to a cluster are possible. If you select a folder on a cluster disk as a destination for SQL Server program files, a message appears requesting another installation path for program files.

When upgrading an installation of SQL Server 7.0 that has previously had program files installed on a cluster disk, a similar message appears: "Setup will move the program files from the cluster disk. Provide a new location for the program files. The drive letter you select must exist on all nodes of the cluster as a local drive so that you can later upgrade to a clustered installation."

For more information, see Upgrading to a SQL Server 2000 Failover Cluster.

Components for Each Installation Type

When you install SQL Server on Microsoft Windows NT® or Windows 2000, these options are offered for all installation types:

  • Windows Services accounts (logon accounts) for SQL Server and SQL Server Agent.

  • Whether to start SQL Server and SQL Server Agent automatically each time the computer is restarted.

  • Use of various network libraries, or protocols, including TCP/IP Sockets, Named Pipes, and Multiprotocol.

This table lists the types of installations and components that each installation provides.

Component | Typical | Minimum | Custom
Database Server | Yes | Yes | Optional
Upgrade Tools1 | Yes | No | Optional
Replication Support | Yes | Yes | Optional
Full-Text Search | Yes | Yes | Optional
Client Management Tools | All | None | Optional
Client Connectivity | Yes | Yes | Not an option
Books Online | Yes | No | Optional
Development Tools | Debugger only | None | Choice of tools
Code Samples | None | None | Choice of samples
Collation Settings | Yes | Yes | Choice of settings

1 Upgrade Tools are installed by default only for the default instance of SQL Server 2000, not for any named instances.

See Also

Net-Libraries and Network Protocols


Select Components

On the Select Components screen, you can choose components and subcomponents to install, or to reinstall if not set up initially. Options for a typical installation are selected by default. Select the components to install or reinstall and clear all others.

Note You cannot remove components by clearing check boxes on this screen. The only way to remove installed components is to remove SQL Server entirely.

Options

Components

Lists the main components of SQL Server

Sub-components

Lists the sub-components available for the selected component

SQL Server components and respective subcomponents include:

  • Server Components
    • SQL Server

    • Upgrade Tools

    • Replication Support

    • Full-Text Search

    • Debug Symbols

    • Performance Counters
  • Management Tools
    • Enterprise Manager

    • Profiler

    • Query Analyzer

    • DTC Client Support

    • Conflict Viewer
  • Client Connectivity

  • Books Online
    • Books Online on Disk
  • Development Tools
    • Headers and Libraries

    • MDAC SDKs

    • Backup/Restore API

    • Debugger Interface
  • Code Samples
    • Choice of many code samples

See Also

How to add components to an instance of SQL Server 2000 (Setup)


Server Components

These components can be installed from the Server Components category in the Select Components dialog box, when running Setup. Server Components are included when the option for Server and Client Tools is selected as an initial installation choice.

SQL Server

Installs the SQL Server relational database engine and other core tools. If any SQL Server program files are installed, the SQL Server component must be installed.

Note When installing the SQL Server component, the Setup program also installs the bcp, isql, and osql utilities, ODBC, OLE DB, and DB-Library.

Upgrade Tools

Installs the SQL Server Upgrade Wizard, used to upgrade SQL Server 6.5 databases to the current version.

Replication Support

Installs the scripts and binary files used for replication.

Full-Text Search

Installs the Microsoft full-text search engine (Microsoft Search service), which extends the ability to search on character columns beyond the basic equality and LIKE operators.

Debug Symbols

Installs the debug symbols for installations.

Performance Counters

Installs performance counters for use with installations.

See Also

Installation Definition


Management Tools

These components can be installed from the Management Tools category in the Select Components dialog box, when running Setup. Management tools are included when the option for Client Tools Only is selected as an initial installation choice.

Enterprise Manager

Used to perform server and enterprise administrative tasks.

Profiler

Used to monitor, record, and support auditing of Microsoft SQL Server database activity.

Query Analyzer

Used to enter Transact-SQL statements and procedures interactively. Also provides graphical query analysis in the form of graphical showplans.

DTC Client Support

Used to extend database transactions across multiple servers.

Microsoft Distributed Transaction Coordinator (MS DTC) coordinates transactions across a network of systems running Microsoft Windows NT®, Microsoft Windows® 98, and Microsoft Windows 95.

Conflict Viewer

Used to view and, if necessary, change the way synchronization conflicts are resolved.

See Also

Installation Definition

How to install client tools only (Setup)


Client Connectivity

The client connectivity component is an option in the Select Components dialog box in Setup. The client connectivity component is used to communicate between clients and servers, and includes the Microsoft Data Access Components (MDAC) and network libraries for DB-Library, ODBC, and OLE DB.

This component has no subcomponents. Client Connectivity is installed when the option for Connectivity Only is selected as an initial installation choice.

Note To connect to a named instance of SQL Server 2000, MDAC 2.6 must be installed on the client computer.

See Also

Installation Definition

Distributing SQL Server Applications Overview


Books Online

This component can be installed from the Books Online category in the Select Components dialog box in Setup. The Books Online component includes both the full SQL Server Books Online for SQL Server 2000 and online Help, available by clicking the Help button or pressing the F1 key in dialog boxes and interface elements.

Books Online on Disk

Installs the complete documentation set on your local drive in the default shared tools locations: \Program Files\Microsoft SQL Server\80\Tools\Books.

Note You may want to view information in SQL Server Books Online for Microsoft® SQL Server™ 7.0. For more information, see How to access SQL Server Books Online for SQL Server 7.0.


Development Tools

These components can be installed from the Development Tools category in the Select Components dialog box in Setup. To install development tools, choose a custom installation in the Setup Type screen. The Debugger Interface is an exception; it is included when you choose to install a typical installation.

Headers and Libraries

Installs the include (*.h) files and library (*.lib) files needed by a C developer to create programs that use OLE DB, ODBC, DB-Library, Open Data Services, SQL-DMO, Embedded SQL for C, and MS DTC. These files are installed in the \Program Files\Microsoft SQL Server\80\Tools\DevTools\Include and the \...\DevTools\Lib directories by default (shared tools location).

MDAC SDKs

Installs MDAC and XML Software Development Kits.

Backup/Restore API

Installs the header files, sample programs, and documentation required by software vendors to develop custom applications to back up and restore Microsoft SQL Server databases.

Debugger Interface

Installs an interface for stored procedure debugging.


Code Samples

The samples component is available from the Code Samples category in the Select Components dialog box in Setup. This component installs programming sample files used for reference when you write programs for Microsoft® SQL Server™ 2000. These files are installed in folders in the \Program Files\Microsoft SQL Server\80\Tools\DevTools\Samples directory by default (shared tools location). You can install any or all of these samples.

Note Sample code for using a virtual device to backup or restore data is included in the Backup/Restore API, a sub-component of the Development Tools component. For more information, see Development Tools.

Option | Name
ADO | Microsoft ActiveX® Data Objects
DBLIB | DB-Library
Desktop | Desktop Engine
DTS | Data Transformation Services
ESQLC | Embedded SQL for C
Misc | Miscellaneous Samples
MSDTC | Microsoft Distributed Transaction Coordinator
ODBC | Open Database Connectivity
ODS | Open Data Services
OLE Automation | OLE Automation
Replication | Replication
Silver | Sample Database Schemas
SQL-DMO | SQL Distributed Management Objects
SQL-NS | SQL Namespace
Utils | Sample Utilities
XML | XML Samples


Network Libraries

On the Network Libraries screen, you can select network libraries to install for Microsoft® SQL Server™ 2000. Network libraries are used to pass network packets between clients and a server running SQL Server. The network libraries, implemented as dynamic-link libraries (DLLs), perform the network operations required to communicate using specific interprocess communication (IPC) mechanisms.

A server can listen on, or monitor, multiple network libraries at one time. During installation, SQL Server Setup installs all of the Net-Libraries onto the computer and allows you to configure some or all of the Net-Libraries. If a particular Net-Library is not configured, the server cannot listen on that Net-Library. After installation, you can change these configurations using the Server Network utility.

For a clustered installation, only Named Pipes and TCP/IP are available. When installing a clustered instance, the unsupported network libraries are unavailable. When you install named instances, the Multiprotocol, AppleTalk, and Banyan VINES protocols are unavailable.

When an instance of Microsoft SQL Server is configured to listen on a static IP port (such as a default instance that takes the default of listening on port 1433), the SQL Server service cannot open the port if another application or component is using the port when the SQL Server service initializes. The TCP/IP server Net-Library will not initialize, and the instance of SQL Server cannot accept TCP/IP connections until the service is stopped and restarted. This problem should not occur if the instance of SQL Server is configured to use a dynamic port address by specifying a port address of 0 using the Server Network Utility. If you cannot use dynamic port addresses (for example, when SQL Server connections must pass through a firewall server configured to pass through specific port addresses, or when some connections are made using the client components from SQL Server version 7.0 or earlier), then using a port address less than 1024 is recommended. Choose a port in this range that is not used by the operating system or another application.

Options

Named Pipes

Named Pipes support is required on Microsoft Windows NT® and Microsoft Windows® 2000 installations of SQL Server. Server-side Named Pipes is not supported on Microsoft Windows 98. By default, SQL Server listens on the standard pipe for Named Pipes Net-Library connections.

Named Pipes name

Paths for the default and named instances differ:

  • Default instance: \\.\pipe\sql\query

  • Named instance: \\.\pipe\MSSQL$instancename\sql\query

After SQL Server is installed, you can change the pipe name.

TCP/IP Sockets

This Net-Library allows SQL Server to communicate by using standard Windows Sockets as the IPC method across the TCP/IP protocol. By default, all installations of Microsoft SQL Server 2000 on all operating systems use the TCP/IP Sockets Net-Library.

Note the following when using TCP/IP Sockets:

  • SQL Server uses UDP port 1434 to establish connections from SQL Server 2000 clients. This socket number is also reserved for SQL Server by Internet Assigned Number Authority (IANA).

  • Do not use dynamic ports and do not set a proxy server address, because the port you are listening on can change at each service startup.

Port Number

If you set SQL Server to listen on TCP/IP, type the TCP/IP port number in the Port number box only if you want SQL Server to listen on a port address different from the default address. This is the port that SQL Server listens on when accepting connections from TCP/IP Sockets clients. The default number for a default instance is 1433, the official IANA socket number for SQL Server. The port for a named instance is dynamically assigned when the instance is first started, unless you set an alternate port during setup.

Remote Winsock proxy address

If you set SQL Server to listen on a proxy server using Microsoft Proxy Server over TCP/IP Sockets, type the proxy server address in the Remote WinSock proxy address box when you set up the TCP/IP Sockets Net-Library.

Multiprotocol

The Multiprotocol Net-Library uses the Windows NT remote procedure call (RPC) facility. In addition, the Multiprotocol Net-Library:

  • Communicates over most IPC mechanisms supported by Windows NT. Only TCP/IP Sockets, NWLink IPX/SPX, and Named Pipes are considered tested and supported.

  • Allows the use of Windows Authentication over all protocols that RPC supports.

  • Supports encryption for user password authentication as well as data.

  • Offers performance comparable to native IPC Net-Libraries for most applications.

Enable Multiprotocol encryption

Use Multiprotocol encryption only for compatibility with existing systems. The Secure Sockets Layer (SSL) encryption that can be enabled using the Server Network Utility (after running Setup) is a more comprehensive encryption solution. Multiprotocol encryption is not supported on Windows 98 servers.

Note The Multiprotocol Net-Library is not supported with named instances.

NWLink IPX/SPX

This Net-Library allows SQL Server to communicate using the NWLink IPX/SPX protocol.

Novell Bindery Service Name

If you set up SQL Server to listen on NWLink IPX/SPX, the Setup program prompts you for the Novell Bindery service name in which to register SQL Server on the Novell network. The default service name is the computer name of the server computer. The Net-Library allows Novell SPX clients to connect to SQL Server.

The server NWLink IPX/SPX Net-Library is not available on Windows 98 and Windows 95.

AppleTalk ADSP

The server AppleTalk (ADSP) Net-Library allows Apple Macintosh® clients to connect to SQL Server using native AppleTalk (as opposed to TCP/IP Sockets).

Note The AppleTalk Net-Library has not been enhanced for SQL Server 2000 and runs at a SQL Server 7.0 level of functionality. This Net-Library will not be supported in a future release of SQL Server 2000 and is not supported on named instances.

Apple Talk Service Object

If you set up SQL Server to listen on AppleTalk, Setup prompts you for the AppleTalk service object name. The AppleTalk service object name is assigned by your system administrator. It is not necessary to enter an AppleTalk zone because the local zone is used when registering the service.

The AppleTalk Net-Library is not supported on Windows 98 and Windows 95.

Banyan VINES

SQL Server supports Banyan VINES Sequenced Packet Protocol (SPP) as the IPC method across the Banyan VINES IP network protocol. Banyan VINES support for clients and servers running Windows NT is available for SQL Server on the Intel® platform only; it is not available on Windows 98 and Windows 95.

Note The Banyan VINES Net-Library has not been enhanced and runs at a SQL Server 7.0 level of functionality. This Net-Library will not be supported in a future release of SQL Server 2000 and is not supported on named instances.

Street Talk Service name

If you set up SQL Server to listen on Banyan VINES, the Setup program prompts you for a StreetTalk service name. This has the form servicename@group@org, where servicename is the StreetTalk computer-based service name used by SQL Server, group is the group, and org is the organization. The computer-based service name used by SQL Server must first be created by using the MSERVICE program included with your Banyan VINES software. Also, to start SQL Server, you must be logged in with administrative permissions.

Enable protocol encryption for all libraries

Select this check box to enable protocol encryption for all network libraries. To use protocol encryption, you must have a certificate on the server. For information about obtaining a certificate, see the Microsoft Windows documentation. If you do not have a certificate, you can enable encryption after installing SQL Server using the Server Network Utility.

Default Net-Library Settings

Note TCP/IP networking must be enabled before running SQL setup.

All Net-Libraries are installed by the Setup program. The table shows the default server and client Net-Library settings by operating system.

Operating system | Server Net-Library settings | Client Net-Library settings
Windows 98 | TCP/IP Sockets, Shared Memory | TCP/IP Sockets
Windows 95 | Not applicable | TCP/IP Sockets
Windows NT 4.0 (Server and Workstation) | TCP/IP Sockets, Shared Memory, Named Pipes | TCP/IP Sockets, Named Pipes
Windows 2000 (all versions) | TCP/IP Sockets, Shared Memory, Named Pipes | TCP/IP Sockets, Named Pipes

See Also

Configuring Client Net-Libraries

Net-Libraries and Network Protocols


Services Accounts

Use the Services Accounts screen in Setup to assign a logon account to each of the two Microsoft® SQL Server™ services, SQL Server and SQL Server Agent. Either the local system or the domain user account is used, and you can use the same account for each service. The default setting is to use the same account for each service, and to automatically start each service. To use the default setting, enter your domain password and click Next.

You can also customize settings for each service. You can enter one logon account for both services, or specify an account for each. To later change options set on the Services Accounts screen, run the Services application in Windows Control Panel.

Important To create or maintain a Microsoft SQL Server™ 2000 failover cluster, you must be logged on to the computer with administrator privileges, that is, be a member of the Administrators local group of the computer or domain. For clustering this means that you must be an administrator of all nodes of the cluster.

When running SQL Server 2000 on Microsoft Windows NT 4.0, in addition to being logged on as an administrator, you must configure both SQL Server and SQL Server Agent to run as administrator accounts.

Options

Use the same account for each service. Auto start SQL Server Service.

The default option: One account is used for both SQL Server and SQL Server Agent. These services start automatically when the operating system starts.

Customize the settings for each service.

Allows you to use different settings for the two services.

Services

Select a service for which you want to customize settings.

SQL Server

Select this option to customize settings for the service, Microsoft SQL Server.

SQL Server Agent

Select this option to customize settings for the service, Microsoft SQL Server Agent.

Service Settings

Select service settings as required.

Use the Local System account

The local system account does not require a password, does not have network access rights in Windows NT 4.0, and may restrict your SQL Server installation from interacting with other servers.

Note In Windows 2000, the local system account does allow network access.

Use a Domain User account

A domain user account uses Windows Authentication to set up and connect to SQL Server. By default, account information appears for the domain user account currently logged on to the computer.

Username

Accept or change the domain username.

Password

Enter the domain password.

Domain

Accept or change the domain name.

Auto Start Service

Select this option to automatically start a service when your operating system starts. This option is available only when customizing the settings for each service.

The SQL Server Agent service is dependent on the SQL Server service in that you can autostart the SQL Server Agent service only if you autostart the SQL Server service as well.

Note When you click Back in the Services Accounts dialog box, the window you return to reverts to the default options. Options specified earlier are not retained.

See Also

Setting Up Windows Services Accounts

Changing Passwords and User Accounts


Authentication Mode

New Information - SQL Server 2000 SP3.

Use this screen to choose the security (authentication) mode you want to use for this installation of Microsoft® SQL Server™ 2000. If you select Mixed Mode, you are prompted to enter and confirm the system administrator password. After successful connection to SQL Server, the security mechanism is the same for both modes.

Options

Windows Authentication Mode

When a user connects through a Microsoft Windows® user account, SQL Server validates the account name and password using information in the Windows operating system.

Security Note When possible, use Windows Authentication.

Mixed Mode (Windows Authentication and SQL Server Authentication)

Allows users to connect using Windows Authentication or SQL Server Authentication. Users who connect through a Microsoft Windows user account can make use of trusted connections (connections validated by Windows) in either Windows Authentication Mode or Mixed Mode. SQL Server Authentication is provided for backward compatibility.

Add password for the sa login

Enter and confirm the system administrator password.

Blank Password (not recommended)

If a user attempts to connect to an instance of SQL Server providing a blank login name, SQL Server uses Windows Authentication. Additionally, if a user attempts to connect to an instance of SQL Server configured for Windows Authentication Mode using a specific login, the login is ignored and Windows Authentication is used.

See Also

Adding a SQL Server Login

Assigning an sa Password

Authentication Modes

Creating Security Accounts


Choose Licensing Mode

Use this dialog box to set the licensing mode enabling your clients to access this instance of Microsoft® SQL Server™. SQL Server 2000 supports two client access licensing modes, one for each device and another for each processor.

  • A device in this context can be a workstation, terminal, or any other device running a SQL Server application connected to an instance of SQL Server.

  • A processor refers to a central processing unit (CPU) installed on a computer running an instance of SQL Server 2000. One computer may have multiple processors installed, requiring multiple processor licenses.

Once a licensing mode is set, you cannot change modes. You can add device or processor licenses after installing SQL Server, using the SQL Server 2000 Licensing Setup utility in Control Panel. (Do not confuse this licensing utility with the Windows Licensing utility, also found in Control Panel.)

For more information about licensing modes, see the Microsoft license agreement for SQL Server 2000.

Options

Licensing Mode

If accessing this dialog box from Control Panel, the mode chosen during setup is selected by default, along with the number of devices or processors you have previously selected.

Per Seat for

The Per Seat licensing mode requires a Client Access License for each device that will access SQL Server 2000 Server. Per Seat is often more economical for networks in which clients connect to more than one server.

In the edit box, select the number of devices to license.

Processor License for

With Processor licensing, a license is needed for each processor installed on the computer running SQL Server. The Processor License allows any number of devices to access the server, whether through an Intranet or over the Internet.

Using Processor licensing, SQL Server 2000 can take advantage of each installed processor, and support an unlimited number of client devices. A customer that provides access to SQL Server databases over the Internet, or that has a large number of users, will generally choose the Processor License.

In the edit box, select the number of processors to license.

Continue

Click the Continue button to complete the installation process, or after modifying the number of devices or processors you want to license.


Installing a Remote Configuration

Microsoft® SQL Server™ 2000 can be installed on a remote computer, that is, a computer other than the one on which Setup is running. Before performing a remote installation:

  • Ensure that the local and remote computers are running Microsoft Windows NT® or Windows® 2000.

  • Ensure that the local and remote computers have an Intel®-compatible processor.

  • Ensure that you are logged on to the local computer with a user account that has administrative privileges on the remote computer.

A remote setup is much like a normal installation, with two additional dialog boxes:

  • The Remote Setup Information dialog box, which is also used when Setup is run on a computer that is part of a cluster. For more information, see Remote Setup Information.

  • The Select Computer dialog box, which allows you to select a remote computer from the list of computers within the connected domains. The list may include computers not available for this installation, because permission must be granted before installing on a remote computer.

    A computer network name may be entered instead of choosing from the list.

See Also

Computer Name


Remote Setup Information

Remote setup information is required to define security in two different setup situations:

  • When you choose to install Microsoft® SQL Server™ 2000 on a remote computer.

  • When Setup is run on a computer that is part of a cluster, even if you are not creating or maintaining a failover cluster installation of SQL Server.

For a remote installation, SQL Server Setup collects the information you enter in Setup dialog boxes, recording the entries into the Setup.iss file. At the same time, the remote setup process starts a remote service, copies files to the \admin$ share directory, and runs an unattended installation on the remote computer using the options specified in Setup.iss.

For clustered computers, the Remote Setup Information box is displayed because any installation on a failover cluster system needs the administrator account to install Microsoft Distributed Transaction Coordinator on both nodes, or to verify the presence of MS DTC. Administrator information must be entered that is valid for all selected nodes in the failover cluster system.

Options

Username, Password, and Domain

Specify the user account under which SQL Server Setup starts a service on the remote computer. This user account must be an administrator on the remote computer and have read access to the Setup source files directory.

Do not confuse the user account entered on this screen with:

  • The user account logged on to the local computer.

  • The user account assigned in SQL Server Setup to the SQL Server and SQL Server Agent services.

Each of these user accounts is specified separately. However, you can use the same user information in each case. That is, you can use the same name, password, and Windows domain for each account.

Target computer

The name of the remote computer entered in the Computer Name dialog box is shown in static text.

Target path

The name of the remote computer and, in Universal Naming Convention format, the directory on the remote computer where SQL Server is to be installed. For example:

\\target_computer\C$\Program Files\Microsoft SQL Server

Setup Source Files

Location of the setup program files used for the remote installation.

To perform a remote installation

SQL Setup

SQL Setup

See Also

Performing an Unattended Installation


Advanced Installation Options

When you select the Advanced option in the Installation Options Setup screen, the Advanced Options dialog box provides three choices.

Options

Record Unattended .ISS file

Create a setup initialization file for unattended installations.

Registry Rebuild

Rebuild registry for a corrupted installation.

Maintain a virtual server for failover clustering

Make changes to existing clusters, such as revising the name, or adding and removing cluster nodes.

See Also

Performing an Unattended Installation

Rebuilding the Registry

Installing a Virtual Server Configuration

SQL Server Language Support


Installing a Virtual Server Configuration

The topics in this section provide information about the Setup screens used in setting up and maintaining failover clustering.


Failover Clustering: Defining the Virtual Server

Use the Failover Clustering screen to define the virtual server for a new cluster, or to maintain the virtual server definition for an existing cluster. You can add and remove IP addresses; multiple IP addresses are allowed for each virtual server.

Options

Virtual Server Name

Displays the network name of the virtual server. This is the name users will see when they connect to the virtual server.

When upgrading to a cluster, this name is entered in the Virtual Server Name dialog box.

IP address

Enter the IP address or addresses used to connect to the virtual server.

SubNet

Displays the Subnet, which is supplied by MSCS.

Network

Displays the Network name you assigned each subnet during setup of MSCS.

Add

Adds the specified IP address and SubNet to the named virtual server.

Remove

Removes the specified IP address and SubNet from the named virtual server.

See Also

Before Installing Failover Clustering

Creating a Failover Cluster

Upgrading to a SQL Server 2000 Failover Cluster


Cluster Management Screen

Use the Cluster Management screen to review the cluster definition provided by Microsoft® SQL Server™ 2000, and make changes if necessary. After you have specified nodes for the virtual server, Setup installs or uninstalls the SQL Server binary files on each node.

Caution If you modify the node list of a virtual server using the quorum resource, your cluster may not fail over properly. For more information, see Modify Node List Warning.

Options

Available Nodes

A list of computers that can be added to the current virtual server definition. If a computer you want is not available at this time, you can run Setup later to add it to the virtual server definition.

Configured Nodes

List of computers currently configured in the current virtual server definition. The computer at the top of the list is the preferred node.

Unavailable Nodes

Computers that are currently offline or not available to be added to a cluster definition.

Add

Adds the selected available node to the list of configured nodes.

Remove

Removes the selected configured node from the list of configured nodes.

See Also

Failover Clustering

Maintaining a Failover Cluster

Cluster Disk Selection Screen

Upgrading to a SQL Server 2000 Failover Cluster


Cluster Disk Selection Screen

Use the Cluster Disk Selection screen to select a cluster group during the installation of a new virtual server or during an upgrade to a cluster. A cluster group is composed of one or more shared cluster disks within a group, and can contain at most one Microsoft® SQL Server™ virtual server. The Cluster Disk Selection screen lists only those groups that already have the shared cluster disk added as a resource. For more information about cluster disks, see Creating a Failover Cluster.

Caution Do not select the quorum disk (the last group in the list) because the quorum disk must be treated as a special resource. Clustering may fail if selected as a cluster group. A warning message appears if you select the quorum disk. For more information, see Quorum Disk Selection Warning.

When using a small cluster, the quorum disk may be the only choice available. Use it only for testing purposes or to explore failover clustering.

Important Never use the quorum group for production purposes.

See Also

Failover Clustering

Maintaining a Failover Cluster

Modify Node List Warning


Quorum Disk Selection Warning

The following warning message appears if you select the quorum disk (the last group in the list) on the Cluster Disk Selection screen. This warning applies to both Microsoft® Windows NT® 4.0 and Microsoft Windows® 2000:

It is strongly recommended that you not use the quorum group with SQL Server.

The quorum disk is a special resource in the Windows operating system. If you select the quorum disk, you may later want to restrict ownership of Microsoft® SQL Server™ to a subset of the cluster nodes. However, the quorum group owner list must include all of the nodes in the cluster.

For example, you may have a two-node cluster (Node1 and Node2) with SQL Server set to use the quorum disk group. If you then modify SQL Server to have only Node1 in the virtual server definition, the quorum disk group is prevented from failing over to Node2. In the event of a failure of Node1, the result is that you not only lose the virtual SQL Server, but the entire MSCS cluster.

This is true for Windows NT 4.0 only. In Windows 2000 the node list is ignored and the quorum disk group can fail over to any node in the cluster configuration. However, another issue may arise. In the previous example, there are no SQL Server program files available on Node2, but the cluster group can fail over to Node2. In this situation, SQL Server is unable to run on Node2 but the cluster group containing the quorum disk may fail over anyway, making your SQL Server unavailable.

For more information about the quorum disk, see the Windows NT documentation.

See Also

Cluster Disk Selection Screen

Modify Node List Warning

Creating a Failover Cluster

Failover Clustering Dependencies


Modify Node List Warning

In the Cluster Management screen, use caution if you modify the node list of a Microsoft® SQL Server™ 2000 virtual server using the quorum resource. If such a node list is modified, the following warning appears when Next is clicked:

Modifying the node list of the quorum resource may prevent your cluster from failing over properly. Are you sure you want to do this?

The quorum resource itself is unable to fail over to any servers that you did not select as part of your virtual server definition. This may jeopardize the availability of your failover cluster. For more information, see the Microsoft Windows NT® documentation.

Note  This problem does not occur when you run SQL Server 2000 on Microsoft Windows® 2000.

See Also

Quorum Disk Selection Warning

Creating a Failover Cluster

Failover Clustering Dependencies


Performing an Unattended Installation

You can perform an unattended installation of Microsoft® SQL Server™ 2000, in which setup screen entries are made automatically using stored information. An unattended installation can be convenient if you want to perform several installations of SQL Server with identical configurations on different computers. An unattended installation requires a setup initialization file, which can be created in several different ways.

By default, each time you install SQL Server using the Setup screens, the options you select are recorded into the setup initialization file, Setup.iss. Setup.iss is placed in the system root directory (%windir%), and is available to provide installation settings at a later time.

Note You cannot perform an unattended installation to set up a failover cluster of Microsoft SQL Server 2000.

Creating a Setup File Using the Record Unattended Option

In Setup, when you select the Record Unattended .ISS file option in the Advanced Options screen, each subsequent choice you make in the setup screens is recorded in the Setup.iss file stored in the system root directory. SQL Server files are not installed in this process. The Setup.iss file can then be run as is, or revised in a text editor if necessary.

To record an unattended installation file

SQL Setup

SQL Setup

Sample Setup Files on the SQL Server Compact Disc

Several sample setup initialization files are included on the Microsoft SQL Server 2000 compact disc, along with batch files to run Setup with the appropriate initialization file.

Sample initialization files are included for client, typical, and custom installations. (A custom setup file includes all features.) The table shows the files used for an unattended installation. The files are located in the root directories on the compact discs of the SQL Server 2000 Standard, Personal, and Enterprise editions.

Type of unattended installation | Sample batch file | Sample setup initialization file
Typical installation of SQL Server. | Sqlins.bat | Sqlins.iss
Client tool only: Includes management tools, client connectivity, and other tools (no server is included). | Sqlcli.bat | Sqlcli.iss
Custom installation of SQL Server: All components are included. | Sqlcst.bat | Sqlcst.iss

Note Batch files are also included on the compact disc for use with Smssql.pdf, a package definition format file for creating a SQL Server package in SMS. For more information, see Installing SQL Server Using SMS.

Creating Initialization Files Manually

For installation options other than those included in the sample setup files, you must create a customized setup file using a text editor. For example:

  • The sample setup files assign the SQL Server services to the local system account. To assign domain user accounts during an unattended installation, you must modify the setup file.

  • Typically, only the default instance of SQL Server 2000 is installed using an unattended installation, but a setup file can be created to install named instances.

To manually create a customized setup initialization file for these and other purposes, see Creating a Setup File Manually.

Running an Unattended Installation

You can run an unattended installation using sample batch files and setup initialization files, or you can run SQL Server Setup directly from the command prompt, using setup files created by any method, and customized or not.

To run an unattended installation

Command Prompt

Command Prompt

See Also

Setup Type: Typical, Minimum, or Custom

How to record an unattended installation file (Setup)

Creating a Setup File Manually


Creating a Setup File Manually

You create a customized setup initialization file interactively when you select the Record Unattended option in Microsoft® SQL Server™ 2000 Setup. You can also edit files manually, to further refine and customize setup initialization files.

Creating or Modifying a Setup File Using a Text Editor

You can use a text editor to modify the Setup.iss file generated using the Record Unattended .ISS file option. You can also modify one of the sample setup files (*.iss) included on the SQL Server 2000 compact disc or you can create your own setup file.

To modify one of the sample setup initialization files found on the SQL Server compact disc, open the file in a text editor and modify as required. Keep the file compatible with the Microsoft Windows® initialization file format and save it with the .iss file name extension.

Format of a Sample Setup Initialization File

A setup initialization file is a text file that uses the standard Windows .ini file format. Sections of the sample setup initialization file for a typical installation of Microsoft SQL Server 2000 are described in the tables that follow. This sample file (Sqlins.iss) is found in the root directory of the SQL Server compact disc.

Note In creating a setup file for a named instance of SQL Server 2000, you must indicate the instance name you want to install and the path required to navigate through the setup screens. The Instance Name dialog box [DlgInstanceName] section must be modified, as well as other places in the setup file where the instance name appears.

[InstallShield Silent]

This section is required for InstallShield. Do not change the values.

Entry | Value | Description
Version | v5.00.000 | Version of the InstallShield Silent response file.
File | Response File | Indicates this is the Response File.

[File Transfer]
Entry | Value | Description
OverwriteReadOnly | NoToAll | Do not overwrite read-only files.

[DlgOrder]

Lists each dialog box in the order it appears in an attended setup. The listing in this section must correspond to the other sections in the setup initialization file.

Entry | Value | Description
Dlg0 | SdWelcome-0 | Initial dialog box
Count | 14 | Number of dialog boxes listed in this section
Dlg1 | DlgMachine-0 | Next dialog box
Dlg2 | DlgInstallMode-0 | Next dialog box
Dlg3 | SdRegisterUser-0 | Next dialog box
Dlg4 | SdLicense-0 | Next dialog box
Dlg5 | DlgCDKey-0 | Next dialog box
Dlg 6 | DlgClientServer-0 | Next dialog box
Dlg7 | DlgInstanceName-0 | Next dialog box
Dlg8 | SetupTypeSQL-0 | Next dialog box
Dlg9 | DlgServices-0 | Next dialog box
Dlg10 | DLGSqlSecurity-0 | Next dialog box
Dlg11 | DlgCollation-0 | Next dialog box
Dlg12 | DlgServerNetwork-0 | Next dialog box
Dlg13 | SdStartCopy-0 | Next dialog box
Dlg14 | SdFinish-0 | Last dialog box

[SdWelcome-0]

Corresponds to the Welcome dialog box.

Entry | Value | Description
Result | 1 | Next

[DlgMachine-0]

Corresponds to the Computer Name dialog box.

Entry | Value | Description
Type | 1 | Local computer
Result | 1 | Next

[DlgInstallMode-0]

Corresponds to the Installation Selection dialog box.

Entry | Value | Description
Type | 1 | Create a new instance
Result | 1 | Next

[SdRegisterUser-0]

Corresponds to the User Information dialog box.

Entry | Value | Description
szName | <user name> | Name of user; company name is not required.
Result | 1 | Next.

[SdLicense-0]

Corresponds to the Software License Agreement dialog box.

Entry | Value | Description
Result | 1 | Yes

[CDKEYDialog-0]

Corresponds to the CD-Key dialog box.

Entry | Value | Description
svCDKey | <CD key value> | Specified for each installation
Result | 1 | Next

[DlgClientServer-0]

Corresponds to the Installation Definition dialog box.

Entry | Value | Description
Type | 2 | Server and client tools
Result | 1 | Next

[DlgInstanceName-0]

Corresponds to the Instance Name dialog box.

Entry | Value | Description
InstanceName | MSSQLSERVER | Designation of the default instance (always the same).
InstanceName | <instance name> | Designation of a named instance.
Result | 1 | Next.

[SetupTypeSQL-0]

Corresponds to the Setup type dialog box.

Entry | Value | Description
szDir | %PROGRAMFILES%\Microsoft SQL Server | Directory where SQL Server program files are installed.
Result | 301 | Typical (301) (302 = Minimum and 303 = Custom).
szDataDir | %PROGRAMFILES%\Microsoft SQL Server | Directory where SQL Server data files are installed (same as program files).

[DlgServices-0]

Corresponds to the Services Accounts dialog box.

Entry | Value | Description
Local-Domain | 3855 <other numeric value> | Use the same account for each service. To customize the settings for each service, see Setup Initialization File Details.
AutoStart | 15 | Autostart Service is enabled.
Result | 1 | Next.

[DlgSQLSecurity-0]

Corresponds to the Authentication dialog box. Choices shown here include options not in the sample Sqlins.iss file.

Entry | Value | Description
LoginMode | -1 | System default security is used. The Microsoft Windows NT® default is Windows Authentication Mode. The Microsoft Windows 98 default is Mixed Mode, with a blank sa password. Although the default sa password is blank, to conform to best security practices, it should be changed to a strong password at the first opportunity.
LoginMode | 1 | Windows Authentication Mode.
LoginMode | 2 | Mixed Mode.
szPwd | <choice of password> | Used only with Mixed Mode security.
Result | 1 | Next.

[DlgCollation-0]

Corresponds to the Collation Settings dialog box.

Entry | Value | Description
collation_name | ' ' | When blank, system default collation is used.
collation_name | <collation designator> | Selected by user. For more information, see Collation Settings in Setup.

[DlgServerNetwork-0]

Corresponds to the Network Libraries dialog box.

Entry | Value | Description
NetworkLibs | 255 245 15 | Named pipes and TCP/IP Value 240 (0xF0) = TCP/IP only Value 15 = Named pipes only To customize network library settings, see Setup Initialization File Details
TCPPort | 1433 | Port address, for TCP/IP
TCPPrxy | Default | Default proxy, or what is entered
NMPPipeName | \\.\pipe\sql\query | Pipe name
Result | 1 | Next

[SdStartCopy-0]

Corresponds to the Start Copying Files dialog box.

Entry | Value | Description
Result | 1 | Next

[SdFinish-0]

Corresponds to the Setup Complete dialog box.

Entry | Value | Description
Result | 1 | Next
bOpt1 | 0 | Placeholder for stock dialog box
bOpt2 | 0 | Placeholder for stock dialog box

See Also

Performing an Unattended Installation

Setup Initialization File Details


Setup Initialization File Details

When creating a customized setup initialization file, the Service Accounts and Network Libraries dialog boxes have additional options used for an unattended installation.

Services Accounts Dialog Box

To customize settings for each service, you can calculate values for the Local-Domain and AutoStart entries.

Local-Domain

If you want the SQL Server and SQL Server Agent services to use different logon accounts, you can calculate the value to enter for Local-Domain. The Local-Domain value is a bitwise logical OR combination of the values shown in the following table. For more information, see | (Bitwise OR).

Service | Account to use | Hexadecimal value
SQL Server | Local System account | x0000000F
SQL Server Agent | Local System account | 0x00000F00
SQL Server | Domain User account | 0x000000F0
SQL Server Agent | Domain User account | 0x0000F000

Additional entries must be added to your setup initialization file if the Domain User account is used for either service.

When SQL Server service is using a domain account, Setup looks for values for:

  • SQLDomain = <domain name>

  • SQLDomainAcct = <domain user account>

  • SQLDomainPwd = <domain password: an encrypted password available only using setup screens>

When SQL Server Agent service is using a domain account, Setup looks for values for:

  • AgtDomain = <domain name>

  • AgtDomainAcct = <domain user account>

  • AgtDomainPwd = <domain password: an encrypted password available only using setup screens>
AutoStart

The value for the AutoStart option is a bitwise logical OR combination using the following hexadecimal values:

Autostart SQL Server = 0x0000000F

Autostart SQL Server Agent = 0x000000F0

A value of zero (0) for either service indicates no AutoStart; manual startup is required.

Network Libraries Dialog Box

To customize network library settings, you can calculate a value for the NetworkLibs entry in the Network Libraries dialog box. The value for NetworkLibs is a bitwise logical OR combination of the values shown in the following table. When a network library is set, additional information must be entered in the setup initialization file, as shown in the third column.

Network Library to use when connecting to the server | Hexadecimal value to use in Bitwise OR operation | Additional information that Setup looks for
Named Pipes | 0xF | NMPPipeName = <named pipe name>
TCP/IP Sockets | 0xF0 | TCPPort = <port number> TCPPrxy = <Remote Winsock proxy address>
NW Link | 0xF000 | NWLinkObj = <Novell Bindary service name>
Apple Talk | 0xF0000 | ApplObj = <Apple Talk service object>
Banyan VINES | 0xF00000 | BanyanObj = <StreetTalk service name>

See Also

Services Accounts

Network Libraries

Performing an Unattended Installation


Installing SQL Server Using SMS

You can use Microsoft® Systems Management Server (SMS) version 1.2 or later to install Microsoft SQL Server™ 2000 automatically on multiple server computers running Microsoft Windows NT® or Microsoft Windows® 2000 in your enterprise.

The SQL Server compact disc contains a Package Definition Format (PDF) file (Smssql.pdf) that automates creating a SQL Server package in SMS. The SQL Server package can then be distributed and installed on SMS computers.

Smssql.pdf includes instructions for running the batch file Smssqins.bat with Sqlins.iss (the setup initialization file) for a typical installation. Both of these files are included on the SQL Server compact disc.

To create a custom command file, edit a copy of Smssql.pdf.

See Also

Performing an Unattended Installation

Creating a Setup File Manually


Rebuilding the Registry

The Registry Rebuild option on the Advanced Options Setup screen allows you to rebuild the registry for a corrupted Microsoft® SQL Server™ installation. This process fixes only the registry; it does not fix data errors or the master database.

Important To rebuild the registry, you must enter setup information using the same choices that you entered during the initial installation. If you do not know or are not sure of this information, do not use this registry rebuild process. To restore the registry, you must uninstall and reinstall SQL Server.

To rebuild the registry

SQL Setup

SQL Setup

See Also

How to rebuild the master database (Rebuild Master utility)


Working with Named and Multiple Instances of SQL Server 2000

With Microsoft® SQL Server™ 2000, you have the option of installing multiple copies, or instances of SQL Server on one computer. When setting up a new installation of SQL Server 2000 or maintaining an existing installation, you can specify it as:

  • A default instance of SQL Server.

This instance is identified by the network name of the computer on which it is running. Applications using client software from earlier versions of SQL Server can connect to a default instance. SQL Server version 6.5 or SQL Server version 7.0 servers can operate as default instances. However, a computer can have only one version functioning as the default instance at a time.

  • A named instance of SQL Server.

    This instance is identified by the network name of the computer plus an instance name, in the format <computername>\<instancename>. Most applications must use SQL Server 2000 client components to connect to a named instance. However, the SQL Server version 7.0 Client Network Utility can be used to configure a server alias name that the SQL Server version 7.0 client components can use to connect to a named instance of SQL Server 2000. For more information about this, see SQL Server 2000 and SQL Server version 7.0 or Communicating with Multiple Instances. A computer can run any number of named instances of SQL Server concurrently. A named instance can run at the same time as an existing installation of SQL Server version 6.5 or SQL Server version 7.0. The instance name cannot exceed 16 characters.

    A new instance name must begin with a letter, an ampersand (&), or an underscore (_), and can contain numbers, letters, or other characters. SQL Server sysnames and reserved names should not be used as instance names. For example, the term "default" should not be used as an instance name because it is a reserved name used by Setup.

Single and multiple instances of SQL Server 2000 (default or named) are available using the SQL Server 2000 Personal Edition, the SQL Server 2000 Standard Edition, or the SQL Server 2000 Enterprise Edition.

Default Instances

You cannot install a default instance of SQL Server 2000 on a computer that is also running SQL Server 7.0. You must either upgrade the SQL Server 7.0 installation to a default instance of SQL Server 2000, or keep the default instance of SQL Server 7.0 and install a named instance of SQL Server 2000.

You can install a default instance of SQL Server 2000 on a computer running SQL Server 6.5, but the SQL Server 6.5 installation and the default instance of SQL Server 2000 cannot be running at the same time. You must switch between the two using the SQL Server 2000 vswitch command prompt utility.

Multiple Instances

Multiple instances occur when you have more than one instance of SQL Server 2000 installed on one computer. Each instance operates independently from any other instance on the same computer, and applications can connect to any of the instances. The number of instances that can run on a single computer depends on resources available. The maximum number of instances supported in SQL Server 2000 is 16.

When you install SQL Server 2000 on a computer with no existing installations of SQL Server, Setup specifies the installation of a default instance. However, you can choose to install SQL Server 2000 as a named instance instead by clearing the Default option in the Instance Name dialog box.

A named instance of SQL Server 2000 can be installed at any time: before installing the default instance of SQL Server 2000, after installing the default instance of SQL Server 2000, or instead of installing the default instance of SQL Server 2000.

Each named instance is made up of a distinct set of services and can have completely different settings for collations and other options. The directory structure, registry structure, and service names all reflect the specific instance name you specify.

See Also

Multiple Instances of SQL Server

Naming Conventions for Instances of SQL Server 2000

Network Protocols for Named Instances

File Locations for Multiple Instances of SQL Server

Working with Instances and Versions of SQL Server


Naming Conventions for Instances of SQL Server 2000

Because Microsoft® SQL Server™ 2000 can be set up to include one or more named instances, with or instead of a default instance, new naming conventions are used to distinguish between instances.

In earlier versions, a SQL Server installation is identified by computer name. In SQL Server 2000, only the default instance is identified solely by computer name. A named instance is identified by a combination of computer name and instance name. This instance name is also reflected in the names of the associated SQL Server services.

Note There can be only one default instance of SQL Server for each computer. It can be an intact SQL Server version 6.5 or SQL Server version 7.0 installation, or it can be an installation of SQL Server 2000 set up as the default instance. In either case, the default instance uses the same service names, registry structure, network listening points, and other defaults used in SQL Server 7.0.

Service Names for Default and Named Instances

When you install a default instance of SQL Server, the service names remain MSSQLServer and SQLServerAgent (the same as in SQL Server 7.0).

When you install a named instance of SQL Server, the service names are changed to:

  • MSSQL$InstanceName for the MSSQLServer service.

  • SQLAgent$InstanceName for the SQLServerAgent service.

The Microsoft Distributed Transaction Coordinator and Microsoft Search services are installed only once, and can be used simultaneously by every installed instance of SQL Server.

See Also

Multiple Instances of SQL Server


Network Protocols for Named Instances

When you install a default instance of Microsoft® SQL Server™ 2000, the standard network addresses are enabled. For example, named pipes uses \\.\pipe\sql\query, and TCP/IP sockets connect to port 1433.

When you select a named instance, only the Named Pipes, TCP/IP, and NWLink IPX/SPX protocols are supported. Named Pipes defaults to a network address of \\Computername\Pipe\MSSQL$instancename\Sql\Query. The port addresses used by TCP/IP and NWLink IPX/SPX are chosen dynamically (by default) the first time the instance is started.

See Also

Communicating with Multiple Instances

Multiple Instances of SQL Server

Network Libraries


File Locations for Multiple Instances of SQL Server

Each named instance of Microsoft® SQL Server™ 2000 has a specific location for its program files and another for its data files that is different from that of the default instance of SQL Server.

Note A named instance is not necessarily the same as a multiple instance. You can have a single named instance or you can have multiple named instances. For more information, see Multiple Instances of SQL Server.

For each named instance of SQL Server that you install, the default directories are:

  • \Program Files\Microsoft SQL Server\MSSQL$InstanceName\Binn for executable files.

  • \Program Files\Microsoft SQL Server\MSSQL$InstanceName\Data for data files.

Shared tools for all instances, both default and named instances, are located in the \Program Files\Microsoft SQL Server\80\Tools directory. You can specify file paths other than the default locations for program and data file for multiple instances.

The following illustration shows the simplest case of multiple instances of Microsoft SQL Server 2000: the default instance and one named instance, Instance1. A named instance has its own full set of data files and executable files. Common files used by both the default instance and any named instances are installed in the folder \Program Files\Microsoft SQL Server\80.

Note If Microsoft SQL Server version 7.0 is used as the default installation alongside a named instance of SQL Server 2000, program and data files are located at C:\Mssql7, the default location for SQL Server 7.0 files.

Finding Install Locations

If you are uncertain about instance paths, query the registry to get the installation path of a particular instance. Run the following at the command prompt, inserting the appropriate instance name:

C:\> REG QUERY HKLM\Software\Microsoft\Microsoft SQL Server\InstanceName\MSSQLServer\Setup\SQLPath

Note The REG QUERY tool is available in the Microsoft Windows® 2000 Resource Kit.

See Also

File Paths for SQL Server 2000

Multiple Instances of SQL Server


Removing Multiple Instances of SQL Server 2000

When you remove a default or named instance of Microsoft® SQL Server™ 2000, the data files and registry keys for that instance are deleted. Tools cannot be removed until all instances of SQL Server 2000 have been removed from a computer, because the tools are shared among all installed instances.

To remove a single instance of SQL Server 2000, or to remove all installed instances, see How to remove SQL Server 2000 (Windows).


Working with Instances and Versions of SQL Server

Multiple instances in Microsoft® SQL Server™ 2000 offer enhanced ways to work with earlier versions of Microsoft SQL Server already installed on your computer. You can leave previous installations intact, and also install and run SQL Server 2000. For example, you can run SQL Server version 7.0 and a named instance of SQL Server 2000 at the same time, or you can run SQL Server version 6.5 in a version switch configuration with SQL Server 2000. If you need to have three different versions of SQL Server installed on the same computer, there are several ways to accomplish this.

In addition, users of all editions of SQL Server can have more than one instance of SQL Server 2000 installed and running at once (multiple instances), as well as one or more earlier versions.

Considerations for using SQL Server 2000 in combination with previous installations include:

  • Using SQL Server 6.5 with the default instance or named instances of SQL Server 2000.

  • Running SQL Server 7.0 with a named instance of SQL Server 2000.

  • Working with three versions of SQL Server: SQL Server 6.5, SQL Server 7.0, and SQL Server 2000.

Note The concept of the default instance is new to SQL Server 2000, due to the introduction of multiple instances. If installed on the same computer as SQL Server 2000, either SQL Server version 6.5 or SQL Server version 7.0 can function as default instances of SQL Server. (A default instance is identified by the network name of the computer on which it is running.) For more information, see Working with Named and Multiple Instances of SQL Server 2000.

Using SQL Server Books Online for SQL Server 7.0

When you keep Microsoft SQL Server version 7.0 on your computer and install a named instance of SQL Server 2000, SQL Server Books Online for SQL Server 7.0 remains in its original location: C:\Mssql7\Books. In this side-by-side configuration, Books Online for SQL Server 7.0 remains accessible from the start menu in the SQL Server 7.0 program group.

Note This is an exception to what occurs for the other shared tools (such as code samples, scripts, and templates), when a named instance of SQL Server 2000 is installed along with SQL Server 7.0. All other shared tools from the 7.0 installation are copied to storage locations, with pointers to the SQL Server 2000 tools replacing previous versions of the tools. Files for Books Online for SQL Server 7.0 are not redirected in this way -- they remain ready for use.

When SQL Server 7.0 is upgraded to the default version of SQL Server 2000, the 7.0 Books Online files are also upgraded. That is, they are replaced with the SQL Server 2000 Books Online.

Whether you have SQL Server 7.0 installed or not, you can access information in the SQL Server 7.0 documentation. For more information, see How to access SQL Server Books Online for SQL Server 7.0.

See Also

Using SQL Server 6.5 with SQL Server 2000

Running SQL Server 7.0 Along with a Named Instance of SQL Server 2000

Working with Three Versions of SQL Server


Using SQL Server 6.5 with SQL Server 2000

If you have Microsoft® SQL Server™ version 6.5 installed, you can keep the SQL Server version 6.5 installation and also install a default or named instance of SQL Server 2000. No version upgrading is involved; however, version switching can be used to move between SQL Server version 6.5 and SQL Server 2000. In addition, SQL Server 2000 tools are used to control both SQL Server 2000 and SQL Server version 6.5.

Warning After SQL Server 2000 is installed, the SQL Server version 6.5 Trace utility and other earlier tools are no longer available.

To install SQL Server 2000 alongside SQL Server 6.5:

  • Keep your SQL Server 6.5 configuration intact.

  • Install SQL Server 2000, selecting either a default or named instance in the Instance Name dialog box.

  • Switch versions from SQL Server 6.5 to the default instance of SQL Server 2000.

Note Switching from SQL Server 2000 back to SQL Server 6.5 is not recommended.

If you install a default instance of SQL Server 2000 on a computer running an instance of SQL Server 6.5, the default instance of SQL Server 2000 becomes the accessible instance of SQL Server, and the SQL Server 2000 program group appears on the Start menu. The instance of SQL Server 6.5 is switched out, and the SQL Server 6.5 program group does not appear on the Start menu.

You can run either the default instance of SQL Server 2000 or the instance of SQL Server 6.5, but not both at the same time. To switch between the two versions of SQL Server, use the Microsoft SQL Server-Verswitch entry on the Start menu. When you switch from SQL Server 2000 to SQL Server 6.5, the instance of SQL Server 2000 becomes inactive, and the SQL Server 6.5 program group replaces the SQL Server 2000 program group on the Start menu. When you switch from SQL Server 6.5 to SQL Server 2000, the process is reversed.

If you install one or more named instances of SQL Server 2000 on a computer running SQL Server 6.5 and there is no default instance of SQL Server 2000, the instance of SQL Server 6.5 remains active as the default instance. Both the SQL Server 2000 and SQL Server 6.5 program groups appear on the Start menu. You should use the SQL Server 6.5 tools to manage the default instance of SQL Server 6.5, and the SQL Server 2000 tools to manage the named instances of SQL Server 2000.

If you install both named and default instances of SQL Server 2000 on a computer running SQL Server 6.5, you can run the named instances of SQL Server 2000 at any time, but must version-switch between the default instance of SQL Server 2000 and the default instance of SQL Server 6.5. The SQL Server 2000 program group always appears on the Start menu. The SQL Server 6.5 program group appears on the Start menu whenever you have version switched to make SQL Server 6.5 the active default instance. The SQL Server 6.5 program group does not appear when you have version switched to make SQL Server 2000 the active default instance.

The illustration shows an installation of SQL Server 6.5 in a version switch configuration with SQL Server 2000.

See Also

Switching Between SQL Server 6.5 and SQL Server 2000

Running SQL Server 7.0 Along with a Named Instance of SQL Server 2000

Working with Three Versions of SQL Server


Running SQL Server 7.0 Along with a Named Instance of SQL Server 2000

You can keep an installation of Microsoft® SQL Server™ version 7.0 intact on your computer and also install a named instance of SQL Server 2000 on the same computer. This configuration enables you to run both the original installation of SQL Server 7.0 and the named instance of SQL Server 2000 at the same time, without using the vswitch command prompt utility.

To run a named instance of SQL Server 2000 with an existing SQL Server 7.0 installation intact:

  • Keep SQL Server version 7.0 in its original condition with no version upgrade to SQL Server 2000. SQL Server 7.0 functions as the default instance of SQL Server, identified by the network name of the computer.

  • Install a named instance of SQL Server 2000, identified by both the network name of the computer plus an instance name.

The illustration shows this configuration.

See Also

How to install a named instance of SQL Server 2000 (Setup)

Working with Three Versions of SQL Server


Working with Three Versions of SQL Server

This topic describes two scenarios for working with SQL Server version 6.5, SQL Server version 7.0, and SQL Server 2000. One example shows three versions installed at one time, with no version upgrades, but with a version switch between SQL Server 6.5 and SQL Server 7.0. The other involves upgrading to SQL Server 2000 from SQL Server 7.0, and then version switching between SQL Server 6.5 and SQL Server 2000.

In any of these situations, multiple named instances of SQL Server 2000 can be installed as well. However, only two different versions of SQL Server can run at one time, using version switching in one of two ways:

  • Switch between SQL Server 6.5 and SQL Server 7.0.

  • Switch between SQL Server 6.5 and SQL Server 2000.
Using Version Switching

To use version switching with SQL Server 6.5 and SQL Server 7.0, while at the same time running multiple instances of SQL Server 2000:

  • Keep the SQL Server 6.5 configuration intact.

  • Keep the SQL Server 7.0 configuration intact, with no version upgrade to SQL Server 2000.

  • Install one or more named instances of SQL Server 2000.

The illustration shows how named instances of SQL Server 2000 and the existing installation of SQL Server version 7.0 can run at the same time. SQL Server version 6.5 is available to be switched in as the default instance instead of SQL Server 7.0.

To use version switching with SQL Server 6.5 and SQL Server 2000, after upgrading from SQL Server version 7.0:

  • Keep the SQL Server 6.5 configuration intact.

  • Have SQL Server 7.0 installed, but prepare to upgrade SQL Server 7.0 to SQL Server 2000.

  • Run Setup. When SQL Server 7.0 is detected, upgrade SQL Server 7.0 to the default instance of SQL Server 2000. (Select the option to Upgrade in the Existing Installation Options dialog box, and leave the Default check box selected in the Instance Name dialog box.) At this point, the installation of SQL Server 7.0 no longer exists; it is replaced by the default instance of SQL Server 2000.

The illustration shows this configuration, along with three SQL Server 2000 named instances.

See Also

Upgrading from SQL Server 7.0 to SQL Server 2000

Using SQL Server 6.5 with SQL Server 2000

Running SQL Server 7.0 Along with a Named Instance of SQL Server 2000


Failover Clustering

In Microsoft® SQL Server™ 2000 Enterprise Edition, SQL Server 2000 failover clustering provides high availability support. For example, during an operating system failure or a planned upgrade, you can configure one failover cluster to fail over to any other node in the failover cluster configuration. In this way, you minimize system downtime, thus providing high server availability.

To install, configure, and maintain a failover cluster, use SQL Server Setup. For information about upgrading to a SQL Server 2000 failover cluster, see Upgrading to a SQL Server 2000 Failover Cluster.

Use failover clustering to:

  • Install SQL Server on multiple nodes in a failover cluster. You are limited only by the number of nodes supported by the operating system.

Before installing failover clustering, you must install Microsoft Windows NT® 4.0, Enterprise Edition, Microsoft Windows® 2000 Advanced Server or Windows 2000 Datacenter Server, and the Microsoft Cluster Service (MSCS).

There are specific installation steps that must be followed to use failover clustering. For more information, see Installing Failover Clustering and Handling a Failover Cluster Installation.

  • Specify multiple IP addresses for each virtual server.

SQL Server 2000 allows you to use all available network IP subnets, thereby providing alternate ways to connect if one subnet fails and increasing network scalability. For example, with a single network adaptor, a network failure can disrupt communications. However, with multiple network cards in the server, each network can be on a different IP subnet. If one subnet fails, at least one connection can continue to function. If a router fails, MSCS continues to function, and all IP addresses still work. However, if the network card on the local computer fails, communication still may be disrupted. For more information, see Creating a Failover Cluster.

  • Administer a failover cluster from any node in the clustered SQL Server configuration. To perform setup tasks, you must be working from the node in control of the cluster disk resource. For more information, see Creating a Failover Cluster.

  • Allow one virtual server to fail over to any other node on the failover cluster configuration. For more information, see Creating a Failover Cluster.

  • Add or remove nodes from the failover cluster configuration using the Setup program. For more information, see Maintaining a Failover Cluster.

  • Reinstall or rebuild a virtual server on any node in the failover cluster without affecting the other nodes. For more information, see Maintaining a Failover Cluster.

  • Perform full-text queries by using Microsoft Search service with failover clustering. For more information, see Using SQL Server Tools with Failover Clustering.
Multiple Instance Support

Failover clustering also supports multiple instances. Multiple instance support makes it easier to build, install, and configure virtual servers in a failover cluster. Applications can connect to each instance on a single computer in much the same way as they connect to instances of SQL Server running on multiple computers. For more information about virtual servers, see Creating a Failover Cluster.

With multiple instance support, you can isolate work environments (for example, testing from production) or volatile application environments and provide different system administrators for each instance of SQL Server on the same computer. For more information, see Multiple Instances of SQL Server.

See Also

Failover Clustering Architecture


Failover Clustering Support

In Microsoft® SQL Server™ 2000 Enterprise Edition, the number of nodes supported in SQL Server 2000 failover clustering depends on the operating system you are running:

  • Microsoft Windows NT® 4.0, Enterprise Edition, Microsoft Windows® 2000 Advanced Server, and Microsoft Windows 2000 Datacenter Server support two-node failover clustering.

  • Windows 2000 Datacenter Server supports up to four-node failover clustering, including an active/active/active/active failover clustering configuration.

The following tools, features and components are supported with failover clustering:

  • Microsoft Search service. For more information, see Using SQL Server Tools with Failover Clustering.

  • Multiple instances. For more information, see Failover Clustering.

  • SQL Server Enterprise Manager. For more information, see Using SQL Server Tools with Failover Clustering.

  • Service Control Manager. For more information, see Using SQL Server Tools with Failover Clustering.

  • Replication. For more information, see Creating a Failover Cluster.

  • SQL Profiler. For more information, see Using SQL Server Tools with Failover Clustering.

  • SQL Query Analyzer. For more information, see Using SQL Server Tools with Failover Clustering.

  • SQL Mail. For more information, see Using SQL Server Tools with Failover Clustering.

The following component is not supported for failover clustering:

  • SQL Server 2000 Analysis Services

Note Microsoft Data Access Components (MDAC) 2.6 is not supported for SQL Server version 6.5 or SQL Server 7.0, when either version is in a failover cluster configuration.

Before using failover clustering, consider the following:

  • Failover clustering resources, including the IP addresses and network name, must be used only when you are running an instance of SQL Server 2000. They should not be used for other purposes, such as file sharing.

  • In a failover cluster configuration, SQL Server 2000 supports Windows NT 4.0, Enterprise Edition but requires that the service accounts for SQL Server services (SQL Server and SQL Server Agent) be local administrators of all nodes in the cluster.

Important SQL Server 2000 supports both Named Pipes and TCP/IP Sockets over TCP/IP within a failover cluster. However, it is strongly recommended that you use TCP/IP Sockets in a clustered configuration.


Creating a Failover Cluster

To create a Microsoft® SQL Server™ 2000 failover cluster, you must create and configure the virtual servers on which the failover cluster runs. You create virtual servers during SQL Server Setup. Virtual servers are not provided by Microsoft Windows NT® 4.0 or Microsoft Windows® 2000.

To create a failover cluster, you must be a local administrator with rights to log on as a service and to act as part of the operating system on all computers in the failover cluster.

Elements of a Virtual Server

A virtual server contains:

  • A combination of one or more disks in a Microsoft Cluster Service (MSCS) cluster group.

    Each MSCS cluster group can contain at most one virtual SQL Server.

  • A network name for each virtual server. This network name is the virtual server name.

  • One or more IP addresses that are used to connect to each virtual server.

  • One instance of SQL Server 2000, including a SQL Server resource, a SQL Server Agent resource, and a full-text resource.

    If an administrator uninstalls the instance of SQL Server 2000 within a virtual server, the virtual server, including all IP addresses and the network name, is also removed from the MSCS cluster group.

A failover cluster can run across one or more actual Windows 2000 Advanced Server or Windows 2000 Datacenter Server servers or Windows NT 4.0, Enterprise Edition servers that are participating nodes of the cluster. However, a SQL Server virtual server always appears on the network as a single Windows 2000 Advanced Server, Windows 2000 Datacenter Server, or Microsoft Windows NT 4.0, Enterprise Edition server.

Naming a Virtual Server

SQL Server 2000 depends on distinct registry keys and service names within the failover cluster so that operations will continue correctly after a failover. Therefore, the name you provide for the instance of SQL Server 2000, including the default instance, must be unique across all nodes in the failover cluster, as well as across all virtual servers within the failover cluster. For example, if all instances failed over to a single server, their service names and registry keys would conflict. If INST1 is a named instance on virtual server VIRTSRV1, there cannot be a named instance INST1 on any node in the failover cluster, either as part of a failover cluster configuration or as a stand-alone installation.

Additionally, you must use the VIRTUAL_SERVER\Instance-name string to connect to a clustered instance of SQL Server 2000 running on a virtual server. You cannot access the instance of SQL Server 2000 by using the computer name that the clustered instance happens to reside on at any given time. SQL Server 2000 does not listen on the IP address of the local servers. It listens only on the clustered IP addresses created during the setup of a virtual server for SQL Server 2000.

Usage Considerations

Before you create a failover cluster, consider the following:

  • If you are using the Windows 2000 Address Windowing Extensions (AWE) API to take advantage of memory greater than 3 gigabytes (GB), make certain that the maximum available memory you configure on one instance of SQL Server will still be available after you fail over to another node. If the failover node has less physical memory than the original node, instances of SQL Server may fail to start or may start with less memory than they had on the original node. You must:
    • Give each server in the cluster the same amount of physical RAM.

    • Ensure that the summed value of the max server memory settings for all instances is less than the lowest amount of physical RAM available on any of the virtual servers in the failover cluster.

    For more information about AWE, see Using AWE Memory on Windows 2000.

  • If you need high-availability servers in replication, it is recommended that you use an MSCS cluster file share as your snapshot folder when configuring a Distributor on a failover cluster. In the case of server failure, the distribution database will be available and replication will continue to be configured at the Distributor.

    Also, when creating publications, specify the MSCS cluster file share for the additional storage of snapshot files or as the location from which Subscribers apply the snapshot. This way, the snapshot files are available to all nodes of the cluster and to all Subscribers that must access it. For more information, see Publishers, Distributors, and Subscribers and Alternate Snapshot Locations.

  • If you want to use encryption with a failover cluster, you must install the server certificate with the fully qualified DNS name of the virtual server on all nodes in the failover cluster. For example, if you have a two-node cluster, with nodes named test1.redmond.corp.microsoft.com and test2.redmond.corp.microsoft.com and a virtual SQL Server "Virtsql", you need to get a certificate for "virtsql.redmond.corp.microsoft.com" and install the certificate on both nodes. You can then check the Force protocol encryption check box on the Server Network Utility to configure your failover cluster for encryption.

  • The MSCS service account must be a part of the administrator group on each node of the cluster for SQL Server. The IsAlive thread runs under the context of the cluster service account, and not the SQL Server service account. If you remove the MSCS service account, the IsAlive thread will no longer be able to create a trusted connection, and you will lose access to the virtual server.
Creating a Failover Cluster

Here are the basic steps for creating a failover cluster using the Setup program:

  1. Identify the information you need to create your virtual server (for example, cluster disk resource, IP addresses, and network name) and the nodes available for failover.

    The cluster disks to use for failover clustering should all be in a single cluster group and owned by the node from which the Setup program is run. This configuration must take place before you run the Setup program. You configure this through Cluster Administrator in Windows NT 4.0 or Windows 2000. You need one MSCS group for each virtual server you want to set up.

  2. Start the Setup program to begin your installation. After all necessary information has been entered, the Setup program installs a new instance of SQL Server binaries on the local disk of each computer in the cluster and installs the system databases on the specified cluster disk. The binaries are installed in exactly the same path on each cluster node, so you must ensure that each node has a local drive letter in common with all the other nodes in the cluster.

    In SQL Server 2000, during a failover only the databases fail over. In SQL Server version 6.5 and SQL Server version 7.0, both the SQL Server databases and binaries fail over during a failover.

    If any resource (including SQL Server) fails for any reason, the services (SQL Server, SQL Server Agent, Full-Text Search, and all services in the failover cluster group) fail over to any available nodes defined in the virtual server.

  3. You install one instance of SQL Server 2000, creating a new virtual server and all resources.

How to create a new failover cluster

SQL Setup

SQL Setup

How to install a one-node failover cluster

SQL Setup

SQL Setup

Upgrading to a SQL Server 2000 Failover Cluster

To upgrade from a SQL Server 6.5 or SQL Server 7.0 failover cluster to a SQL Server 2000 failover cluster, you must first uncluster the previous installation. SQL Server 6.5 or SQL Server 7.0 clusters cannot exist on the same computer as a failover cluster. For more information about upgrading, see Upgrading to a SQL Server 2000 Failover Cluster.

To upgrade from a SQL Server 6.5 active/passive failover cluster

SQL Setup

SQL Setup

To upgrade from a SQL Server 6.5 active/active failover cluster

SQL Setup

SQL Setup

To upgrade from a SQL Server 7.0 active/active failover cluster

SQL Setup

SQL Setup

To upgrade from a SQL Server 7.0 active/passive failover cluster

SQL Setup


Failover Clustering Example

The following example illustrates how you configure Microsoft® SQL Server™ 2000 failover clustering.

CLUSTERNODEA and CLUSTERNODEB are two computers in a failover cluster. Run SQL Server Setup on CLUSTERNODEA and create a virtual server named "SQLCLUSTA." Then install a default instance of SQL Server 2000, which can run on both CLUSTERNODEA and CLUSTERNODEB. From this point forward, connect to the server by specifying "SQLCLUSTA" as the server name in the connection string.

Run the Setup program again on CLUSTERNODEB. Create a new virtual server named "SQLCLUSTB" (in a different Microsoft Cluster Service (MSCS) cluster group) and install an instance named "Inst1" that can run on both CLUSTERNODEA and CLUSTERNODEB. From this point forward, connect to the server by specifying "SQLCLUSTB\Inst1" as the connection string.

The two virtual servers are running in the MSCS cluster consisting of CLUSTERNODEA and CLUSTERNODEB. Other than that, they are completely separate from each other. Each virtual server resides in a different MSCS cluster group, and each has a different set of IP addresses, a distinct network name, and data files that reside on a separate set of shared cluster disks.

When a failover occurs for any resource in an MSCS cluster group, all resources that are members of that group also fail over. For SQLCLUSTA, any failure (from the disk resources, IP address, the network name, or the installations of SQL Server 2000 within the virtual server) causes all members of the cluster group to fail over when the failover threshold is reached.

The following illustration is a two-node cluster with binaries and data. Each virtual server in this illustration must have exclusive ownership of the disk on which the data and log files are located.

See Also

Failover Clustering Architecture


Upgrading to a SQL Server 2000 Failover Cluster

When you are upgrading to a Microsoft® SQL Server™ 2000 failover cluster, only one default instance is allowed. Use the Cluster Wizard in SQL Server version 6.5 or SQL Server 7.0 to uncluster any existing SQL Server 6.5 or SQL Server 7.0 clustered instances before upgrading to SQL Server 2000. Then run SQL Server Setup on SQL Server 2000.

SQL Server 6.5 or SQL Server 7.0 failover clusters cannot exist on the same computer as a SQL Server 2000 failover cluster. In SQL Server 6.5 or SQL Server 7.0, in an active/active configuration or in an active/passive configuration where one server contains an unclustered SQL Server, there is a name conflict. Both servers are default instances.

Important You cannot run the Cluster Wizard in SQL Server 6.5 or SQL Server 7.0 after SQL Server 2000 has been installed.

For SQL Server 2000, you must use a domain account for the services (SQL Server, SQL Server Agent, and all services in the clustered group). That account must be an administrator on all computers in the cluster, if those computers are running on Microsoft Windows NT® Server 4.0, Enterprise Edition.

Note If you are using replication on a SQL Server 6.5 or 7.0 failover cluster and upgrading to a SQL Server 2000 failover cluster, you must uncluster the previous installation. Delete all publications, remove replication, and then reconfigure replication after upgrading. This will not be a requirement when upgrading from SQL Server 2000 in future releases.

To upgrade from a SQL Server 6.5 active/passive failover cluster

SQL Setup

SQL Setup

To upgrade from a SQL Server 6.5 active/active failover cluster

SQL Setup

SQL Setup

To upgrade from a SQL Server 7.0 active/active failover cluster

SQL Setup

SQL Setup

To upgrade from a SQL Server 7.0 active/passive failover cluster

SQL Setup


Handling a Failover Cluster Installation

When you install a Microsoft® SQL Server™ 2000 failover cluster, you must:

  • Ensure that the operating system is installed properly and designed to support failover clustering. For more information about what to do before installing a failover cluster, see Before Installing Failover Clustering. For more information about the order of installation, see Installing Failover Clustering.

  • Consider whether the SQL Server tools, features, and components you want to use are supported with failover clustering. For more information, see Failover Clustering Support.

  • Consider whether failover clustering is dependent on the products you want to use. For more information, see Failover Clustering Dependencies.

  • Consider how to create a new failover cluster. For more information about creating a new failover cluster configuration, see Creating a Failover Cluster.

  • Review the instructions for upgrading from a SQL Server version 6.5 or SQL Server version 7.0 cluster to a SQL Server 2000 failover cluster. For more information, see Upgrading to a SQL Server 2000 Failover Cluster.


Before Installing Failover Clustering

Before you install a Microsoft® SQL Server™ 2000 failover cluster, you must select the operating system on which your computer will run. You can use Microsoft Windows NT® 4.0, Enterprise Edition, Microsoft Windows® 2000 Advanced Server, or Microsoft Windows 2000 Datacenter Server. You also must install Microsoft Cluster Service (MSCS).

Preinstallation Checklist

Before you begin the installation process, verify that:

  • There is no IRQ sharing between network interface cards (NICs) and drive/array (SCSI) controllers. Although some hardware may support this sharing, it is not recommended.

  • Your hardware is listed on the Windows NT Hardware Compatibility List.

    For a complete list of supported hardware, see the Hardware Compatibility List at the Microsoft Web site.

    The hardware system must appear under the category of cluster. Individual cluster components added together do not constitute an approved system. Only systems purchased as a cluster solution and listed in the cluster group are approved. When checking the list, specify cluster as the category. All other categories are for OEM use.

  • MSCS has been installed completely on at least one node before you run Windows NT 4.0, Enterprise Edition or Windows 2000 Advanced Server or Windows 2000 Datacenter Server simultaneously on all nodes.

    When using MSCS, you must make certain that one node is in control of the shared SCSI bus prior to the other node(s) coming online. Failure to do this can cause application failover to go into an online pending state. As a result, the cluster either fails on the other node or fails totally. However, if your hardware manufacturer has a proprietary installation process, follow the hardware manufacturer instructions.

  • WINS is installed according to the following article in the Product Support Services Microsoft Web site:

    Q258750 Recommended Private "Heartbeat" Configuration on Cluster Server

  • The disk drive letters for the cluster-capable disks are the same on both servers.

  • You have disabled NetBIOS for all private network cards before beginning SQL Server Setup.

  • You have cleared the system logs in all nodes and viewed the system logs again. Ensure that the logs are free of any error messages before continuing.


Installing Failover Clustering

If you are installing Microsoft® SQL Server™ 2000 failover clustering on Microsoft Windows NT® 4.0, Enterprise Edition, you need to install programs in the order specified below. However, this is not necessary if you are installing failover clustering on Microsoft Windows® 2000 Advanced Server or Windows 2000 Datacenter Server.

Caution If you do not install the programs in the following order, the software products can fail on installation and require that you completely reinitialize the disk and restart installation.

Before installing SQL Server 2000 in a failover cluster configuration, you must upgrade any pre-release versions of SQL Server 2000.

To install failover clustering on Windows NT 4.0

  1. Install Windows NT 4.0, Enterprise Edition.

    Windows NT 4.0, Enterprise Edition includes Windows NT 4.0 Service Pack 3. Service Pack 3 is required to install Microsoft Cluster Service (MSCS).

    • Do not go directly to Service Pack 4 or later if you intend to install the Windows NT Option Pack.

    • Do not install Microsoft Internet Information Server (IIS).

    Important IIS is installed by default. It is recommended that you clear this option during the Windows NT 4.0 installation.

  2. Install MSCS.

  3. Install Microsoft Internet Explorer version 5.0 or later.

  4. Manually create a Microsoft Distributed Transaction Coordinator (MS DTC) compatible resource group where MS DTC setup can create its resources. This should contain an IP address, network name, and cluster disk resource. Any group with these three things is compatible with MS DTC.

    SQL Server Setup will install MS DTC in a later step. Install Windows NT 4.0 Option Pack only if you require components of the Windows NT 4.0 Option pack besides MS DTC.

  5. Install the latest Windows NT 4.0 Service Pack, Service Pack 5 at the latest. Click Create an uninstall directory, click Year 2000 Setup, and then select the Service Pack install for Intel based systems check box.

    Do not select Microsoft Message Queue Server (MSMQ 1.0) or IIS. MSMQ 1.0 is not supported on SQL Server 2000. It is recommended that IIS functionality be used with Windows NT Load Balancing Service (WLBS). For more information about WLBS, search on "WLBS Features Overview" on the NT Server Microsoft Web site.

    Prior to Step 5, it is recommended that you rename the hidden directory $NTServicePackUninstall$ to $NTServicePackUninstall$.service packnumber. After installing the service pack, add a new directory. This way you have uninstall directories available, which prevents the directories from being accidentally overwritten.

  6. Install SQL Server 2000.

Note Install any additional server products before installing any other applications.

To install failover clustering on Windows 2000

  1. Install Windows 2000 and accept the default application choices.

  2. After installing Windows 2000 on the first node and prior to installing MSCS, click Start\Programs\Administrative Tools\Configure Your Server.

  3. Click Advanced\Cluster Service, and then in the right pane, click Learn More.

  4. From Help, review Item 2 under Windows Clustering.

    Windows Clustering is used during the installation of Windows 2000 and with SQL Server 2000 failover clustering. Follow these instructions to install MSCS.

    Important It is necessary to read the section on Planning for Windows Clustering\Requirements for server clusters and to follow the Checklist for server clusters called Checklist: Creating a server cluster. This is found under the Server Clusters section\Checklist for server clusters.

  5. After you have successfully installed MSCS, you need to configure MS DTC to run on a cluster.

    For more information about MS DTC, see Failover Clustering Dependencies.

  6. On the Start menu, point to Programs\Administrative Tools\Cluster Administrator, and click View Groups\Cluster Group. If the group contains an MS DTC resource, proceed to Step 9. If not, complete the following two steps.

  7. On the Start menu, point to Command Prompt. Enter comclust.exe from the command prompt.

  8. Repeat Step 7 on the remaining nodes of the cluster, one node at a time.

  9. Install SQL Server 2000.

Note Install any additional server products before installing any user applications.


Failover Clustering Dependencies

There are several products that interact with Microsoft® SQL Server™ 2000 failover clustering. To ensure that your failover cluster functions properly, you need to understand the underlying dependencies that failover clustering has on other products.

Microsoft Distributed Transaction Coordinator (MS DTC)

SQL Server 2000 requires Microsoft Distributed Transaction Coordinator (MS DTC) in the cluster for distributed queries and two-phase commit transactions, as well as for some replication functionality. After you install Microsoft Windows® 2000 and configure your cluster, you must run the Cluster Wizard (the comclust.exe program) on all nodes to configure MS DTC to run in clustered mode.

The Cluster Wizard makes the following changes to the MS DTC configuration:

  • It creates an MS DTC resource in a resource group containing a shared cluster disk resource and a network name resource.

  • It creates an MS DTC log file on the shared cluster disk contained in the MS DTC resource group. Placing the MS DTC log file on the shared cluster disk makes it possible for the MS DTC transaction manager to access the MS DTC log file from any system in the cluster.

  • It copies critical MS DTC registry entries to the shared cluster registry.
Running MS DTC in Clustered Mode

When MS DTC is running in clustered mode, only one node in the cluster runs the MS DTC transaction manager at a time.

Any process running on any node in the cluster can use MS DTC. These processes simply call the MS DTC Proxy and the MS DTC Proxy automatically forwards MS DTC calls to the MS DTC transaction manager that is controlling the entire cluster.

If the node running the MS DTC transaction manager fails, the MS DTC transaction manager is automatically restarted on another node in the cluster. The newly restarted MS DTC transaction manager reads the MS DTC log file on the shared cluster disk to determine the outcome of pending and recently completed transactions. Resource managers reconnect to the MS DTC transaction manager and perform recovery to determine the outcome of in-doubt transactions. Applications reconnect to MS DTC so they can initiate new transactions.

For example, suppose the MS DTC transaction manager is active on system B. The application program and resource manager on system A call the MS DTC proxy. The MS DTC proxy on system A forwards all MS DTC calls to the MS DTC transaction manager on system B.

If system B fails, the MS DTC transaction manager on system A will take over. It will read the entire MS DTC log file on the shared cluster disk, perform recovery, and then serve as the transaction manager for the entire cluster.

Note The MS DTC transaction manager, MS DTC Proxy, and Component Services administrative tools are installed on each node of a Windows 2000 cluster using MSCS as part of Windows 2000 Setup.

To manually install MS DTC on a Windows 2000 system running MSCS

  1. Install Windows 2000 on each node in the cluster.

  2. Use the Windows 2000 Configure Your Server facility to configure your cluster.

  3. From a command prompt, run comclust.exe on each node in the cluster. Comclust.exe can be found in the system32 directory.

To automatically install MS DTC on a Windows 2000 cluster system

  1. Install Windows 2000 on each node in the cluster and configure your cluster using automatic installation scripts.

  2. From a command prompt, run comclust.exe on each node in the cluster. Comclust.exe can be found in the system32 directory.

To upgrade a non-clustered Windows NT 4.0 SP4 system to a Windows 2000 cluster

  1. Upgrade each system that will be part of the cluster to Windows 2000.

  2. Use the Windows 2000 Configure Your Server facility to configure your server.

  3. From a command prompt, run comclust.exe on each node in the cluster. Comclust.exe can be found in the system32 directory.

To upgrade a clustered Windows NT 4.0 SP4 system to a Windows 2000 cluster

  1. Install Windows 2000 on each node in the cluster.

    MS DTC requires that all nodes in the cluster be upgraded to Windows 2000 at the same time.

  2. From a command prompt, run comclust.exe on each node in the cluster. Comclust.exe can be found in the system32 directory.

Important Microsoft System Management Server 1.2 is not supported with SQL Server or Microsoft Cluster Service (MSCS).

To recover from a cluster failure and rebuild MS DTC on a Windows 2000 cluster

  1. When a node is lost, MS DTC will continue to work on the remaining nodes in the cluster. It does not matter whether the node that is lost is the primary or secondary node.

  2. When you are ready to restore the lost node, join the lost node back to the cluster. After the node has joined the cluster, run Comclust.exe, which can be found in the system32 directory. This will reconfigure MS DTC on the node.


Maintaining a Failover Cluster

After you have installed a Microsoft® SQL Server™ 2000 failover cluster, you can change or repair your existing setup. For example, you can add additional nodes to a virtual server in a failover cluster, run a clustered instance as a stand-alone instance, remove a node from a clustered instance, or recover from failover cluster failure.

Adding a Node to an Existing Virtual Server

During SQL Server Setup, you are given the option of maintaining an existing virtual server. If you choose this option, you can add other nodes to your failover cluster configuration at a later time. You can add up to three additional nodes to an existing virtual server configured to run on one node.

To add a node to an existing virtual server

SQL Setup

SQL Setup

Removing a Node from an Existing Failover Cluster

You can remove a node from a virtual server (for example, if a node is damaged). Each node in a virtual SQL Server is considered a peer, and you can remove any node.

A removed node can be added back to a failover cluster at any time. For example, a removed node can be rebuilt after a failure and added back to the failover cluster. Alternately, if a node is temporarily unavailable and later comes back online and an instance of SQL Server 2000 from the affected virtual server is still in place, the Setup program removes this instance from the computer before installing the binaries on the node again.

Note A damaged node does not have to be available to be removed, but the removal process will not uninstall any of the binaries from the unavailable node.

To remove a node from an existing failover cluster

SQL Setup

SQL Setup

Running a Clustered Instance of SQL Server as a Stand-Alone Instance

Usually, you run a clustered instance of SQL Server under the control of Microsoft Cluster Service (MSCS). However, it may be necessary to run a clustered instance of SQL Server as a stand-alone instance (for example, when you want to perform administrative operations like running an instance of SQL Server in single-user mode). To connect to a clustered instance of SQL Server 2000 in stand-alone mode using sockets, both the IP address and network name resources must be online for the virtual server on which the instance was installed.

If these resources cannot be online, connect using Named Pipes. However, you must create an alias on the client side to talk to the pipe name on which the instance of SQL Server is listening. Use SQL Server Network Utility to find out the pipe name. For more information, see Failover Cluster Troubleshooting.

Recovering from Failover Cluster Failure

Usually, there are two scenarios that cause failover cluster failure:

  • In Scenario 1, failure is caused by hardware failure in Node 1 of a two-node cluster. This hardware failure could be caused by a failure in the SCSI card or the operating system.

    To recover from this failure, first remove the failover cluster using the Setup program.

    To remove a failover clustered instance

    SQL Setup

    SQL Setup

    To recover from failover cluster failure in Scenario 1

    SQL Setup

    SQL Setup

  • In Scenario 2, failure is caused by Node 1 being down or offline, but not irretrievably broken. This could be caused by an operating system failure. However, recovering from operating system failure using the steps below can take time. If the operating system failure can be recovered easily, avoid using Scenario 2.

    To recover from this failure, first remove the failover cluster using the Setup program.

    To remove a failover clustered instance

    SQL Setup

    SQL Setup

    To recover from failover cluster failure in Scenario 2

    SQL Setup

    SQL Setup

Changing Service Accounts

You should not change the passwords for any of the SQL Server service accounts when a failover cluster node is down or offline. If you have to do this, you will need to reset the password again using Enterprise Manager when all nodes are back online.

If the service account for SQL Server is not an administrator in a cluster, the administrative shares cannot be deleted on any nodes of the cluster. The administrative shares must be available in a cluster for SQL Server to function.

See Also

Handling a Failover Cluster Installation

SQL Server Network Utility


Using SQL Server Tools with Failover Clustering

You can use Microsoft® SQL Server™ 2000 failover clustering with a variety of SQL Server tools and features. However, review the following usage considerations.

Full-Text Queries

To use the Microsoft Search service to perform full-text queries with failover clustering, consider the following:

  • An instance of SQL Server 2000 must run on the same system account on all failover cluster nodes in order for full-text queries to work on failover clusters.

  • You must change the start-up account for SQL Server 2000 in the failover cluster using SQL Server Enterprise Manager. If you use Control Panel or the Services Application in Microsoft Windows® 2000, you will break the full-text configuration for SQL Server.
SQL Server Enterprise Manager

To use SQL Server Enterprise Manager with failover clustering, consider the following:

  • You must change the start-up account for SQL Server 2000 in the failover cluster by using SQL Server Enterprise Manager. If you use Control Panel or the Services Application in Microsoft Windows 2000, you could break your server configuration.

  • When creating or altering databases, you will only be able to view the cluster disks for the local virtual server.

  • If you are browsing a table through SQL Server Enterprise Manager and lose the connection to SQL Server during a failover, you will see the error message, "Communication Link Failure". You must press ESC and undo the changes to exit out of the SQL Server Enterprise Manager window. You cannot click Run Query, save any changes, or edit the grid.

  • If you use Enterprise Manager to reset the properties of the SQL Server service account, you will be prompted to restart SQL Server. When SQL Server is running in a failover cluster configuration, this will bring the full text and SQL Agent resources offline, as well as SQL Server. However, when SQL Server is restarted, it will not bring the full text or SQL Agent resources back online. You must start those resources manually using the Windows Cluster Administrator utility.
Service Control Manager

Use the Service Control Manager to start or stop a clustered instance of SQL Server. You cannot pause a clustered instance of SQL Server.

To start a clustered instance of SQL Server using Service Control Manager

Service Manager

Service Manager

To stop a clustered instance of SQL Server using Service Control Manager

Service Manager

Service Manager

SQL Profiler

You can use SQL Profiler with failover clustering. However, if you experience a failover on a server where you are running a SQL Profiler trace, you must restart the trace when the server is back online to continue tracing.

SQL Query Analyzer

You can use SQL Query Analyzer with failover clustering. However, if you experience a failover on a server where you are executing a query, you must restart the query when the server is back online to continue execution.

SQL Mail

To use SQL Mail with failover clustering, consider the following:

  • An instance of SQL Server 2000 must run on the same Microsoft Windows NT® 4.0 and Windows 2000 account on all failover cluster nodes in order for SQL Mail to work on failover clusters.

  • Each failover cluster node must have a MAPI profile with an identical name and settings. For more information, see Configuring Mail Profiles.

See Also

SQL Mail

Microsoft Search Service

SQL Query Analyzer

Monitoring with SQL Profiler

SQL Server Enterprise Manager

Starting, Pausing, and Stopping SQL Server


Failover Cluster Troubleshooting

This topic provides information about:

  • Resolving the most common Microsoft® SQL Server™ 2000 failover clustering usage issues.

  • Optimizing failover cluster performance.

  • Using failover clustering with extended stored procedures that use COM objects.
Resolving Common Usage Issues

The following list describes common usage issues and explains how to resolve them:

  • SQL Server 2000 cannot log on to the network after it migrates to another node.

    SQL Server service account passwords must be identical on all nodes or else the node cannot restart a SQL Server service that has migrated from a failed node.

    If you change the SQL Server service account passwords on one node, you must change the passwords on all other nodes. However, if you change the account using SQL Server Enterprise Manager, this task will be done automatically.

  • SQL Server cannot access the cluster disks.

    A node cannot recover cluster disks that have migrated from a failed node if the shared cluster disks use a different letter drive. The disk drive letters for the cluster disks must be the same on both servers. If they are not, review your original installation of the operating system and Microsoft Cluster Service (MSCS). For more information, see the Microsoft Windows NT® 4.0, Enterprise Edition, Windows® 2000 Advanced Server, or Windows 2000 Datacenter Server documentation.

  • You do not want a failure of a service, such as full-text search or SQL Server Agent, to cause a failover.

    To prevent the failure of specific services from causing the SQL Server group to fail over, configure those services using Cluster Administrator in Windows NT 4.0 or Windows 2000. For example, to prevent the failure of the Full-Text Search service from causing a failover of SQL Server, clear the Affect the Group check box on the Advanced tab of the Full Text Properties dialog box. However, if SQL Server causes a failover, the full-text search service will restart.

  • SQL Server will not start automatically.

    You cannot start a failover cluster automatically using SQL Server. You must use Cluster Administrator in MSCS to automatically start a failover cluster.

  • The error message "No compatible resource groups found" is displayed during SQL Server Setup.

    This error is caused by the Microsoft Distributed Transaction Coordinator (MS DTC) setup on Windows NT 4.0, Enterprise Edition. MS DTC requires a group containing a network name, IP address, and shared cluster disk to be owned by the local node when the Setup program is run. If this error is displayed, open Cluster Administrator and make certain there is a group that meets these requirements owned by the local node. The easiest way to do this is to move a disk into the cluster group that already contains a network name and IP address. After you have this group on the local node, click Retry.

  • The error message "All cluster disks available to this virtual server are owned by other node(s)" is displayed during Setup.

    This message is displayed when you select the drive and path for installing data files, and the drive you selected is not owned by the local node. Move the disk to the local node using Cluster Administrator.

  • The error message "Unable to delete SQL Server resources. They must be manually removed. Uninstallation will continue." is displayed during SQL Server Setup.

    This message is displayed if SQL Server Setup cannot delete all of the SQL Server resources. You must go into Control Panel and uninstall the instance you were trying to remove on every node.

  • You cannot enable the clustering operating system error log.

    The operating system cluster error log is used by MSCS to record information about the cluster. Use this error log to debug cluster configuration issues. To enable the cluster error log, set the system environment variable CLUSTERLOG=<path to file> (for example, CLUSTERLOG=c:\winnt\cluster\cluster.log). This error log is on by default in Windows 2000.

  • If the Network Name is offline and you cannot connect using TCP/IP, you must use Named Pipes.

    To connect using Named Pipes, create an alias using the Client Network Utility to connect to the appropriate computer. For example, if you have a cluster with two nodes (Node A and Node B), and a virtual server (Virtsql) with a default instance, you can connect to the server that has the Network Name resource offline by doing the following:

    1. Determine on which node the group containing the instance of SQL Server is running by using the Cluster Administrator. For this example, it will be Node A.

    2. Start the SQL Server service on that computer using net start. For more information about using net start, see Starting SQL Server Manually.

    3. Start the SQL Server Network Utility on Node A. View the pipe name on which the server is listening. It should be similar to \\.\$$\VIRTSQL\pipe\sql\query.

    4. On the client computer, start the Client Network Utility.

    5. Create an alias SQLTEST1 to connect via Named Pipes to this pipe name. To do this, put Node A as the server name and edit the pipe to be \\.\pipe\$$\VIRTSQL\sql\query. Connect to this instance using the alias SQLTEST1 as the server name.

    For more information, see Client Net-Libraries and Network Protocols.

Optimizing Failover Clustering Performance

To optimize performance when using failover clustering, consider the following:

  • If your disk controller is not external to your clustered computer, you must turn off write-caching within the controller to prevent data loss during a failover.

  • Write-back caching cannot be used on host controllers in a cluster without hindering performance. However, if you use external controllers, you continue to provide performance benefits. External disk arrays are not affected by failover clustering and can sync the cache correctly, even across a SCSI bus.

  • It is recommended that you do not use the cluster drive for file shares. Using these drives impacts recovery times and can cause a failover of the cluster group due to resource failures.
Using Extended Stored Procedures and COM Objects

When you use extended stored procedures with a failover clustering configuration, all extended stored procedures need to be installed on the shared cluster disk. This is to ensure that when a node fails over, the extended stored procedures can still be used.

If the extended stored procedures use COM components, the administrator needs to register the COM components on each node of the cluster. The information for loading and executing COM components must be in the registry of the active node in order for the components to be created. Otherwise, the information will remain in the registry of the computer on which the COM components were first registered. For more information, see Extended Stored Procedure Architecture.


How to create a new failover cluster (Setup)

New Information - SQL Server 2000 SP3.

Important Before you create a Microsoft® SQL Server™ 2000 failover cluster, you must configure Microsoft Cluster Service (MSCS) and use Cluster Administrator in Microsoft Windows NT® 4.0 or Windows® 2000 to create at least one cluster disk resource. Note the location of the cluster drive in the Cluster Administrator before you run SQL Server Setup because you need this information to create a new failover cluster.

To create a new failover cluster

  1. On the Welcome screen of the Microsoft SQL Server Installation Wizard, click Next.

  2. On the Computer Name screen, click Virtual Server and enter a virtual server name. If Setup detects that you are running MSCS, it will default to Virtual Server. Click Next.

  3. On the User Information screen, enter the user name and company. Click Next.

  4. On the Software License Agreement screen, click Yes.

  5. On the Failover Clustering screen, enter one IP address for each network configured for client access. That is, enter one IP address for each network on which the virtual server will be available to clients on a public (or mixed) network. Select the network for which you want to enter an IP address, and then enter the IP address. Click Add.

    The IP address and the subnet are displayed. The subnet is supplied by MSCS. Continue to enter IP addresses for each installed network until you have populated all desired networks with an IP address. Click Next.

  6. On the Cluster Disk Selection screen, select the cluster disk group where the data files will be placed by default. Click Next.

  7. On the Cluster Management screen, review the cluster definition provided by SQL Server 2000. By default, all available nodes are selected. Remove any nodes that will not be part of the cluster definition for the virtual server you are creating. Click Next.

  8. On the Remote Information screen, enter login credentials for the remote cluster node. The login credentials must have administrator privileges on the remote node(s) of the cluster. Click Next.

  9. On the Instance Name screen, choose a default instance or specify a named instance. To specify a named instance, clear the Default check box, and then enter the name for the named instance. Click Next.

    Important You cannot name an instance DEFAULT or MSSQLSERVER. For more information about naming instances of SQL Server 2000, see Working with Named and Multiple Instances of SQL Server 2000. Names must follow rules for SQL Server identifiers. For more information about naming conventions for identifiers, see Using Identifiers.

  10. On the Setup Type screen, select the type of installation to install. The Setup program automatically defaults to the first available cluster disk resource from the group you previously selected.

    However, if you need to specify a different clustered drive resource, under Data Files, click Browse and then specify a path on a clustered drive resource. You will be required to select a clustered drive resource that is owned by the node on which you are running the Setup program. The drive also must be a member of the cluster group you previously selected. Click Next.

  11. On the Services Accounts screen, select the service account(s) that you want to run in the failover cluster. Click Next.

  12. In the Authentication Mode dialog box, choose the authentication mode to use. If you change the selection from Windows Authentication Mode to Mixed Mode (Windows Authentication and SQL Server Authentication), you need to enter and confirm a password for the sa login.

    Security Note When possible, use Windows Authentication.

  13. On the Start Copying Files screen, click Next.

  14. On the Setup Complete screen, click Finish.

    If you are instructed to restart the computer, do so now. It is important to read the message from the Setup program when you are done with installation. Failure to restart any of the specified nodes may cause failures when you run the Setup program in the future on any node in the failover cluster.


How to install a one-node failover cluster (Setup)

  1. On the Welcome screen of the Microsoft SQL Server Installation Wizard, click Next.

  2. On the Computer Name screen, click Virtual Server and enter a virtual server name. If SQL Server Setup detects that you are running Microsoft® Cluster Service (MSCS), it will default to Virtual Server. Click Next.

  3. On the User Information screen, enter the user name and company. Click Next.

  4. On the Software License Agreement screen, click Yes.

  5. On the Failover Clustering screen, enter one IP address per installed network for the virtual server. Select the network for which you wish to enter an IP address, and then enter the IP address. Click Add.

    The IP address and the subnet are displayed. The subnet is supplied by MSCS. Continue to enter IP addresses for each installed network until you have populated all desired networks with an IP address. Click Next.

  6. On the Cluster Disk Selection screen, select the cluster disk group where the data files will be placed by default. Click Next.

  7. On the Cluster Management screen, review the failover cluster definition provided by Microsoft SQL Server™ 2000. By default, all available nodes are selected. Remove any nodes that will not be part of the cluster definition for the virtual server you are creating. Click Next.

  8. On the Remote Information screen, enter login credentials that have administrator privileges on the remote node of the cluster. Click Next.

  9. On the Instance Name screen, choose a default instance or specify a named instance. To specify a named instance, clear the Default check box, and then enter the name. Click Next.

    Important You cannot name an instance DEFAULT or MSSQLSERVER. The name must follow the rules for SQL Server identifiers. For more information about naming conventions for identifiers, see Using Identifiers.

  10. On the Setup Type screen, select the type of installation to install. Setup will automatically default to the first available clustered disk resource from the group you previously selected. However, if you need to specify a different clustered drive resource, under Data Files, click the Browse button and then specify a path on a clustered drive resource. You will be required to select a clustered drive resource that is owned by the node on which you are running Setup. The drive must also be a member of the cluster group you previously selected. Click Next.

  11. On the Services Accounts screen, select the service account(s) that you want to run in the failover cluster. Click Next.

  12. In the Authentication Mode dialog box, choose the authentication mode to use. If you change the selection from Windows Authentication Mode to Mixed Mode (Windows Authentication and SQL Server Authentication), you must enter and confirm a password for the sa login.

  13. Security Note When possible, use Windows Authentication.

    On the Start Copying Files screen, click Next.

  14. On the Setup Complete screen, click Finish. If you are instructed to restart the computer, do so now. It is important to read the message from the Setup program when you are done with installation. Failure to restart any of the specified nodes may cause failures when running the Setup program in the future on any node in the cluster.


How to add nodes to an existing virtual server (Setup)

  1. On the Welcome screen of the Microsoft SQL Server Installation Wizard, click Next.

  2. On the Computer Name screen, click Virtual Server and specify the virtual server to which you want to add a node. Click Next.

  3. On the Installation Selection screen, click Advanced options. Click Next.

  4. On the Advanced Options screen, click Maintain a virtual server for failover clustering. Click Next.

  5. On the Failover Clustering screen, click Next.

    You do not need to enter an IP address.

  6. On the Cluster Management screen, select the node and click Add.

    If the node is listed as unavailable, you must modify the disk resources in the cluster group of the virtual server so the disk is available for the node you want to add to the Microsoft® SQL Server™ configuration. Click Next.

  7. On the Remote Information screen, enter login credentials for the remote cluster node that has administrator privileges on the remote node of the cluster. Click Next.

  8. On the Setup Complete screen, click Finish.


How to remove a node from an existing failover cluster (Setup)

  1. On the Welcome screen of the Microsoft SQL Server Installation Wizard, click Next.

  2. On the Computer Name screen, click Virtual Server and specify the name of the server from which to remove the node. Click Next.

  3. You may see an error message saying that one (or more) of the nodes of the Microsoft® Windows NT® 4.0 or Microsoft Windows® 2000 cluster are unavailable. This may be because the node(s) you are attempting to remove is damaged. The node(s) still can be removed. Click OK.

  4. On the Installation Selection screen, click Advanced Options. Click Next.

  5. On the Advanced Options screen, click Maintain a virtual server for failover clustering. Click Next.

  6. On the Failover Clustering screen, click Next.

    You do not need to modify any IP address(es).

  7. On the Cluster Management screen, select the node and click Remove. Click Next.

  8. On the Remote Information screen, enter login credentials for the remote cluster node that has administrator privileges on the remote node(s) of the cluster. Click Next.

  9. On the Setup Complete screen, click Finish.

    If you are instructed to restart the computer, do so now. It is important to read the message from SQL Server Setup when you are done with installation. Failure to restart any of the specified nodes may cause failures when you run the Setup program in the future on any node in the failover cluster.


How to remove a failover clustered instance (Setup)

  1. On the Welcome screen of the Microsoft SQL Server Installation Wizard, click Next.

  2. On the Computer Name screen, click Virtual Server and specify the name of the server from which to remove a clustered instance. Click Next.

  3. On the Installation Selection screen, click Upgrade, remove, or add components to an existing instance of SQL Server.

  4. On the Instance Name screen, for a default instance, click Default. For a named instance, specify the name of the instance to remove. Click Next.

  5. On the Existing Installation screen, click Uninstall your existing installation. Click Next.

  6. On the Remote Information screen, specify the password that is a valid administrator password on all nodes in the cluster. Click Next.

  7. In the Setup message "Successfully uninstalled the instance . . . ", click OK.

  8. On the Setup Complete screen, click Finish.

    If you are instructed to restart the computer, do so now. It is important to read the message from SQL Server Setup when you are done with installation. Failure to restart any of the specified nodes may cause failures when you run the Setup program in the future on any node in the failover cluster.


How to recover from failover cluster failure in Scenario 1

In this scenario, failure is caused by hardware failure in Node 1 of a two-node cluster. This hardware failure could be caused, for example, by the failure of a small computer system interface (SCSI) card or the operating system.

  1. After Node 1 fails, the Microsoft® SQL Server™ 2000 failover cluster fails over to Node 2.

  2. Run SQL Server Setup and remove Node 1. For more information, see How to remove a failover clustered instance .

  3. Evict Node 1 from Microsoft Cluster Service (MSCS). To evict a node from MSCS, from Node 2, right-click on the node to remove, and then click Evict Node.

  4. Install new hardware to replace the failed hardware in Node 1.

  5. Install the operating system. For more information about which operating system to install and specific instructions on how to do this, see Before Installing Failover Clustering.

  6. Install MSCS and join the existing cluster. For more information, see Before Installing Failover Clustering.

  7. Run the Setup program on Node 2 and add Node 1 back to the failover cluster. For more information, see How to add nodes to an existing virtual server (Setup).


How to recover from failover cluster failure in Scenario 2

In Scenario 2, failure is caused by Node 1 being down or offline but not irretrievably broken. This could be caused, for example, by an operating system failure.

  1. After Node 1 fails, the Microsoft® SQL Server™ 2000 failover cluster fails over to Node 2.

  2. Run SQL Server Setup and remove Node 1. For more information, see How to remove a failover clustered instance.

  3. Resolve the problem with Node 1.

  4. Ensure that the Microsoft Cluster Service (MSCS) cluster is working and all nodes are online.

  5. Run the Setup program on Node 2 and add Node 1 back to the failover cluster. For more information, see How to add nodes to an existing virtual server (Setup).


How to upgrade from a SQL Server 6.5 active/passive failover cluster (Setup)

To upgrade from a SQL Server 6.5 active/passive failover cluster

  1. Uncluster Microsoft® SQL Server™ version 6.5.

  2. Install a default instance of SQL Server 2000.

    You must install the binaries to a local drive and use a cluster disk for the data. This local drive is a path, which is a non-clustered disk valid on all nodes of the cluster. On all nodes of the cluster, this drive must have at least 300 megabytes (MB) of available space.

  3. Run the SQL Server Upgrade Wizard to migrate your data into SQL Server 2000.

  4. Uninstall SQL Server 6.5.

  5. Run SQL Server Setup to upgrade your default instance of SQL Server 2000 to a SQL Server 2000 failover cluster.

    For more information, see How to upgrade from a default instance to a default clustered instance of SQL Server 2000 (SQL Server Setup).

See Also

How to perform a SQL Server version 6.5 to SQL Server 2000 upgrade using a direct pipeline (SQL Server Upgrade Wizard)

How to perform a SQL Server version 6.5 to SQL Server 2000 upgrade using a tape drive (SQL Server Upgrade Wizard)


How to upgrade from a SQL Server 6.5 active/active failover cluster (Setup)

Note To upgrade from a Microsoft® SQL Server™ 6.5 active/active failover cluster (or any configuration where SQL Server exists on the second node), you must first convert one side of the failover cluster to a named instance of SQL Server 2000.

To upgrade from a SQL Server 6.5 active/active failover cluster

  1. On Node 1, uncluster SQL Server 6.5. On Node 2, uncluster SQL Server 6.5.

  2. On Node 1, install a default (non-clustered) instance of SQL Server 2000.

    You must install the binaries to a local drive and use a cluster disk for the data. This local drive is a path, which is a non-clustered disk valid on all nodes of the cluster. This drive on all nodes of the cluster must have at least 300 megabytes (MB) of available space.

  3. On Node 1, run the SQL Server 2000 Upgrade Wizard to migrate your data into SQL Server 2000.

  4. On Node 1, uninstall the instance of SQL Server 6.5.

  5. On Node1, install a named, clustered instance of SQL Server 2000.

  6. Run the Copy Database Wizard (CDW.exe) to migrate your SQL Server data (originally from SQL Server 6.5) to a named instance in a SQL Server 2000 failover cluster. For more information about the Copy Database Wizard, see Using the Copy Database Wizard or How to upgrade databases online using the Copy Database Wizard (Enterprise Manager).

  7. On Node 1, uninstall the default instance of SQL Server 2000.

  8. On Node 2, install a default instance of SQL Server 2000.

  9. Run the SQL Server 2000 Upgrade Wizard to migrate your data into SQL Server 2000.

    You must install the binaries to a local drive and use a cluster disk for the data. This local drive is a path, which is a non-clustered disk valid on all nodes of the cluster. On all nodes of the cluster, this drive must have at least 300 megabytes (MB) of available space.

  10. On Node 2, uninstall the instance of SQL Server 6.5.

  11. On Node 2, upgrade the default instance of SQL Server to a clustered instance.

    For more information, see How to upgrade from a default instance to a default clustered instance of SQL Server 2000 (SQL Server Setup).


How to upgrade from a SQL Server 7.0 active/active failover cluster (Setup)

Note To upgrade from a Microsoft® SQL Server™ version 7.0 active/active failover cluster (or any configuration where SQL Server exists on the second node), you must first convert one side of the failover cluster to a named instance of SQL Server 2000.

To upgrade from a SQL Server 7.0 active/active failover cluster

  1. On Node 1, uncluster SQL Server version 7.0. Reboot Node 1.

  2. On Node 2, uncluster SQL Server 7.0. Reboot Node 2.

  3. On Node 1, install a clustered, named instance of SQL Server 2000 as a virtual server. This is not an upgrade process, but a side-by-side installation of SQL Server 7.0 and SQL Server 2000. Do not install the data to the same location/disk as Node 2. If you do, when you attempt to upgrade Node 2 from a SQL Server 7.0 to a SQL Server 2000 installation, Setup will fail.

  4. On Node 1, run the Copy Database Wizard (CDW.exe) to move all databases and related information from the SQL Server 7.0 installation into the clustered, named instance of SQL Server 2000. For more information about the Copy Database Wizard, see Using the Copy Database Wizard or How to upgrade databases online using the Copy Database Wizard (Enterprise Manager).

  5. On Node 1, uninstall SQL Server 7.0.

  6. On Node 2, upgrade SQL Server 7.0 to SQL Server 2000 as the default instance.

    You must install the binaries to a local drive and use a cluster disk for the data. This local drive is a path, which is a non-clustered disk valid on all nodes of the cluster. This drive on all nodes of the cluster must have at least 300 megabytes (MB) of available space.

  7. On Node 2, upgrade the default instance of SQL Server 2000 to a clustered instance.

    For more information, see How to upgrade from a default instance to a default clustered instance of SQL Server 2000 (SQL Server Setup).

Note Optionally, you could create two named instances of SQL Server 2000 and use the Copy Database Wizard to upgrade both SQL Server 7.0 installations to a clustered, named instance of SQL Server 2000. This will provide better consistency, because all references to clustered installations of SQL Server 2000 will be in the form VirtualServer\Instance, rather than sometimes being just the servername, and sometimes both the servername and instancename.


How to upgrade from a SQL Server 7.0 active/passive failover cluster (Setup)

To upgrade from a SQL Server 7.0 active/passive failover cluster

  1. On Node 1, uncluster Microsoft® SQL Server™ version 7.0. Reboot Node 1.

  2. On Node 1, upgrade SQL Server 7.0 to SQL Server 2000 as the default instance.

    You must install the binaries to a local drive and use a cluster disk for the data. This local drive is a path, which is a non-clustered disk valid on all nodes of the cluster. This drive on all nodes of the cluster must have at least 300 megabytes (MB) of available space.

  3. On Node 1, upgrade the default instance of SQL Server 2000 to a clustered instance of SQL Server 2000.

    For more information, see How to upgrade from a default instance to a default clustered instance of SQL Server 2000 (SQL Server Setup).


How to upgrade from a default instance to a default clustered instance of SQL Server 2000 (Setup)

Note This upgrade is from a default instance (a local installation where the data is on a local disk) to a clustered instance of Microsoft® SQL Server™ 2000. Use this upgrade step if you want to have a cluster disk.

To upgrade from a default instance to a default clustered instance of SQL Server 2000

  1. On the Welcome screen of the SQL Server Installation Wizard, click Next.

  2. On the Computer Name screen, click Local Computer. The computer you want to change from a default to a clustered instance should be displayed. You must be on the local computer to upgrade from a default to a clustered instance. Click Next.

  3. On the Installation Selection screen, click Upgrade, remove, or add components to an existing instance of SQL Server. Click Next.

  4. On the Existing Installation screen, click Upgrade your existing installation to a clustered installation. Click Next.

  5. On the Virtual Server Name screen, enter a name for your virtual server. Click Next.

  6. On the Failover Clustering screen, enter one IP address for each network configured for client access. That is, enter one IP address for each network on which the virtual server will be available to clients on a public (or mixed) network. Select the network for which you want to enter an IP address, and then enter the IP address. Click Add.

    The IP address and the subnet are displayed. The subnet is supplied by Microsoft Cluster Service (MSCS). Continue to enter IP addresses for each installed network until you have populated all desired networks with an IP address. Click Next.

  7. On the Cluster Management screen, review the failover cluster definition provided by SQL Server 2000. By default, all available nodes are selected. Remove any nodes that will not be part of the failover cluster definition for the virtual server you are creating. Click Next.

  8. On the Remote Information screen, enter login credentials for the remote cluster node. The login credentials must have administrator privileges on the remote node(s) of the cluster. Click Next.

  9. On the Services Accounts screen, select the service account(s) for the SQL Server services under which you want the failover cluster to run. Click Next.

  10. On the Setup Complete screen, click Finish. If you need to restart the remote nodes in the failover cluster, you will be instructed to do so in the Setup Complete screen.


How to upgrade from a local default instance to a clustered, named instance of SQL Server 2000 (Setup)

To upgrade from a local default instance to a named clustered instance of SQL Server 2000

  1. Install a clustered, named instance of Microsoft® SQL Server™ 2000.

  2. Run the Copy Database Wizard (CDW.exe) to move all databases and related information into the clustered, named instance of SQL Server 2000. For more information about the Copy Database Wizard, see Using the Copy Database Wizard or How to upgrade databases online using the Copy Database Wizard (Enterprise Manager).

  3. Optionally, you can uninstall the default instance of SQL Server 2000.


Collation Options for International Support

In Microsoft® SQL Server™ 2000, it is not required to separately specify code page and sort order for character data, and the collation used for Unicode data. Instead, specify the collation name and sorting rules to use. The term, collation, refers to a set of rules that determine how data is sorted and compared. Character data is sorted using rules that define the correct character sequence, with options for specifying case-sensitivity, accent marks, kana character types, and character width. Microsoft SQL Server 2000 collations include these groupings:

  • Windows collations

    Windows collations define rules for storing character data based on the rules defined for an associated Windows locale. The base Windows collation rules specify which alphabet or language is used when dictionary sorting is applied, as well as the code page used to store non-Unicode character data. For more information, see Collations.

  • SQL collations

    SQL collations are provided for compatibility with sort orders in earlier versions of Microsoft SQL Server. For more information, see Using SQL Collations.

Changing Collations After Setup

When you set up SQL Server 2000, it is important to use the correct collation settings. You can change collation settings after running Setup, but you must rebuild the databases and reload the data. It is recommended that you develop a standard within your organization for these options. Many server-to-server activities can fail if the collation settings are not consistent across servers.

See Also

Collation Settings in Setup

How to rebuild the master database (Rebuild Master utility)

Selecting a SQL Collation

Windows Collation Designators


Collation Settings in Setup

Use the Collation Settings screen to modify default collation settings. Use the Windows Locale option to match collation settings in instances of Microsoft® SQL Server™ 2000. Use SQL Collations to match settings that are compatible with the sort orders in earlier versions of SQL Server.

Windows Locale

Change the default settings for Windows Locale (Windows collation) only if your installation of SQL Server must match the collation settings used by another instance of SQL Server 2000, or must match the Windows locale of another computer.

Collation Designator

Select the name of a specific Windows collation from the list, for example:

  • Use Latin1_General for the U.S. English character set (code page 1252).

  • Use Modern_Spanish for all variations of Spanish, which also use the same character set as U.S. English (code page 1252).

  • Use Arabic for all variations of Arabic, which use the Arabic character set (code page 1256).

  • Use Japanese_Unicode for the Unicode version of Japanese (code page 932), which has a different sort order from Japanese, but the same code page (932).

For more information, see Windows Collation Designators.

Sort Order

Select Sort Order options to use with the Collation Designator selected. Binary is the fastest sorting order, and is case-sensitive. If Binary is selected, the Case-sensitive, Accent-sensitive, Kana-sensitive, and Width-sensitive options are not available. For more information, see Windows Collation Sorting Styles.

SQL Collations

The SQL Collations option is used for compatibility with earlier versions of Microsoft SQL Server. Select this option to match settings compatible with SQL Server version 7.0, SQL Server version 6.5, or earlier. For more information, see SQL Collations.


Windows Collation Sorting Styles

On the Collation Settings screen you can choose Binary sort order, or you can define the sorting styles to use with the Collation Designator (Windows collation name) selected.

Note For Windows collations, the nchar, nvarchar, and ntext data types have the same sorting behavior as char, varchar, and text data types. For more information, see SQL Server Collation Fundamentals.

Sort order | Description
Binary | Sorts and compares data in Microsoft® SQL Server™ tables based on the bit patterns defined for each character. Binary sort order is case-sensitive, that is lowercase precedes uppercase, and accent-sensitive. This is the fastest sorting order. If this option is not selected, SQL Server follows sorting and comparison rules as defined in dictionaries for the associated language or alphabet.
Case-sensitive | Specifies that SQL Server distinguish between uppercase and lowercase letters. If not selected, SQL Server considers the uppercase and lowercase versions of letters to be equal. SQL Server does not define whether lowercase letters sort lower or higher in relation to uppercase letters when Case-sensitive is not selected.
Accent-sensitive | Specifies that SQL Server distinguish between accented and unaccented characters. For example, 'a' is not equal to 'á'. If not selected, SQL Server considers the accented and unaccented versions of letters to be equal.
Kana-sensitive | Specifies that SQL Server distinguish between the two types of Japanese kana characters: Hiragana and Katakana. If not selected, SQL Server considers Hiragana and Katakana characters to be equal.
Width-sensitive | Specifies that SQL Server distinguish between a single-byte character (half-width) and the same character when represented as a double-byte character (full-width). If not selected, SQL Server considers the single-byte and double-byte representation of the same character to be equal.

See Also

Collation Settings in Setup

Windows Collation Designators


Windows Collation Designators

Use this table to synchronize collation settings with another Windows locale.

In Control Panel, find the Windows locale name in the Regional Settings application (Microsoft® Windows NT® 4.0, Microsoft Windows® 98, and Microsoft Windows 95) or the Regional Options application (Microsoft Windows 2000), and then use this table to find the corresponding Collation Designator and code page.

Windows locale | LCID (locale ID) | Collation designator | Code page
Afrikaans | 0xx436 | Latin1_General | 1252
Albanian | 0x41C | Albanian | 1250
Arabic (Saudi Arabia) | 0x401 | Arabic | 1256
Arabic (Iraq) | 0x801 | Arabic | 1256
Arabic (Egypt) | 0xC01 | Arabic | 1256
Arabic (Libya) | 0x1001 | Arabic | 1256
Arabic (Algeria) | 0x1401 | Arabic | 1256
Arabic (Morocco) | 0x1801 | Arabic | 1256
Arabic (Tunisia) | 0x1C01 | Arabic | 1256
Arabic (Oman) | 0x2001 | Arabic | 1256
Arabic (Yemen) | 0x2401 | Arabic | 1256
Arabic (Syria) | 0x2801 | Arabic | 1256
Arabic (Jordan) | 0x2C01 | Arabic | 1256
Arabic (Lebanon) | 0x3001 | Arabic | 1256
Arabic (Kuwait) | 0x3401 | Arabic | 1256
Arabic (United Arab Emirates) | 0x3801 | Arabic | 1256
Arabic (Bahrain) | 0x3C01 | Arabic | 1256
Arabic (Qatar) | 0x4001 | Arabic | 1256
Basque | 0x42D | Latin1_General | 1252
Byelorussian | 0x423 | Cyrillic_General | 1251
Bulgarian | 0x402 | Cyrillic_General | 1251
Catalan | 0x403 | Latin1_General | 1252
Chinese (Taiwan) | 0x30404 | Chinese_Taiwan_Bopomofo | 950
Chinese (Taiwan) | 0x404 | Chinese_Taiwan_Stroke | 950
Chinese (People's Republic of China) | 0x804 | Chinese_PRC | 936
Chinese (People's Republic of China) | 0x20804 | Chinese_PRC_Stroke | 936
Chinese (Singapore) | 0x1004 | Chinese_PRC | 936
Croatia | 0x41a | Croatian | 1250
Czech | 0x405 | Czech | 1250
Danish | 0x406 | Danish_Norwegian | 1252
Dutch (Standard) | 0x413 | Latin1_General | 1252
Dutch (Belgium) | 0x813 | Latin1_General | 1252
English (United States) | 0x409 | Latin1_General | 1252
English (Britain) | 0x809 | Latin1_General | 1252
English (Canada) | 0x1009 | Latin1_General | 1252
English (New Zealand) | 0x1409 | Latin1_General | 1252
English (Australia) | 0xC09 | Latin1_General | 1252
English (Ireland) | 0x1809 | Latin1_General | 1252
English (South Africa) | 0x1C09 | Latin1_General | 1252
English (Carribean) | 0x2409 | Latin1_General | 1252
English (Jamaican) | 0x2009 | Latin1_General | 1252
Estonian | 0x425 | Estonian | 1257
Faeroese | 0x0438 | Latin1_General | 1252
Farsi | 0x429 | Arabic | 1256
Finnish | 0x40B | Finnish_Swedish | 1252
French (Standard) | 0x40C | French | 1252
French (Belgium) | 0x80C | French | 1252
French (Switzerland) | 0x100C | French | 1252
French (Canada) | 0xC0C | French | 1252
French (Luxembourg) | 0x140C | French | 1252
Georgian (Modern Sort) | 0x10437 | Georgian_Modern_Sort | 1252
German (PhoneBook Sort) | 0x10407 | German_PhoneBook | 1252
German (Standard) | 0x407 | Latin1_General | 1252
German (Switzerland) | 0x807 | Latin1_General | 1252
German (Austria) | 0xC07 | Latin1_General | 1252
German (Luxembourg) | 0x1007 | Latin1_General | 1252
German (Liechtenstein) | 0x1407 | Latin1_General | 1252
Greek | 0x408 | Greek | 1253
Hebrew | 0x40D | Hebrew | 1255
Hindi | 0x439 | Hindi | Unicode only
Hungarian | 0x40E | Hungarian | 1250
Hungarian | 0x104E | Hungarian_Technical | 1250
Icelandic | 0x40F | Icelandic | 1252
Indonesian | 0x421 | Latin1_General | 1252
Italian | 0x410 | Latin1_General | 1252
Italian (Switzerland) | 0x810 | Latin1_General | 1252
Japanese | 0x411 | Japanese | 932
Japanese (Unicode) | 0x10411 | Japanese_Unicode | 932
Korean (Extended Wansung) | 0x412 | Korean_Wansung | 949
Korean | 0x412 | Korean_Wansung_Unicode | 949
Latvian | 0x426 | Latvian | 1257
Lithuanian | 0x427 | Lithuanian | 1257
Lithuanian | 0x827 | Lithuanian_Classic | 1257
Macedonian (Former Yugoslav Republic of Macedonia) | 0x41C | Cyrillic_General | 1251
Norwegian (Bokmål) | 0x414 | Danish_Norwegian | 1252
Norwegian (Nynorsk) | 0x814 | Danish_Norwegian | 1252
Polish | 0x415 | Polish | 1250
Portuguese (Portugal) | 0x816 | Latin1_General | 1252
Portuguese (Brazil) | 0x416 | Latin1_General | 1252
Romanian | 0x418 | Romanian | 1250
Russian | 0x419 | Cyrillic_General | 1251
Serbian (Latin) | 0x81A | Cyrillic_General | 1251
Serbian (Cyrillic) | 0xC1A | Cyrillic_General | 1251
Slovak | 0x41B | Slovak | 1250
Slovenian | 0x424 | Slovenian | 1250
Spanish (Mexico) | 0x80A | Traditional_Spanish | 1252
Spanish (Traditional Sort) | 0x40A | Traditional_Spanish | 1252
Spanish (Modern Sort) | 0xC0A | Modern_Spanish | 1252
Spanish (Guatemala) | 0x100A | Modern_Spanish | 1252
Spanish (Costa Rica) | 0x140A | Modern_Spanish | 1252
Spanish (Panama) | 0x180A | Modern_Spanish | 1252
Spanish (Dominican Republic) | 0x1C0A | Modern_Spanish | 1252
Spanish (Venezuela) | 0x200A | Modern_Spanish | 1252
Spanish (Colombia) | 0x240A | Modern_Spanish | 1252
Spanish (Peru) | 0x280A | Modern_Spanish | 1252
Spanish (Argentina) | 0x2C0A | Modern_Spanish | 1252
Spanish (Ecuador) | 0x300A | Modern_Spanish | 1252
Spanish (Chile) | 0x340A | Modern_Spanish | 1252
Spanish (Uruguay) | 0x380A | Modern_Spanish | 1252
Spanish (Paraguay) | 0x3C0A | Modern_Spanish | 1252
Spanish (Bolivia) | 0x400A | Modern_Spanish | 1252
Swedish | 0x41D | Finnish_Swedish | 1252
Thai | 0x41E | Thai | 874
Turkish | 0x41F | Turkish | 1254
Ukrainian | 0x422 | Ukrainian | 1251
Urdu | 0x420 | Arabic | 1256
Vietnamese | 0x42A | Vietnamese | 1258

See Also

Collation Settings in Setup

Collations

Windows Collation Sorting Styles

Windows Collation Name


Using SQL Collations

SQL collation settings correspond to the type of installation. In general, choose a SQL collation that supports the Windows locale most commonly used at your site. For more information about identifying your site Windows Locale, see Regional Settings in Windows Control Panel. In many cases, a computer will run the Windows locale that matches the language requirements of the user, so Setup automatically detects the Windows locale and chooses the appropriate SQL collation.

SQL collations control:

  • The code page used for storing non-Unicode data in Microsoft® SQL Server™.

  • The rules governing how SQL Server sorts and compares characters stored in both Unicode and non-Unicode data types.

Choose a SQL collation if:

  • You use the replication feature with existing instances of SQL Server version 6.5 or SQL Server version 7.0

  • Your application code depends on the behaviors of the previous SQL Server collations.

An upgrade of SQL Server 7.0 to SQL Server 2000 keeps the previous SQL collation settings; no collation choice is required.

Use this table to determine if you need to make a collation choice, and if so, which collation you should choose.

Installation you want | Collation to choose
To install on a new system with no compatibility requirements for synchronizing with any type of existing system Use the locale identified by Setup, and then choose the desired binary, case, or other options.

For this release of SQL Server, when Setup detects that the computer is running the U.S. English locale, Setup automatically selects the SQL collation: Dictionary order, case-insensitive, for use with 1252 character set.

To select the equivalent Windows collation, select Collation designator, choose the Latin1_General collation designator, do not select case-sensitive, and select accent-sensitive.
To upgrade an installation of SQL Server 6.5 or SQL Server 7.0 to a default instance of SQL Server 2000, or to install a default instance of SQL Server 2000 that will version switch with an installation of SQL Server 6.5 | Use the SQL collation chosen by Setup.
To synchronize (for example, to replicate) with an existing instance of SQL Server 2000 | Select SERVERPROPERTY(N'Collation') on the existing instance, and specify that collation. If the collation name of the existing instance starts with SQL, select the same SQL collation in Setup. If the collation name of the existing instance does not start with SQL, the collation name refers to a Windows collation name and consists of the collation designator name followed by a description of what binary, case, accent, kana and width sensitivity options are specified. Select the same Windows collation designator and sorting options in Setup.
To synchronize with an existing installation of SQL Server 6.5 or SQL Server 7.0 Execute sp_helpsort on the existing system, and then use the sort ID to select a SQL collation to make your instance of SQL Server 2000 compatible with an existing installation.

For more information, see Selecting a SQL Collation.
To synchronize with a Windows locale of another computer | In Control Panel, find the locale name from the Regional Settings application (Microsoft Windows NT® 4.0, Microsoft Windows® 98, and Microsoft Windows 95), or from the Regional Options application (Microsoft Windows 2000), and then use the table provided in the topic Windows Collation Designators. Set the sorting options, as explained in the topic Windows Collation Sorting Styles.

Note When you perform an action that depends on collations, the SQL Server collation used by the referenced object must use a code page supported by the operating system running on the computer. For more information, see Specifying Collations.

See Also

Examples of SQL Collations

Selecting Collations

sp_helpsort

Setting Client Code Pages

SQL Server Collation Fundamentals

SERVERPROPERTY


Examples of SQL Collations

These are examples of SQL collations listed on the Collation Settings screen in Microsoft® SQL Server™ 2000 Setup:

Binary order, for use with the 437 (U.S. English) character set.

This collation uses binary sort order (simple sorting based on coded value) with the U.S. English character set (code page 437 - MS-DOS Latin US).

In Transact-SQL, the string SQL_Latin1_General_Cp437_BIN is used to designate this setting.

Dictionary order, case-insensitive, accent-insensitive, for use with 1252 character set.

This collation uses the dictionary sorting rules for the U.S. English character set (code page 1252 - Windows Latin 1 ANSI, sort order ID 54). Uppercase or lowercase characters and accent marks are not considered when sorting.

In Transact-SQL, the string SQL_Latin1_General_CP1_CI_AI is used to designate this setting.

Romanian dictionary order, case-sensitive, for use with the 1250 (Central European) character set.

This collation uses the dictionary order sorting rules for the Romanian language, and uses the Central European character set (code page 1250, sort order ID 89).

In Transact-SQL, the string SQL_Romanian_Cp1250_CS_AS is used to designate this setting.

See Also

Collation Settings in Setup

Selecting a SQL Collation

Using SQL Collations

SQL Collation Name


Selecting a SQL Collation

New Information - SQL Server 2000 SP3.

When selecting a SQL collation in the Collations Settings screen, use the following table to make the installation of Microsoft® SQL Server™ 2000 compatible with an installation of an earlier version of SQL Server.

Note Each SQL Collation name has an equivalent string in T-SQL code. For a list of sort order identifiers and the T-SQL version, see SQL Collation Name.

In the table, the left column lists the sort order ID of an instance of SQL Server 7.0 or SQL Server 6.5. The right column lists the SQL Server 2000 collation recommended for compatibility.

Sort order ID | SQL collation name
30 | Binary order, for use with the 437 (U.S. English) character set.
31 | Dictionary order, case-sensitive, for use with the 437 (U.S. English) character set.
32 | Dictionary order, case-insensitive, for use with the 437 (U.S. English) character set.
33 | Dictionary order, case-insensitive, uppercase preference, for use with the 437 (U.S. English) character set.
34 | Dictionary order, case-insensitive, accent-insensitive, for use with the 437 (U.S. English) character set.
40 | Binary order, for use with the 850 (Multilingual) character set.
41 | Dictionary order, case-sensitive, for use with the 850 (Multilingual) character set.
42 | Dictionary order, case-insensitive, for use with the 850 (Multilingual) character set.
43 | Dictionary order, case-insensitive, uppercase preference, for use with the 850 (Multilingual) character set.
44 | Dictionary order, case-insensitive, accent-insensitive, for use with the 850 (Multilingual) character set.
49 | Strict compatibility with version 1.x case-insensitive databases, for use with the 850 (Multilingual) character set.
50 | Binary order for use with 1252 character set.
51 | Dictionary order, case-sensitive, for use with 1252 character set.
52 | Dictionary order, case-insensitive, for use with 1252 character set.
53 | Dictionary order, case-insensitive, uppercase preference, for use with 1252 character set.
54 | Dictionary order, case-insensitive, accent-insensitive, for use with 1252 character set.
55 | Alternate dictionary order, case-sensitive, for use with the 850 (Multilingual) character set.
56 | Alternate dictionary order, case-insensitive, uppercase preference, for use with the 850 (Multilingual) character set.
57 | Alternate dictionary order, case-insensitive, accent-insensitive, for use with the 850 (Multilingual) character set.
58 | Scandinavian dictionary order, case-insensitive, uppercase preference, for use with the 850 (Multilingual) character set.
59 | Scandinavian dictionary order, case-sensitive, for use with the 850 (Multilingual) character set.
60 | Scandinavian dictionary order, case-insensitive, for use with the 850 (Multilingual) character set.
61 | Alternate dictionary order, case-insensitive, for use with the 850 (Multilingual) character set.
71 | Latin-1 case-sensitive, for use with 1252 character set.
72 | Latin-1 case-insensitive, for use with 1252 character set.
73 | Danish/Norwegian case-sensitive sort order for code page 1252.
74 | Finnish/Swedish case-sensitive sort order for code page 1252.
75 | Icelandic case-sensitive sort order for code page 1252.
80 | Binary order, for use with the 1250 (Central European) character set.
81 | Dictionary order, case-sensitive, for use with the 1250 (Central European) character set.
82 | Dictionary order, case-insensitive, for use with the 1250 (Central European) character set.
83 | Czech dictionary order, case-sensitive, for use with the 1250 (Central European) character set.
84 | Czech dictionary order, case-insensitive, for use with the 1250 (Central European) character set.
85 | Hungarian dictionary order, case-sensitive, for use with the 1250 (Central European) character set.
86 | Hungarian dictionary order, case-insensitive, for use with the 1250 (Central European) character set.
87 | Polish dictionary order, case-sensitive, for use with the 1250 (Central European) character set.
88 | Polish dictionary order, case-insensitive, for use with the 1250 (Central European) character set.
89 | Romanian dictionary order, case-sensitive, for use with the 1250 (Central European) character set.
90 | Romanian dictionary order, case-insensitive, for use with the 1250 (Central European) character set.
91 | Croatian dictionary order, case-sensitive, for use with the 1250 (Central European) character set.
92 | Croatian dictionary order, case-insensitive, for use with the 1250 (Central European) character set.
93 | Slovak dictionary order, case-sensitive, for use with the 1250 (Central European) character set.
94 | Slovak dictionary order, case-insensitive, for use with the 1250 (Central European) character set.
95 | Slovenian dictionary order, case-sensitive, for use with the 1250 (Central European) character set.
96 | Slovenian dictionary order, case-insensitive, for use with the 1250 (Central European) character set.
97 | Windows Polish case-sensitive sort order for code page 1250.
98 | Windows Polish case-insensitive sort order for code page 1250.
104 | Binary order, for use with the 1251 (Cyrillic) character set.
105 | Dictionary order, case-sensitive, for use with the 1251 (Cyrillic) character set.
106 | Dictionary order, case-insensitive, for use with the 1251 (Cyrillic) character set.
107 | Ukrainian dictionary order, case-sensitive, for use with the 1251 (Cyrillic) character set.
108 | Ukrainian dictionary order, case-insensitive, for use with the 1251 (Cyrillic) character set.
112 | Binary order, for use with the 1253 (Greek) character set.
113 | Dictionary order, case-sensitive, for use with the 1253 (Greek) character set.
114 | Dictionary order, case-insensitive, for use with the 1253 (Greek) character set.
120 | Mixed dictionary order, for use with the 1253 (Greek) character set.
121 | Dictionary order, case-sensitive, accent-sensitive, for use with the 1253 (Greek) character set.
124 | Dictionary order, case-insensitive, accent-insensitive, for use with the 1253 (Greek) character set.
128 | Binary order, for use with the 1254 (Turkish) character set.
129 | Dictionary order, case-sensitive, for use with the 1254 (Turkish) character set.
130 | Dictionary order, case-insensitive, for use with the 1254 (Turkish) character set.
136 | Binary order, for use with the 1255 (Hebrew) character set.
137 | Dictionary order, case-sensitive, for use with the 1255 (Hebrew) character set.
138 | Dictionary order, case-insensitive, for use with the 1255 (Hebrew) character set.
144 | Binary order, for use with the 1256 (Arabic) character set.
145 | Dictionary order, case-sensitive, for use with the 1256 (Arabic) character set.
146 | Dictionary order, case-insensitive, for use with the 1256 (Arabic) character set.
152 | Binary order, for use with the 1257 (Baltic) character set.
153 | Dictionary order, case-sensitive, for use with the 1257 (Baltic) character set.
154 | Dictionary order, case-insensitive, for use with the 1257 (Baltic) character set.
155 | Estonian dictionary order, case-sensitive, for use with the 1257 (Baltic) character set.
156 | Estonian dictionary order, case-insensitive, for use with the 1257 (Baltic) character set.
157 | Latvian dictionary order, case-sensitive, for use with the 1257 (Baltic) character set.
158 | Latvian dictionary order, case-insensitive, for use with the 1257 (Baltic) character set.
159 | Lithuanian dictionary order, case-sensitive, for use with the 1257 (Baltic) character set.
160 | Lithuanian dictionary order, case-insensitive, for use with the 1257 (Baltic) character set.
183 | Danish/Norwegian dictionary order, case-insensitive, uppercase preference, for use with 1252 character set.
184 | Finnish-Swedish (Phone), case-insensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 184 on Code Page 1252 for non-Unicode Data.
185 | Finnish-Swedish (Standard), case-insensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 185 on Code Page 1252 for non-Unicode Data.
186 | Icelandic dictionary order, case-insensitive, uppercase preference, for use with 1252 character set.
192 | Binary order, for use with the 932 (Japanese) character set.
193 | Dictionary order, case-insensitive, for use with the 932 (Japanese) character set
194 | Binary order, for use with the 949 (Korean) character set.
195 | Dictionary order, case-insensitive, for use with the 949 (Korean) character set.
196 | Binary order, for use with the 950 (Traditional Chinese) character set.
197 | Dictionary order, case-insensitive, for use with the 950 (Traditional Chinese) character set.
198 | Binary order, for use with the 936 (Simplified Chinese) character set.
199 | Dictionary order, case-insensitive, for use with the 936 (Simplified Chinese) character set.
200 | Dictionary order, case-sensitive, for use with the 932 (Japanese) character set.
201 | Dictionary order, case-sensitive, for use with the 949 (Korean) character set.
202 | Dictionary order, case-sensitive, for use with the 950 (Traditional Chinese) character set.
203 | Dictionary order, case-sensitive, for use with the 936 (Simplified Chinese) character set.
204 | Binary order, for use with the 874 (Thai) character set.
205 | Dictionary order, case-insensitive, for use with the 874 (Thai) character set.
206 | Dictionary order, case-sensitive, for use with the 874 (Thai) character set.

See Also

Examples of SQL Collations

Collation Settings in Setup

Specifying Collations

SQL Collations


Setting Client Code Pages

The code pages a client uses are determined by your operating system settings.

To set client code pages in the Windows NT, Windows 2000, or Windows 98 operating systems

Windows


Upgrading Character Set, Sort Order, and Collation

Microsoft® SQL Server™ 2000 supports several different ways to specify collations. You no longer have to separately specify the code page used for character data, the sort order used for character data, and the collation used for Unicode data. When you upgrade, SQL collations can be specified for compatibility with existing instances of SQL Server.

Because the default collation for an instance of Microsoft SQL Server is defined during setup, it is important to become familiar with collation settings in SQL Server 2000 when:

  • Your application code depends in some way on the behavior of previous SQL Server collations.

  • You are going to use the replication feature with existing installations of SQL Server 6.5 or SQL Server 7.0.

  • You must store character data that reflects multiple languages.

See Also

Collation Options for International Support

Collations

Selecting Collations

Specifying the Default Collation for an Instance of SQL Server


Changing Collation Settings After Installing

Collation settings, which include character set, sort order, and other locale-specific settings, are fundamental to the structure of all Microsoft® SQL Server™ 2000 databases. To change one or more of these settings, you must rebuild the master and user databases.

See Also

Collation Settings in Setup

Collations

How to rebuild the master database (Rebuild Master utility)


After Installing or Upgrading to SQL Server 2000

For a standard installation, components include:

  • The SQL Server relational database engine.

  • System databases used to store system level information such as login and configuration settings and for use as database templates.

  • The pubs and Northwind sample databases, provided as learning tools.

  • Stored procedures, a recompiled collection of Transact-SQL statements.

  • Interactive management tools used for administering SQL Server.

  • SQL Server Books Online, the complete documentation for SQL Server 2000.

See Also

Books Online

Management Tools

Select Components

SQL Stored Procedures

Using the Start Menu

System and Sample Databases

System Databases and Data


Using the Start Menu

Microsoft® SQL Server™ 2000 Setup creates the Microsoft SQL Server program group on the Start menu in the Programs group. From the Microsoft SQL Server program group, you can start:

  • Books Online.

  • Client Network Utility.

  • Configure SQL XML Support in IIS.

  • Enterprise Manager.

  • Import and Export Data.

  • Profiler.

  • Query Analyzer.

  • Server Network Utility.

  • Service Manager.
Microsoft SQL Server-Switch Program Group

If you install an instance of Microsoft SQL Server 2000 (default or named) on the same computer with an installation of Microsoft SQL Server version 6.5, Setup removes the Microsoft SQL Server 6.5 program group and adds the Microsoft SQL Server-Switch program group. SQL Server 6.5 and SQL Server 2000 cannot run at the same time, but using the Server-Switch program group, you can switch between the two versions.

On the Start menu, only the program group of the active version of SQL Server is accessible at any given time. The nonactive version is shown in the Server-Switch program group so you can quickly switch from one version to another.

The Microsoft SQL Server-Switch program group contains these options:

  • Microsoft SQL Server 6.5 or Microsoft SQL Server 2000 (the nonactive version)

  • SQL Server Upgrade Wizard

  • Uninstall SQL Server 6.5

See Also

Switching Between SQL Server 6.5 and SQL Server 2000


System and Sample Databases

When Microsoft® SQL Server™ 2000 is installed, Setup creates the database and log files shown in this table.

Database | Database file | Log file
master | Master.mdf | Mastlog.ldf
model | Model.mdf | Modellog.ldf
msdb | Msdbdata.mdf | Msdblog.ldf
tempdb | Tempdb.mdf | Templog.ldf
pubs | Pubs.mdf | Pubs_log.ldf
Northwind | Northwnd.mdf | Northwnd.ldf

The system databases are master, model, msdb, and tempdb. The sample databases, pubs and Northwind, are provided as learning tools. (Names of these databases are case-sensitive.) Many of the examples in SQL Server Books Online are based on the sample databases.

Note The default location of the database and log files is Program Files\Microsoft SQL Server\Mssql\Data. This location may vary if the default location was changed when SQL Server was installed.

See Also

Northwind Sample Database

pubs Sample Database

System Databases and Data


Locating Directories and Files

The following tables and illustration show the default locations of directories and files for Microsoft® SQL Server™ 2000 (primarily for the default instance). Depending on the options you install, all of the files listed in the tables may not appear on your computer, and others not listed may be included.

Paths listed here are default paths, and may vary if locations were changed during installation. Both program and data file locations can be changed, but the location of shared tools cannot be changed.

Important Do not delete any of the following directories or their contents: Binn, Data, Ftdata, HTML, or 1033. You may delete other directories, if necessary; however, you may not be able to retrieve any lost functionality or data without uninstalling and reinstalling SQL Server 2000.

Do not delete or modify any of the .htm files in the HTML directory. They are required for SQL Server Enterprise Manager and other tools to function properly.

Shared Files for All Instances of SQL Server 2000

This table shows the locations for the shared files for both default and named instances of SQL Server 2000.

Location | Description
\Program Files\Microsoft SQL Server\80\Com | Dynamic-link libraries (DLLs) for Component Object Model (COM) objects.
\Program Files\Microsoft SQL Server\80\Com\Binn\Resources\1033 | Resource files (RLLs) used by the DLLs in this COM directory. (Note: 1033 is for U.S. English; localized versions use different directory numbers.)
\Program Files\Microsoft SQL Server\80\Tools\Binn | Microsoft Windows NT® client executable files.
\Program Files\Microsoft SQL Server\80\Tools\Binn\Resources\1033 | Resource files used by the DLLs in the Tools\Binn directory.
\Program Files\Microsoft SQL Server\80\Tools\Books | SQL Server Books Online files, including online Help files.
Program Files\Microsoft SQL Server\80\Tools\DevTools\ | Header files, library files, and sample programs for use by developers.
Program Files\Microsoft SQL Server\80\Tools\Html | Microsoft Management Console (MMC) and SQL Server HTML files.
Program Files\Microsoft SQL Server\80\Tools\Templates | Boilerplate files with SQL scripts to help you create objects in the database.

Program and Data Files for the Default Instance of SQL Server 2000

This table shows the locations of the program and data files for the default instance of SQL Server 2000. These are the default file locations, which can be changed during installation.

Location | Description
\Program Files\Microsoft SQL Server\Mssql\Backup | Default location for backup files.
\Program Files\Microsoft SQL Server\Mssql\Binn | Microsoft Windows NT server executable files and DLL files for extended stored procedures.
\Program Files\Microsoft SQL Server\Mssql\Binn\Resources\1033 | Resource files used by the DLLs in this Binn directory.
Program Files\Microsoft SQL Server\Mssql\Data | System and sample database files.
Program Files\Microsoft SQL Server\Mssql\Ftdata | Full-text catalog files.
Program Files\Microsoft SQL Server\Mssql\Install | Scripts run during Setup and resulting output files.
Program Files\Microsoft SQL Server\Mssql\Jobs | Storage location for temporary job output files.
Program Files\Microsoft SQL Server\Mssql\Log | Error log files.
Program Files\Microsoft SQL Server\Mssql\Repldata | Working directory for replication tasks.
Program Files\Microsoft SQL Server\Mssql\Upgrade | Files used for version upgrade from SQL Server version 6.5 to SQL Server 2000.

File Locations for the Default Instance of SQL Server 2000

This illustration shows the file locations for the default instance of Microsoft® SQL Server™ 2000.

See Also

File Paths for SQL Server 2000


Changing Passwords and User Accounts

Microsoft® SQL Server™ 2000 services accounts and passwords are linked to Microsoft Windows® user accounts and passwords. Changes in one location may require changes in the other.

Changing SQL Server Services Accounts After Install

After you have installed SQL Server 2000, use SQL Server Enterprise Manager to change the assigned password or other properties of any SQL Server–related service. Each service must be changed individually. In addition, the Microsoft Search service (full-text search) must always run under the local system account.

The new user account takes effect when the service is restarted. You should not change the passwords for any of the SQL Server service accounts when a failover cluster node is down or offline. If you have to do this, you will need to reset the password again using Enterprise Manager when all nodes are back online.

If you are running Microsoft Windows NT®, and you select to change the current service account for SQL Server to a non-administrator account (and the current service account for SQL Server is not an administrator account), the Valid Administrator Login dialog box is displayed. SQL Server must have administrator privileges to change security entries, so you must enter the user name, password, and domain to impersonate the non-administrator service account you have selected.

Once you have specified this information, all objects are granted full control permission. The location of the objects is determined by the following:

  • Permissions are set for all files in the binary and data installation locations for the specific instances.

  • Registry permissions depend on whether the instance is default or named:

    For a default instance, permissions are applied only to the entries listed below the HKLM\Software\Microsoft\MSSQLServer entry:

    • SQLServerAgent

    • Replication

    • Providers

    • Setup

    • Tracking

    • MSSQLServer

    For a named instance, permissions are applied to the entire HKLM\Software\Microsoft\MicrosoftSQLServer\80 entry.

The following rights are granted to the accounts:

  • SeServiceLogonRight, which allows the account to run as a service.

  • SeLockMemoryPrivilege, which allows the account to use the AWE memory feature of SQL Server.

  • SeTcbPrivilege, which allows the account to impersonate other accounts.

If you are running SQL Server in a failover cluster configuration, permissions are also set for all files in the binary and data installation locations for all nodes in the cluster. Permission is also granted for the service account on the Cluster Object.

Note If you are running Microsoft Windows 2000 and want to use the Windows 2000 Encrypted File System to encrypt any SQL Server files, you must unencrypt the files before you can change the SQL Server service accounts. If you do not unencrypt the files and then reset the SQL Server service accounts, you cannot unencrypt the files.

Changing the current service account for SQL Server to a non-administrator account causes existing full-text catalogs to become inaccessible. Either rebuild and perform a full population of all catalogs belonging to this instance of SQL Server, or switch back to an account with administrator permissions.

You can change the SQLServerAgent service account to a non Microsoft Windows NT® 4.0 administrator account. However, the Windows NT 4.0 account must be a member of the sysadmin fixed server role to run SQL Server Agent.

To change the MSSQLServer services login (Enterprise Manager)

Enterprise Manager

Enterprise Manager

Windows Passwords Changes

If your Windows password changes after SQL Server 2000 is installed (for example, your password expires), you must also revise the user account information for SQL Server services in Windows.

To change SQL Server services login account information (Windows NT)

Windows

Windows

To change SQL Server services login account information (Windows 2000)

Windows

Windows

After changing the SQL Server service account information in Control Panel, you must also change the SQL Server service account in SQL Server Enterprise Manager. This allows the service account information for Microsoft Search service to remain synchronized as well.

Important Although the Microsoft Search service is always assigned to the local system account, the full-text search engine tracks the SQL Server service account in Windows. Full-text search and failover clustering are not available if Windows password changes are not reset using SQL Server Enterprise Manager.

For more information about creating Windows NT user accounts, granting advanced user rights, setting password expiration, and managing group memberships, see the Windows NT documentation or User Manager for Domains Help. For Microsoft Windows 2000 users, see Computer Management or Group Policy Editor in the Windows 2000 documentation.

See Also

Creating Security Accounts

Security Architecture


Renaming a Server

When you change the name of the computer that is running Microsoft® SQL Server™ 2000, the new name is recognized during SQL Server startup. You do not have to run Setup again to reset the computer name.

You can connect to SQL Server using the new computer name after you have restarted the server. However, to correct the sysservers system table, you should manually run these procedures:

sp_dropserver old_name
GO
sp_addserver new_name, local
GO

When you have more than one instance of SQL Server on the computer, change the sysservers system table information by running the stored procedures this way:

sp_dropserver old_servername\instancename
GO
sp_addserver new_servername\instancename, local
GO
Issues with Remote Logins and Replication

If the computer has any remote logins, for example, if it is a replication Publisher or Distributor, sp_dropserver may generate an error similar to this:

Server: Msg 15190, Level 16, State 1, Procedure sp_dropserver, Line 44
There are still remote logins for the server 'SERVER1'.

To resolve the error, you may need to drop remote logins for this server. If replication is installed, disable replication on the server before running the sp_dropserver stored procedure.

To disable replication using the SQL Server Enterprise Manager

  1. Expand a server group, and then expand the Distributor (the server that contains the distribution database).

  2. Right-click the Replication folder, and then click Disable Publishing.

  3. Complete the steps in the Disable Publishing and Distribution Wizard.


Deploying SQL Server After Initial Installation

Microsoft® SQL Server™ 2000 includes a new method for distributing a disk image of an installation. When an installation is first created, it is marked as a new installation. When the server is restarted after installation, SQL Server 2000 verifies that the server name has not changed. If the server name has changed, an automatic correction is made.

This functionality allows Independent Service Vendors to install SQL Server 2000, stop the server, clone the disk image, and then distribute it as required. On the first startup of the distributed server, the name correction is made.

This process can be done only one time. If the server is restarted and then stopped, a new SQL Server installation must be created to be distributed as an image during deployment.


Installing Full-Text Search and Indexing Tools

The full-text search engine (Microsoft Search service) is installed by default with a typical installation of Microsoft® SQL Server™ 2000, Standard and Enterprise editions.

Important If upgrading from SQL Server 7.0 to SQL Server 2000 and full-text search is not installed in SQL Server 7.0, install full-text search as an additional component after the upgrade is completed.

Microsoft Indexing Service Version 2.0

In addition to using full-text search on character columns in SQL Server data, you can use Microsoft Indexing Service along with Microsoft Search service to make textual queries against data residing in the file system. This indexing service is included in Microsoft Windows® 2000. Microsoft Windows NT® users can install the indexing service from the Microsoft Windows NT 4.0 Option Pack.

To install Microsoft Indexing Service 2.0 (Windows NT only)

  1. Install Windows NT 4.0 Option Pack.

  2. Select Index Server 2.0. An error appears stating that Index Server 2.0 did not install properly.

  3. Install Windows NT 4.0 Service Pack 4.

  4. Reinstall Windows NT 4.0 Option Pack. You are not required to change any settings.

  5. Optional step: Repeat the reinstallation of Windows NT 4.0 Service Pack 4.

    Repeating this procedure ensures proper installation.

See Also

Full-text Querying of File Data

How to add components to an instance of SQL Server 2000 (Setup)


Configuring SQL Server 2000 After Upgrading

After the server is upgraded to Microsoft® SQL Server™ 2000, you may want to perform several configuration tasks, for example:

  • Set server configuration parameters.

  • Set security parameters.

  • Register the server and add it to a server group.

Use SQL Server Enterprise Manager or Transact-SQL to perform these tasks.

See Also

Administering SQL Server Overview


Switching Between SQL Server 6.5 and SQL Server 2000

Microsoft® SQL Server™ 2000 can be installed on the same computer with Microsoft SQL Server version 6.5, but only one version can be active at one time.

Note Switching between versions is not the same as running multiple instances. For more information, see Working with Instances and Versions of SQL Server.

After the SQL Server Upgrade Wizard finishes the conversion from SQL Server version 6.5, SQL Server 2000 is the active version of SQL Server. If enough disk space exists on your computer, you can keep the SQL Server 6.5 installation intact.

To switch from one version to the other, use the Microsoft SQL Server-Switch application on the Start menu, or run Vswitch.exe.

Important Be sure the SQL Server Upgrade Wizard is finished with its upgrade tasks, before you attempt to switch between the active and nonactive versions of SQL Server.

If you install a default instance of SQL Server 2000 on a computer running an instance of SQL Server 6.5, the default instance of SQL Server 2000 becomes the accessible instance of SQL Server, and the SQL Server 2000 program group appears on the Start menu. The instance of SQL Server 6.5 is switched out, and the SQL Server 6.5 program group does not appear on the Start menu.

You can run either the default instance of SQL Server 2000 or the instance of SQL Server 6.5, but not both at the same time. To switch between the two versions of SQL Server, use the Microsoft SQL Server-Verswitch entry on the Start menu. When you switch from SQL Server 2000 to SQL Server 6.5, the instance of SQL Server 2000 becomes inactive, and the SQL Server 6.5 program group replaces the SQL Server 2000 program group on the Start menu. When you switch from SQL Server 6.5 to SQL Server 2000, the process is reversed.

If you install one or more named instances of SQL Server 2000 on a computer running SQL Server 6.5 and there is no default instance of SQL Server 2000, the instance of SQL Server 6.5 remains active as the default instance. Both the SQL Server 2000 and SQL Server 6.5 program groups appear on the Start menu. You should use the SQL Server 6.5 tools to manage the default instance of SQL Server 6.5, and the SQL Server 2000 tools to manage the named instances of SQL Server 2000.

If you install both named and default instances of SQL Server 2000 on a computer running SQL Server 6.5, you can run the named instances of SQL Server 2000 at any time, but must version-switch between the default instance of SQL Server 2000 and the default instance of SQL Server 6.5. The SQL Server 2000 program group always appears on the Start menu. The SQL Server 6.5 program group appears on the Start menu whenever you have version switched to make SQL Server 6.5 the active default instance. The SQL Server 6.5 program group does not appear when you have version switched to make SQL Server 2000 the active default instance.

To switch from SQL Server 6.5 to SQL Server 2000

Command Prompt

Command Prompt

Windows

Windows

See Also

Using SQL Server 6.5 with SQL Server 2000

Removing SQL Server 7.0 or SQL Server 6.5 After Upgrading


Removing SQL Server 7.0 or SQL Server 6.5 After Upgrading

After you upgrade your Microsoft® SQL Server™ version 7.0 installation to Microsoft SQL Server 2000, or after you upgrade your databases from SQL Server version 6.5 to SQL Server 2000, you can keep the earlier versions on your computer.

A number of configurations are available for keeping earlier versions of SQL Server alongside SQL Server 2000. For more information, see Working with Instances and Versions of SQL Server.

When you are ready to remove an earlier version, you can use the Add/Remove Programs option in Control Panel, or you can run uninstall from the Start menu.

To remove SQL Server 7.0

  • On the Start menu, in the SQL Server 7.0 group, click Uninstall SQL Server 7.0.

To remove SQL Server 6.5

  • On the Start menu, in the SQL Server 6.5 group, click Remove SQL Server 6.5.


Removing SQL Server 2000

You can remove instances of Microsoft® SQL Server™ 2000 by:

  • Running SQL Server 2000 Setup and selecting the Uninstall option.

  • Running the Add/Remove Programs application in Control Panel.

Each named instance of SQL Server 2000 must be removed separately. You cannot remove individual components of SQL Server 2000. To remove components, you must remove the entire instance.

Important Before removing SQL Server 2000, quit all applications, including the Windows NT Event Viewer, the Registry editor, all SQL Server applications, and all applications dependent on SQL Server.

To remove SQL Server using Control Panel

Windows

Windows

To remove instances of SQL Server using Setup

SQL Setup

SQL Setup

See Also

Existing Installation Options


Upgrading to SQL Server 2000: Overview

Upgrading from Microsoft® SQL Server™ version 7.0 to Microsoft SQL Server 2000 is one of the basic choices offered by the SQL Server Setup program on the initial Installation Selection screen. When you select the option to Upgrade, remove, or add components to an existing installation of SQL Server, Setup detects your current installation and initiates the correct sequence of setup screens for the upgrade selected. Upgrade variations include:

  • A complete installation upgrade from SQL Server 7.0 to SQL Server 2000 (installing over SQL Server 7.0).

  • Adding components to an installation of SQL Server 2000.

  • An upgrade to the feature set of an existing installation of SQL Server 2000 (edition and component upgrade).

  • An upgrade to SQL Server 2000 from SQL Server version 6.5 using the SQL Server Upgrade Wizard.

  • An online database upgrade of SQL Server 7.0 databases to SQL Server 2000 database format using the Copy Database Wizard.

During the upgrade from SQL Server 7.0, external packages, such as Microsoft Management Console and the Microsoft Distributed Transaction Coordinator, must be installed for each upgrade, and the registry updated. The master database and other system databases are upgraded in various ways involving a series of scripts run on the server with specific options. If the upgrade process fails built-in recovery mechanisms restart and resume the upgrade.

See Also

Upgrading from SQL Server 7.0 to SQL Server 2000

Upgrading an Existing Installation of SQL Server

Upgrading Databases from SQL Server 7.0 (Copy Database Wizard)

Upgrading to a SQL Server 2000 Failover Cluster


Hardware and Software Requirements for Upgrading

In addition to the hardware and software requirements for an installation of Microsoft® SQL Server™, the computer must meet these requirements for an upgrade.

Hardware/software | Upgrade requirements
Operating system | Microsoft Windows NT® Server Enterprise Edition version 4.0 with Service Pack 5 (SP5) or later. Windows NT Server version 4.0 with SP5 or later. Windows NT Workstation 4.0 with SP5 or later. Internet Explorer 5.0 or later. Windows 2000.
SQL Server 6.5 | When upgrading SQL Server version 6.5 to an instance of SQL Server 2000 on the same computer, you must have applied SQL Server 6.5 Service Pack 5 (SP5) or later. When upgrading SQL Server 6.5 to an instance of SQL Server 2000 on a different computer, you must have applied SQL Server 6.5 Service Pack 3 (SP3) or later.
SQL Server 7.0 | SQL Server 7.0 (at any Service Pack level).
Network protocols | Named Pipes. SQL Server 6.5, SQL Server 7.0, and SQL Server 2000 all must be set to listen to the default pipe, \\.\pipe\sql\query. Named Pipes is required even for a tape backup upgrade.
Hard-disk space | No additional hard-disk space is required when upgrading from SQL Server 7.0 to SQL Server 2000. When upgrading from SQL Server 6.5 to SQL Server 2000, however, you need approximately 1.5 times the size of the SQL Server 6.5 databases.

See Also

Hardware and Software Requirements for Installing SQL Server 2000


Upgrading from SQL Server 7.0 to SQL Server 2000

You can overwrite an installation of Microsoft® SQL Server™ version 7.0 with a version upgrade to Microsoft SQL Server 2000. If SQL Server 7.0 is detected as an existing installation when you run Setup, you can choose the option to upgrade. In this process, all the SQL Server 7.0 program files are upgraded, and all data stored in SQL Server 7.0 databases is preserved. In addition, SQL Server Books Online for SQL Server 7.0 remains on your computer.

Note SQL Server 7.0 profiler traces and registered servers are not upgraded when SQL Server 7.0 tools are upgraded to SQL Server 2000. Similarly, information models that were installed with Microsoft Repository 2.0 are not upgraded automatically. SQL Server 2000 supports newer versions of information models for both Data Transformation Services (DTS) and the Open Information Model (OIM). For more information about upgrading the DTS information model, see DTS Information Model. For more information about upgrading the OIM, see Upgrading an Information Model.

You can also upgrade from one edition of SQL Server to another edition during the version upgrade to SQL Server 2000. For more information, see SQL Server 2000: Editions and Components.

Caution After you perform this version upgrade, the SQL Server 7.0 installation no longer exists on your computer. The only way to restore an installation of SQL Server 7.0 is to first uninstall SQL Server 2000, perform a complete reinstall of SQL Server 7.0 files, and then restore your backed-up SQL Server 7.0 databases.

To upgrade an installation of SQL Server 7.0 to SQL Server 2000

SQL Setup

SQL Setup

After Upgrading

After you upgrade from SQL Server 7.0 to SQL Server 2000, it is recommended that you repopulate full-text catalogs and update statistics. Both operations can be time-consuming, but will enhance the performance of SQL Server 2000.

Repopulate Full-Text Catalogs

The upgrade process marks your databases as full-text disabled, due to a format change from SQL Server 7.0 to SQL Server 2000. Catalogs must be repopulated after an upgrade, but this operation is not automatically run at setup time because it can be time-consuming. Administrators should plan to repopulate all full-text catalogs at a convenient time. For more information, see sp_fulltext_catalog and sp_fulltext_database.

Update Statistics

It is recommended that you update all SQL Server 7.0 statistics after upgrading to SQL Server 2000. Although this update may take a significant amount of time on large databases, using SQL Server 7.0 statistics with SQL Server 2000 may result in poor query performance.

Use the sp_updatestats stored procedure, to update statistics in user-defined tables in SQL Server 2000 databases. For more information, see sp_updatestats.

See Also

Full-text Indexes

How to repopulate all full-text catalogs for a database (Enterprise Manager)

Transact-SQL Overview

How to access SQL Server Books Online for SQL Server 7.0


Replication and Upgrading

When upgrading to Microsoft® SQL Server™ 2000, you can upgrade servers in your organization one at a time; however, when servers are used for replication, you must upgrade the Distributor first, the Publisher second, and then Subscribers. Upgrading servers one at a time following this sequence is recommended when a large number of Publishers and Subscribers exist because you can continue to replicate data even though servers are running different versions of SQL Server. You can create new publications and subscriptions with servers running instances of SQL Server 2000, and still maintain subscriptions created in SQL Server 6.5 or SQL Server 7.0.

When using transactional replication, you can upgrade Subscribers before the Publisher. If you are using immediate updating with snapshot replication or transactional replication, there are additional upgrade recommendations in this topic under Upgrading and Immediate Updating.

You can upgrade replication servers running SQL Server 6.5 or SQL Server 7.0 to SQL Server 2000. If the server is running SQL Server 6.5, you do not need to upgrade it to SQL Server 7.0 before upgrading to SQL Server 2000.

Important When upgrading servers configured for replication to SQL Server 2000, the database compatibility level must be set to 70 (version 7.0 compatibility) or later. If you have servers running in 65 (version 6.5) or an earlier compatibility level, temporarily change them to 70 or later during the upgrade process.

When the Publisher or Subscriber is running in 65 or an earlier compatibility level during upgrade to SQL Server 2000, error 15048 will be raised stating that the operation is supported only on SQL Server version 7.0 or SQL Server 2000.

For more information about setting the backward compatibility level, see SQL Server 2000 and SQL Server version 6.5.

If you are upgrading replication on a failover cluster, you must uncluster the previous installation before upgrading. Unclustering the previous installation means that you must delete all publications, remove replication, and reconfigure it after upgrading to SQL Server 2000. This will not be a requirement when upgrading SQL Server 2000 to future releases.

Upgrading and Immediate Updating

If you are using immediate updating with snapshot replication or transactional replication, changes to that feature in SQL Server 2000 will affect how you upgrade. Rows in immediate updating articles now use a uniqueidentifier column to identify versions, whereas in SQL Server 7.0, a timestamp column was used. In addition, the triggers generated for immediate updating have been changed, and the trigger generation code has been modified to accommodate queued updating. Because of these changes, additional upgrade steps are necessary.

If using immediate updating:

  • Upgrade both the Publisher and Subscriber before replicating data.

  • Drop the publication and all subscriptions to the publication.

  • Use an ALTER TABLE DROP COLUMN Transact-SQL statement to drop the timestamp column from the tables on the Publisher and from the tables on the Subscriber that allow Subscriber updates.

  • Re-create the publication and subscriptions. The system adds a uniqueidentifier column to the published table. That column is used for row versioning (to detect conflicts when receiving updates from the Subscriber).

Although it is recommended you upgrade both the Publisher and the Subscriber and then drop and re-create the existing publications, the Publisher and Subscribers can be upgraded in any order. If you need to reinitialize a Subscriber or add a new Subscriber, you need to drop and re-create the publication.

Upgrading and File Transfer Protocol

If using File Transfer Protocol (FTP), you should follow the recommended upgrade path, which ensures that Subscribers are able to obtain the necessary FTP information from the Distributor.

SQL Server 2000 stores FTP parameters as Publication Properties; you no longer need to administer them at the Subscriber for each subscription. When upgrading to SQL Server 2000, the FTP option in the Publication Properties is turned off, and you need to open the properties for each publication that uses FTP, and then reset the FTP parameters.

SQL Server 7.0 Subscribers will continue to locate FTP files using the FTP parameters stored in the Subscription Properties when using a Distributor running an instance of SQL Server 2000. However, Subscribers running an instance of SQL Server 2000 will not be able to obtain FTP information from Distributors running earlier versions of SQL Server.

Existing subscriptions using merge replication or transactional replication will be unaffected by this change unless you need to reinitialize or connect to the FTP site. The FTP parameters need to be specified before snapshot replication occurs, or replication agents will not be able to locate the snapshot files.

For more information about changing the FTP parameters, see Using TCP/IP and FTP and How to specify FTP information (Enterprise Manager).

Troubleshooting and Replication Upgrades

If errors occur while upgrading replication servers, they might be related to the database being offline or unavailable or a script may have failed. For more information about troubleshooting errors that occur when upgrading replication, see Help with Replication.

It is recommended that you stop all data modifications at the replication server while it is being upgraded. When upgrading from SQL Server 6.5, you must run the Log Reader Agent and Distribution Agent before upgrading to make sure there are no replicated commands pending delivery to Subscribers.

Because you can upgrade servers running instances of Microsoft® SQL Server™ 2000 one at a time, you may have circumstances where servers in your replication topology are running different versions of SQL Server. You can replicate between different versions of SQL Server, but you are often limited to the functionality of the earliest version used.

Important When upgrading from SQL Server 6.5 or 7.0 to SQL Server 2000, SQL Server Setup runs several *.sql replication scripts. Although the upgrade process can take several minutes and does not display progress notifications, you can view error messages in the *.out and *.err files located in the SQL Server Install directory.

See Also

Publishing Data Over the Internet Using TCP/IP and FTP

Replication Between Different Versions of SQL Server

Replication Data Considerations

Updatable Subscriptions


Upgrading Databases from SQL Server 7.0 (Copy Database Wizard)

New Information - SQL Server 2000 SP3.

As an enhancement to the regular upgrade procedure, you can perform an online upgrade of databases and associated meta data. Using the Copy Database Wizard, you can move or copy a database from Microsoft® SQL Server™ 7.0 to an instance of Microsoft SQL Server 2000, without having to shut down any servers in the process.

Advantages of an online database upgrade include:

  • No downtime for servers during the upgrade.

  • Custom selection of databases to upgrade, leaving other databases still available to the original (SQL Server 7.0) server.

  • Inclusion of related meta data in the upgrade procedure. For example, logon information, jobs, and user-specific objects associated with user databases can be included.

  • The process can be run at a convenient time.

The Database Copy Wizard is based on detach and attach functionality that allows user databases to be moved or copied from a source to a destination server. A Data Transformation Services (DTS) package performs the actual move or copy operation You can schedule the package to run at a specified time or rerun the package if required.

Options for SQL Server 7.0 Database Upgrades

Database administrators can move or copy one or more databases from an instance of SQL Server 7.0 to the default instance of SQL Server 2000 on your local computer or to a named instance on a remote computer. This upgrade feature does not support SQL Server 6.5 databases.

Local computer
  • SQL Server 7.0 databases can be upgraded to a named instance of SQL Server 2000 on the local computer.
Remote computer
  • SQL Server 7.0 databases can be upgraded to a default instance of SQL Server 2000 on a remote computer.

  • SQL Server 7.0 databases can be upgraded to a named instance of SQL Server 2000 on a remote computer.

Note You can have only one active default instance of SQL Server on a computer at one time; either a default instance of SQL Server 7.0 or a default instance of SQL Server 2000. SQL Server 6.5 can also be a default instance. For more information, see Working with Instances and Versions of SQL Server.

Exceptions

The Copy Database Wizard cannot be used in these situations:

  • A database with the identical name on both source and destination servers cannot be moved or copied. On the database selection screen, it will be noted as "Already exists."

  • For databases involved in replication, a regular server upgrade is required.
Copy Database Wizard Safeguards

At the start of a database move or copy operation, one administrator must have exclusive use of all files to prevent any changes to the file set during the process. Two connections are required to copy database files: sysadmin privileges on both installations of SQL Server and administrator privileges on the server/network.

To prevent any chance of data corruption in SQL Server 7.0 databases, you must make sure that no users, applications or services are trying to access the databases.

Note Do not place your SQL Server 7.0 database in read-only mode, as this will generate an error during the execution of the Copy Database Wizard.

The database cannot be renamed during this operation. Any name conflicts between source and destination servers must be resolved manually prior to upgrading databases. Nothing on the destination server is overwritten.

If you move or copy multiple databases in one operation, each database is actually moved one at a time; that is, one database at a time is detached, files are copied and then reattached. To avoid any problems, the DTS package writes a message to the error log indicating that the database is about to be detached from its source server. At the same time, a script is prepared to attach the database to its destination. After the database is successfully attached to the destination, another entry is written to the log indicating successful completion.

When upgrading to a destination that is a clustered server, the Copy Database Wizard will ensure you select only shared drives on a clustered destination server. The source server may also be clustered.

Note Unrelated to this upgrade process, you can also use the Copy Database Wizard to move or copy user databases from one instance of SQL Server 2000 to another instance of SQL Server 2000. For more information, see Using the Copy Database Wizard.

To upgrade databases online using the Copy Database Wizard

Wizard

Wizard

See Also

Database Copy Wizard Help


Upgrading Databases from SQL Server 6.5 (Upgrade Wizard)

You can convert data from Microsoft® SQL Server™ version 6.5 to the formats for SQL Server 2000 using the SQL Server Upgrade Wizard. The wizard upgrades any or all of your databases, transferring all catalog data, objects, and user data. It also transfers replication settings, SQL Executive settings, and most of the SQL Server 6.5 configuration options. Be sure to review all aspects of this upgrade, as noted in Preparing to Upgrade from SQL Server 6.5.

Note To run the SQL Server Upgrade Wizard, you must have a default instance of Microsoft SQL Server 2000 installed on your computer.

The SQL Server Upgrade Wizard does not support consolidation of databases from multiple SQL Server 6.5 installations. If you must upgrade SQL Server 6.5 databases from multiple servers, consolidate all of the SQL Server 6.5 databases onto one server, and then run the wizard to upgrade the consolidated server.

The SQL Server Upgrade Wizard does not remove SQL Server 6.5 from your computer. If you are using a tape backup to perform the upgrade, you have the option of removing the SQL Server 6.5 devices to save disk space.

When the upgrade process is complete, two separate installations of SQL Server exist, including two separate sets of the same data. The SQL Server 6.5 and the SQL Server 2000 installations become independent of each other.

If you are performing the upgrade on a single computer, additional disk space is required. For more information, see Estimating the Disk Space Required for Upgrading. You can also upgrade from one computer to another. For more information, see Upgrading Using One or Two Computers (Logon Screen).

Note You can leave the installation of SQL Server 6.5 on a computer indefinitely. In addition to installations of SQL Server 6.5 and a default instance of SQL Server 2000 on the same computer, you also can install multiple named instances of the SQL Server 2000 on the same computer. For more information, see Working with Instances and Versions of SQL Server.

To perform a version upgrade using a direct pipeline

SQL Setup

SQL Setup

To perform a version upgrade using a tape drive

SQL Setup


Preparing to Upgrade from SQL Server 6.5

Follow this checklist before using the SQL Server Upgrade Wizard to move from Microsoft® SQL Server™ version 6.5 to Microsoft SQL Server 2000:

  • Back up the SQL Server 6.5 database files (all .dat files, including master) so you can completely restore them if necessary.

  • Run the appropriate Database Console Commands (DBCC) on the SQL Server 6.5 databases to ensure they are in a consistent state.

  • Estimate the disk space required. In addition to the hard disk space used by Microsoft SQL Server 2000, you need approximately 1.5 times the size of the SQL Server 6.5 databases.

  • Set tempdb to at least 10 MB in the SQL Server 6.5 installation, 25 MB is recommended.

  • Ensure the master database has at least 3 MB of free space.

  • Ensure that all database users have logon information in the master database.

    This is important for restoring a database because system logon information resides in the master database.

  • Ensure the @@SERVERNAME is defined on SQL Server 2000. If @@SERVERNAME is NULL, you can use the sp_addserver system stored procedure. For example, if your computer is named production, the command would be sp_addserver 'production1',local. Changes do not take affect until the MSSQLServer service is restarted.

    Note Because SQL Server 6.5 does not recognize the hyphen (-) in a computer name, replace a hyphen with an underscore (_).

  • Disable any startup stored procedures.

    The SQL Server Upgrade Wizard starts and stops the SQL Server 6.5 server during the upgrade process. Stored procedures processed at startup may cause the upgrade process to stop responding.

  • Ensure that you upgrade all databases with cross-database dependencies at the same time.

    For example, you want to upgrade three databases, database1, database2, and database4, and there is logon information in SQL Server 6.5 master..sysdatabases for USER1 that defaults to database3 (not one of the databases you are upgrading). The SQL Server Upgrade Wizard does not create the logon information because the database is not upgraded, and therefore does not exist in SQL Server 2000. If USER1 is listed as the owner for objects in any of the databases upgraded, those objects cannot be created because the logon information for USER1 does not exist.

  • If performing a two-computer upgrade, assign a domain user name and password to the MSSQLServer service for SQL Server 6.5 and SQL Server 2000 instead of using the local system account or a local user account. The domain user account should belong to the Administrators group of both the computers involved in the upgrade. (The local system account is sufficient for a one-computer upgrade.)

  • Stop replication and ensure that the log is empty.

  • Quit all applications, including all services dependent on SQL Server.

If you copied the SQL Server 6.5 databases to a new computer to perform the upgrade, you may need to update the new SQL Server 6.5 master database as follows:

  • Change references from the earlier server name to the current server name in the SQL Server 6.5 master database.

  • Update the device file locations in the SQL Server 6.5 master database.

  • Ensure all users have corresponding logon information.

To change the size of tempdb in SQL Server 6.5

Transact-SQL

Transact-SQL

To change to the current server name in the SQL Server 6.5 master database

Transact-SQL

Transact-SQL

To update the device file locations in the SQL Server 6.5 master database

Transact-SQL

Transact-SQL

See Also

Estimating the Disk Space Required for Upgrading

Upgrading Using One or Two Computers (Logon Screen)

How To Upgrade from SQL Server 6.5


Estimating the Disk Space Required for Upgrading

Before you perform an upgrade of Microsoft® SQL Server™ version 6.5 to SQL Server 2000, ensure that there is available disk space. This is important if you intend to perform either a one-computer or a two-computer upgrade.

The SQL Server Upgrade Wizard estimates the disk space necessary to upgrade the SQL Server 6.5 server to SQL Server 2000. The wizard examines the current SQL Server 6.5 installation and estimates the amount of disk space the SQL Server 6.5 data will occupy in SQL Server 2000.

You can estimate:

  • The size of SQL Server 2000 databases.

  • The size of SQL Server 2000 logs.

  • The amount of disk space required for tempdb.

Note The SQL Server Upgrade Wizard estimates the disk space required; it cannot give an exact requirement.

To estimate the disk space required for an upgrade

Windows


Data and Object Transfer

The Data and Object Transfer screen allows you to choose upgrade options.

Export from 6.5 Server / Import

The objects and data check boxes indicate that the SQL Server Upgrade Wizard exports catalog data, objects, and user data from selected Microsoft® SQL Server™ version 6.5 databases and imports them into newly created SQL Server 2000 databases.

Data Transfer Method

You can perform an upgrade using either of the following data transfer methods:

  • Named pipe (simultaneous import/export)

    A direct pipeline enables the SQL Server Upgrade Wizard to transfer data in memory from Microsoft SQL Server version 6.5. This data transfer method is the most reliable and provides the best performance. However, when performing a one-computer upgrade, you cannot reuse the disk space occupied by the SQL Server 6.5 devices until the version upgrade process is complete, so use this option only if you have disk space available.

  • Tape (requires a Microsoft Windows NT® tape driver to be installed)

    The SQL Server Upgrade Wizard backs up to tape all of the SQL Server 6.5 databases you have selected to upgrade. The SQL Server Upgrade Wizard then optionally deletes all of the SQL Server 6.5 devices, freeing disk space before new data files are created.

    Important The SQL Server Upgrade Wizard deletes all of the SQL Server 6.5 devices, not only those upgraded. You should upgrade all databases if you choose to delete the SQL Server 6.5 devices.

    The tape backup option should be used only when you want to upgrade on a single computer but there is not enough space on the hard disk to install SQL Server 2000 alongside SQL Server 6.5 and perform the version upgrade.

    Note The SQL Server Upgrade Wizard uses a named pipe, even when performing a tape backup upgrade. SQL Server 6.5 and SQL Server 2000 must be set to listen to the default named pipe, \\.\pipe\sql\query.

Verification

The transfer of objects and data by the SQL Server Upgrade Wizard is a very reliable process. If any objects could not be imported due to errors in those objects or compatibility problems with Microsoft SQL Server, they are noted in the output logs of the SQL Server Upgrade Wizard.

The SQL Server Upgrade Wizard also offers the following optional verification measures:

  • Validate successful object data transfer

    The SQL Server Upgrade Wizard examines the SQL Server 6.5 databases before the upgrade process and SQL Server 2000 databases after the upgrade. For each, the wizard prepares a list of all objects, including schema and stored procedures, and the number of rows in each table. The wizard then compares the two lists and reports any discrepancies.

  • Exhaustive data integrity verification

    The SQL Server Upgrade Wizard performs a checksum for each column of each table before and after the upgrade to verify that data values have not changed.

    Note The SQL Server Upgrade Wizard does not report as errors any intentional differences in objects. If some objects, typically stored procedures, could not import due to errors in the objects or compatibility problems with SQL Server 2000, they are reported twice: once in the SQL scripts that show the source code of the objects and the error messages received from SQL Server 2000 when trying to create them, and then again in the output of the verification processes.


Order of Upgrade Using a Direct Pipeline or Tape Drive

The SQL Server Upgrade Wizard performs a version upgrade using the options specified. The Microsoft® SQL Server™ version 6.5 server and data used by SQL Server 6.5 databases are left intact throughout the version upgrade process. At this time, the SQL Server 6.5 catalog data, objects, and databases are converted so that they are compatible with SQL Server 2000. After the version upgrade is complete, SQL Server 2000 becomes your production system.

The order of upgrade is basically the same for both a direct pipeline and a tape drive upgrade. The one difference is in how data is exported and imported. When using a tape drive, data is exported to the tape drive after shutting down SQL Server 6.5 and before starting SQL Server 2000. This data is then imported from the tape drive later to SQL Server 2000. When using a direct pipeline, the export and import steps are combined in one step, simultaneously.

The following list shows the order in which the SQL Server Upgrade Wizard performs the upgrade from SQL Server 6.5 to SQL Server 2000. The differences between the direct pipeline and tape drive methods are noted.

  • Starts SQL Server 6.5

  • Updates ODBC and SQL-DMO components on SQL Server 6.5

  • Examines SQL Server 6.5 databases

  • Exports replication settings

  • Exports server configuration settings from the master database

  • Exports logon information

  • Exports database owners

  • Exports SQL Executive objects and settings from the msdb database

  • Exports database objects for all databases chosen

  • Shuts down SQL Server 6.5
    • Tape Drive only: Exports data to tape

    • Tape Drive only: Backs up and then deletes SQL Server 6.5 devices
  • Starts SQL Server 2000

  • Creates databases

  • Modifies SQL Executive objects and settings to SQL Server 2000 formats

  • Imports logon information

  • Imports database objects
    • Tape Drive only: Imports data from tape into SQL Server 2000

    • Direct Pipeline only: Simultaneously exports data from SQL Server 6.5 and imports it into SQL Server 2000
  • Imports modified SQL Executive objects and settings into SQL Server 2000

  • Imports replication settings

  • Examines SQL Server 2000 databases

  • Verifies that the upgrade is successful

  • Sets database options in SQL Server 2000

  • Marks server and databases as moved

  • Drops temporary tempdb files


Upgrading Using One or Two Computers (Logon Screen)

The upgrade process can take place on a single computer or from one computer to another, depending on where Microsoft® SQL Server™ version 6.5 and SQL Server 2000 are installed. The SQL Server Upgrade Wizard identifies the two servers as the export server and import server.

  • For a one-computer upgrade, leave the import and export servers at their default values.

  • For a two-computer upgrade, select the name of the computer with your SQL Server 6.5 server as the export server. To upgrade SQL Server from one computer to another, the two computers must be in the same network domain.

Important The one-computer upgrade is the only method supported when upgrading a server used in replication. A two-computer upgrade is not supported for replication servers.

Export server (6.5)

Export server (6.5) is the name of the SQL Server 6.5 server. This defaults to the name of the computer on which the SQL Server Upgrade Wizard is run, but may be changed if your SQL Server 6.5 server is on another computer.

  • Server name

    Server name is the name of your SQL Server version 6.5 server. This defaults to the name of the computer on which the SQL Server Upgrade Wizard is run, but may be changed if your SQL Server 6.5 server is on another computer.

  • Administrator password ('sa')

    Enter the system administrator (sa) password for the SQL Server 6.5 server. Unless you have changed it since installing SQL Server 2000, the default sa password is blank. To conform to best security practices, it should be changed to a strong password at the first opportunity.

  • Optional startup arguments

    Enter any trace flags or other startup parameters to be used when the SQL Server Upgrade Wizard starts the SQL Server 6.5 server.

Import server

The import server is the name of the SQL Server 2000 server. This is always the name of the computer on which the SQL Server Upgrade Wizard is run.

  • Server name

    Server name is the name of your SQL Server 2000 server computer. This is always the name of the computer on which the SQL Server Upgrade Wizard is run.

  • Administrator password ('sa')

    Enter the system administrator (sa) password for the SQL Server 2000 server. Unless you have changed it since installing SQL Server 2000, the default sa password is blank. To conform to best security practices, it should be changed to a strong password at the first opportunity.

  • Optional startup arguments

    Enter any trace flags or other startup parameters to be used when the SQL Server Upgrade Wizard starts the SQL Server 2000 server.


Selecting a Scripting Code Page

The SQL Server Upgrade Wizard requires the selection of a scripting code page, which is used to create the upgrade scripts. When the Code Page Selection screen appears in the Upgrade Wizard, most users can accept the default code page, which is the code page recorded in the master database.

In some cases, the actual code page used for a Microsoft® SQL Server™ 6.5 installation differs from the code page recorded in the master database. If you know that the actual code page is different from the recorded code page, select the actual code page in the list on the Code Page Selection screen.

Caution If you choose a scripting code page other than the default, do not upgrade replication settings. If the server is involved in replication, reconfigure the replication settings after the upgrade is complete.

The enhancements to collation settings in SQL Server 2000 do not apply directly to this selection of a code page for the SQL Server 6.5 upgrade. For more information about collation enhancements, see Collations.


Selecting Databases to Upgrade

When running the SQL Server Upgrade Wizard, you can choose to upgrade some or all Microsoft® SQL Server™ version 6.5 databases. The master, msdb, and publication system databases, as well as the pubs and Northwind sample databases, are not explicitly available for selection. However, the master, msdb, and publication databases can be selected for upgrading (the default) in the Server Configuration dialog box of the SQL Server Upgrade Wizard.

Note If you run the SQL Server Upgrade Wizard again after databases have been upgraded, previously updated databases will default to the excluded list. If you want to upgrade a database again, drop the database in SQL Server 2000 and move it to the included list in the wizard.


Database Configuration

Before any data is transferred, the SQL Server Upgrade Wizard creates, if necessary, database and log files large enough to contain the upgraded database data. On the Database Creation screen there are several options for creating the Microsoft® SQL Server™ 2000 database and log files.

Using the Default Database Configuration

The SQL Server Upgrade Wizard estimates how much disk space is necessary to hold transferred objects and data for each selected database and creates database files of the estimated sizes. The wizard makes no allowance for free space beyond the loaded data. By default, the data file for a database is placed in the same location as the first device used by that database in SQL Server 6.5.

The SQL Server Upgrade Wizard also creates a log file for each database using the SQL Server 6.5 log size. By default, the log file is placed in the same location as the first device used for log space in SQL Server 6.5.

You can view and edit the default database configuration in the SQL Server Upgrade Wizard. For each database and log file you can modify:

  • The name and file path.

  • The initial size of the file.

  • The autogrow increment.

If using multiple devices in a SQL Server version 6.5 database, then multiple database files are created in the same location. However, the first database file is sized to accommodate the bulk of the data, and the other files are minimally sized. If you want to remove these files, you must do so before they are created. All files are set to grow automatically if extra space is required.

Using a Custom Database Configuration

You can specify a custom configuration in two ways:

  • Using databases and logs that you created in SQL Server 2000.

    The SQL Server Upgrade Wizard does not create any user databases. You must create the necessary databases and logs in SQL Server 2000 before you start the SQL Server Upgrade Wizard. Use this option only if necessary.

  • Using an SQL script file that you provide.

    The SQL Server Upgrade Wizard uses an SQL script file that you provide to create the necessary user databases and logs. Use this option only if you are familiar with the new CREATE DATABASE statement in SQL Server 2000.

If you create the user databases or an SQL script file, the SQL Server 2000 databases must have the same names as in SQL Server 6.5. Also, remember that data may take up more disk space in SQL Server 2000 than in SQL Server 6.5. The SQL Server Upgrade Wizard estimates this growth. You can view the proposed layout of the SQL Server 2000 data files to see the estimated initial size of the SQL Server 2000 database, and edit the default configuration, if necessary. For more information, see Proposed Database Layout.

It is recommended that you leave the autogrow feature on for each database. You may also want to set a backward compatibility level for each database.

To edit the default database configuration

Wizard

Wizard

See Also

CREATE DATABASE

Estimating the Disk Space Required for Upgrading


Proposed Database Layout

The Proposed Database Layout dialog box lists the databases, file groups, and data files that the Microsoft® SQL Server™ Upgrade Wizard will create. You can create or remove file groups and data files from the File menu. Double-click a data file to edit the file name, initial size, or file growth details.

Object Details

Click on a file group or data file in the proposed database layout to view details. Click a database in the proposed database layout to view summary information.

Drive Summary

The drive summary lists all local fixed-disk drives. For each drive, the existing SQL Server version 6.5 data file size, proposed SQL Server 2000 data file size, and free space are listed. On the Options menu, select Freespace includes 6.5 files to view the free space that would exist if the SQL Server 6.5 data files were deleted. This option shows the disk space available if the upgrade is performed using tape and the SQL Server 6.5 devices are deleted.

See Also

Database Configuration


Tape Upgrade Transfer Options

When you perform a tape backup, you must select a tape drive and choose how the SQL Server Upgrade Wizard handles backing up and deleting objects in the Microsoft® SQL Server™ version 6.5 databases.

Device for Data Transfer

The SQL Server Upgrade Wizard transfers all of the data you are upgrading to this tape drive before the SQL Server 2000 databases are created.

Backing Up the SQL Server 6.5 Devices

You may also choose to back up the SQL Server 6.5 devices. This is separate from the transfer to tape that the SQL Server Upgrade Wizard uses to complete the upgrade. There are two options for backing up the devices:

  • Prompt me to backup my devices manually

    Before data is exported, the SQL Server Upgrade Wizard pauses and prompts you to perform a backup. The SQL Server Upgrade Wizard does not perform a backup for you. You must use a backup utility such as Microsoft Windows NT® Backup.

  • Automatically copy device files to the following location

    Before data is exported, the SQL Server Upgrade Wizard copies the device files to a shared network directory.

Warning If you back up the devices to tape, remove the tape backup and insert a blank tape before continuing. Before the SQL Server Upgrade Wizard begins transferring data to the tape drive, it formats the tape in the drive. If you do not remove your tape backup, the SQL Server Upgrade Wizard overwrites it.

Deleting the SQL Server 6.5 Devices

If you decide to delete your SQL Server 6.5 devices before creating the SQL Server 2000 databases, you can choose whether to be prompted before the devices are deleted. All of the SQL Server 6.5 device files will be deleted if you choose to delete devices, even if you are upgrading only one database. This will render the SQL Server 6.5 server unusable until the files are restored.

Note If you choose not to delete the devices, you must have enough disk space for both the SQL Server 6.5 and SQL Server 2000 databases. If sufficient space is available, you should use a Named Pipe upgrade instead of a Tape upgrade.

See Also

How to perform a SQL Server version 6.5 to SQL Server 2000 upgrade using a tape drive (SQL Server Upgrade Wizard)


System Configuration

On the System Configuration screen, you can set options for system objects to transfer, ANSI Nulls, and quoted identifiers.

System Objects to Transfer

When the SQL Server Upgrade Wizard upgrades the master database, it can upgrade several configuration options:

  • Server configuration

    Logon information and remote logon registrations and server configuration options relevant to Microsoft® SQL Server™ 2000 are transferred as part of the version upgrade process. The SQL Server 6.5 configuration options not used in SQL Server 2000 are not transferred.

  • Replication settings

    All articles, subscriptions, and publications of each selected database, including the distribution database, if any, are transferred and upgraded.

  • SQL Executive settings

    All tasks scheduled by SQL Executive are transferred and upgraded so that the SQL Server 2000 can schedule and run the tasks in SQL Server Agent.

Note Upgrading replication or SQL Executive settings causes existing modifications made to the SQL Server 2000 replication or SQL Server Agent settings to be overwritten.

ANSI Nulls

The ANSI_NULLS option controls both database default nullability and comparisons against null values. When upgrading Microsoft SQL Server version 6.5 to the SQL Server 2000, set the ANSI_NULLS option to ON or OFF.

When the SQL Server Upgrade Wizard creates the SQL Server 2000 database tables, the database default nullability determined by the ANSI_NULLS option is not an issue. All columns are explicitly qualified as NULL or NOT NULL based on their status in SQL Server 6.5.

The ANSI_NULLS option is important with regard to comparisons against null values, when the SQL Server Upgrade Wizard creates the SQL Server 2000 database objects. With ANSI_NULLS set to ON, the comparison operators EQUAL (=) and NOT EQUAL (<>) always return NULL when one of its arguments is NULL. With ANSI_NULLS set to OFF, these operators return TRUE or FALSE, depending on whether both arguments are NULL.

In SQL Server 6.5, the ANSI_NULLS option in objects, such as stored procedures and triggers, is resolved during query execution time. In SQL Server 2000, the ANSI_NULLS option is resolved when the object is created. You must choose the ANSI_NULLS option setting you want for all objects in the databases you are upgrading. The SQL Server Upgrade Wizard then creates all database objects using this ANSI_NULLS setting.

Quoted Identifiers

Note Quoted identifiers are used by default in SQL Server 2000, that is, they are set to ON. This is different from SQL Server 7.0 where they were set to OFF by default.

The QUOTED_IDENTIFIER setting determines what meaning Microsoft SQL Server gives to double quotation marks ("). When QUOTED_IDENTIFIER is set to OFF, double quotation marks delimit a character string, just as single quotation marks do. When QUOTED_IDENTIFIER is set to ON, double quotation marks delimit an identifier, such as a column name. An identifier must be enclosed in double quotation marks; for example, if its name contains characters that are otherwise not allowed in an identifier, including spaces and punctuation, or if the name conflicts with a reserved word in Transact-SQL. Regardless of the QUOTED_IDENTIFIER setting, an identifier can also be delimited by square brackets.

The meaning of the following statement, for example, depends on whether QUOTED_IDENTIFIER is set to ON or OFF:

SELECT "x" FROM T

If QUOTED_IDENTIFIER is set to ON, "x" is interpreted to mean the column named x. If it is set to OFF, "x" is the constant string x and is equivalent to the letter x.

If the previous SELECT statement example were part of a stored procedure created when QUOTED_IDENTIFIER was set to ON, then "x" would always mean the column named x. Even if the QUOTED_IDENTIFIER setting was later switched, and set to OFF, the stored procedure would respond as if it were set to ON and treat "x" as the column named x.

When the SQL Server Upgrade Wizard re-creates database objects in SQL Server 2000, the QUOTED_IDENTIFIER setting determines how all of these objects behave. If all database objects were created in SQL Server 6.5 with the same QUOTED_IDENTIFIER setting, click that setting, either On or Off. If objects were created in SQL Server version 6.5 with a mix of the two settings, or if you are unsure of the settings used, click Mixed.

With the Mixed option, the SQL Server Upgrade Wizard first converts all objects containing double quotation marks with QUOTED_IDENTIFIER set ON. The SQL Server Upgrade Wizard then converts any objects that failed to be created with QUOTED_IDENTIFIER set OFF.

See Also

How to perform a SQL Server version 6.5 to SQL Server 2000 upgrade using a direct pipeline (SQL Server Upgrade Wizard)

How to perform a SQL Server version 6.5 to SQL Server 2000 upgrade using a tape drive (SQL Server Upgrade Wizard)


Completing the SQL Server Upgrade Wizard

Use this screen to view the summary of choices you have made.

Click View warnings and choices in notepad to open a text version of the upgrade script. If all options are correct, click Finish.


Upgrade Script Interpreter

After you click Finish, this screen displays the progress of the upgrade.

Progress indicator

Displays information about the current task and its progress toward completion. The information presented varies according to the type of task.

Task

The SQL Server Upgrade Wizard adds each upgrade task to the list as it is started.

Status

The SQL Server Upgrade Wizard displays the status (Running, Done, or Error) for each task.

Started

The SQL Server Upgrade Wizard displays the time and date on which the task began.

End

The SQL Server Upgrade Wizard displays the time and date on which a completed or terminated task is finished.

Pause Task

Temporarily suspends the version upgrade process until you click Resume.

Cancel Task

Cancels the currently running task and proceeds to the next task. Do not cancel a task unless you are certain the current task does not need to be completed before subsequent tasks are run.

Retry Task

Retries the current upgrade task. If a task ended in an error and you corrected the problem, the SQL Server Upgrade Wizard retries the current task.

Pause Between Steps

Allows you to participate interactively in the version upgrade process and track the progress of the SQL Server Upgrade Wizard. The SQL Server Upgrade Wizard asks for confirmation between each step of the version upgrade process.


Backward Compatibility

Backward compatibility issues are divided in these sections:

  • For issues related to upgrades from Microsoft® SQL Server™ version 7.0 to SQL Server 2000, see:

    SQL Server 2000 and SQL Server version 7.0

  • For issues related to upgrades between SQL Server 6.5 and Microsoft SQL Server 2000, see:

    SQL Server 2000 and SQL Server version 6.5

    If upgrading from SQL Server 6.5 to SQL Server 2000, review both sections.


SQL Server 2000 and SQL Server version 7.0

New Information - SQL Server 2000 SP3.

Microsoft® SQL Server™ 2000 is compatible with SQL Server 7.0 in most ways. The section describes backward compatibility issues when upgrading from SQL Server 7.0 to SQL Server 2000:

  • Client Network Utility and Named Instances

  • Multiserver Jobs and Named Instances

  • Upgrading SQL Server 6.5 Client Software

  • Authentication Modes

  • ROWCOUNT Setting for Operations Against Remote Tables

  • Server Configuration Options

  • Recovery Models and Database Options

  • Reserved Keywords

  • SQL Profiler Extended Stored Procedures

  • Default Connection Option Settings in SQL Query Analyzer

  • bcp Utility

  • Database Diagrams from Earlier Versions of Visual Database Design Tools

  • Data Transformation Services

  • Specifying Trusted Connections

  • Extended Objects in SQL-DMO

  • SQL-SCM

  • English Query and SQL Server 7.0 OLAP Services
Client Network Utility and Named Instances

When using the SQL Server client connectivity components from SQL Server 7.0 or earlier, you must set up an alias using the Client Network Utility before you connect to a named instance of SQL Server 2000. For example, on a SQL Server 7.0 client, to connect to a named instance of SQL Server 2000, you must add an alias that points to \\computername\pipe\MSSQL$instancename\sql\query. If you use an alias name of computername\instancename, clients can connect by specifying this name in the same way as SQL Server 2000 clients do. For the TCP/IP Sockets and NWLink IPX/SPX Net-Libraries, you must use the Client Network Utility to define an alias on the client that specifies the port address on which the named instance is listening.

Multiserver Jobs and Named Instances

When using Master Servers and Target Servers, SQL Server 7.0 cannot interoperate with named instances of SQL Server 2000. To use an instance of SQL Server 7.0 with an instance of SQL Server 2000 for MSX/TSX operations, you must use a default instance, not a named instance, of SQL Server 2000.

Upgrading SQL Server 6.5 Client Software

When running an instance of SQL Server version 6.5 on a server, this issue applies:

If you are upgrading from SQL Server 6.5 client software to SQL Server 2000 client software (and you have an application that uses the default Net-Library), you must use the Client Network Utility to make either Named Pipes or Multiprotocol the default Net-Library to make Windows Authentication connections.

Authentication Modes

SQL Server 2000 can operate in one of two security (authentication) modes:

  • Windows Authentication Mode (Windows Authentication)

  • Mixed Mode (Windows Authentication and SQL Server Authentication)

Mixed Mode allows users to connect using Windows Authentication or SQL Server Authentication. Users who connect through a Microsoft Windows NT® 4.0 or Windows 2000 user account can make use of trusted connections (connections validated by Windows NT 4.0 or Windows 2000) in either Windows Authentication Mode or Mixed Mode.

Security Note When possible, use Windows Authentication.

SQL Server Authentication is provided for backward compatibility. An example of SQL Server Authentication would be if you create a single Microsoft Windows® 2000 group, add all necessary users to that group, and then grant the Windows 2000 group login rights to SQL Server and access to any necessary databases.

ROWCOUNT Setting for Operations Against Remote Tables

ROWCOUNT is not supported for INSERT statements against remote tables in SQL Server 2000 when the database compatibility level is set to 80. For these INSERT operations, the SET ROWCOUNT option is ignored.

The ROWCOUNT setting for INSERT statements against remote tables was supported in SQL Server 7.0.

Server Configuration Options

These server configuration options are not supported in SQL Server 2000.

default sortorder id | resource timeout
extended memory size | spin counter
language in cache | time slice
language neutral full-text | unicode comparison style
max async IO | unicode locale id

For more information about configuration options, see Setting Configuration Options and sp_configure.

Recovery Models and Database Options

Microsoft® SQL Server™ 2000 provides the following recovery models to simplify recovery planning, simplify backup and recovery procedures, and to clarify tradeoffs between system operational requirements:

  • Simple Recovery

  • Full Recovery

  • Bulk-Logged Recovery

Each model addresses different needs for performance, disk and tape space, and protection against data loss.

In SQL Server 7.0 and earlier, similar functionality was provided through the combined settings of the trunc. log on chkpt and select into/bulkcopy database options, which could be set using the sp_dboption stored procedure.

This table maps the settings of trunc. log on chkpt and select into/bulkcopy to the new recovery models.

If trunc. log on chkpt is: | And select into/bulkcopy is: | The recovery model is:
FALSE | FALSE | FULL
FALSE | TRUE | BULK-LOGGED
TRUE | TRUE | SIMPLE
TRUE | FALSE | SIMPLE

Note If you upgrade a database in which the trunc. log on chkpt and select into/bulkcopy options are set to TRUE, select into/bulkcopy is set to FALSE, forcing the database into the simple recovery model.

The trunc. log on chkpt and select into/bulkcopy database options are supported in SQL Server 2000 for backward compatibility purposes, but may not be supported in future releases.

In SQL Server 2000, the ALTER DATABASE Transact-SQL statement provides a SET clause for specifying database options, including recovery models. For more information about database options, see Setting Database Options and ALTER DATABASE.

Reserved Keywords

These words are no longer reserved keywords in SQL Server 2000: AVG, COMMITTED, CONFIRM, CONTROLROW, COUNT, ERROREXIT, FLOPPY, ISOLATION, LEVEL, MAX, MIN, MIRROREXIT, ONCE, ONLY, PERM, PERMANENT, PIPE, PREPARE, PRIVILEGES, REPEATABLE, SERIALIZABLE, SUM, TAPE, TEMP, TEMPORARY, UNCOMMITTED, WORK.

These words are reserved keywords in SQL Server 2000: COLLATE, FUNCTION, OPENXML.

SQL Profiler Extended Stored Procedures

SQL Profiler extended stored procedures, such as xp_trace_addnewqueue and xp_trace_generate_event, are not supported in SQL Server 2000. They have been replaced by a set of new stored procedures and system user-defined functions. For more information, see Creating and Managing Traces and Templates.

Default Connection Option Settings in SQL Query Analyzer

In SQL Server version 7.0 and earlier, the default setting for SET QUOTED_IDENTIFIER in SQL Query Analyzer was OFF. In SQL Server 2000, the default setting in SQL Query Analyzer is ON, which is also the default setting for ODBC and OLE DB. Moreover, several new features in SQL Server 2000, such as indexed views and indexes on computed columns, require this option to be ON.

Note If you use double quotation marks for strings when QUOTED_IDENTIFIER is ON, you will receive a syntax error.

bcp Utility

To read character files created by earlier versions of DB-Library bcp in SQL Server 2000, use the -V switch. For more information, see bcp Utility.

Database Diagrams from Earlier Versions of Visual Database Design Tools

For users who have database diagrams created with earlier versions of the visual database design tools:

  • If the first visual database tool that was used against a SQL Server 2000 database is a version earlier than the tools in SQL Server 2000, SQL Server Enterprise Manager will not be able to open or create a database diagram in that database. Any attempt to do so results in the error:
    ODBC error: [Microsoft][ODBC SQL Server Driver][SQL Server]Could not find stored procedure 'dbo.dt_getobjwithprop_u'.

    There are several visual database tools that can put a database into this state. These include the Query Designer, the View Designer, the Database Designer, and the Table Designer in SQL Server 7.0 and earlier, as well as many tools that enumerate the objects in a database. These tools are also in Microsoft Access 2000 and Microsoft Visual Studio® 6.

    Running the following script on the database allows SQL Server Enterprise Manager to work with the database diagrams in that database:

    alter table dbo.dtproperties add uvalue nvarchar(255) null
go
if exists(select * from dbo.dtproperties) exec('update dbo.dtproperties set uvalue = convert(nvarchar(255), value)')
go

    After this script has been run, both the SQL Server Enterprise Manager in SQL Server 2000 and the earlier versions of the visual database tools can jointly access the database diagrams in the database. There are additional issues to consider when using the earlier versions of the database tools against a SQL Server 2000 database. For more information, see Hardware and Software Requirements for Installing SQL Server 2000.

Data Transformation Services

These are the backward compatibility issues for Data Transformation Services (DTS).

Extended DTS Objects

Some objects in Data Transformation Services (DTS) are extended in SQL Server 2000. For more information about using new Data Transformation Services objects, methods, and properties with SQL Server 7.0 and earlier, see Extended DTS Objects.

Copy SQL Server Objects Task

There are restrictions on using the Copy SQL Server Objects task (Transfer SQL Server Objects task in SQL Server version 7.0) when copying database objects between an instance of SQL Server 2000 and SQL Server 7.0. For more information, see Copy SQL Server Objects Task.

Running DTS Packages on SQL Server 7.0 or Earlier

DTS packages created on an instance of SQL Server 2000 cannot be loaded or run on an instance of SQL Server version 7.0 or earlier. If you attempt to do this, you may receive one of the following messages:

  • "Invalid class string."

  • "Parameter is incorrect."

Both messages indicate that the current server does not contain all the components necessary to load the package and cannot support objects defined in the DTS package, such as tasks and transformations.

However, if you receive one of these messages, you can still open and run the package on an instance of SQL Server 2000.

Using DTS with Different Collations, Different Code Pages, and Non-Unicode Data

When using the Copy SQL Server Objects task and Copy Column transformation to copy non-Unicode data between an instance of SQL Server 2000 and SQL Server 7.0, issues arise when using different code pages and collations. For more information, see Data Conversion and Transformation Considerations.

Specifying Trusted Connections

In SQL Server 7.0, you did not have to code "trusted_connection=yes" in your connection strings for ADO, OLE DB, or ODBC to obtain a trusted connection. If you did not specify a UID and PASSWORD, SQL Server would default to trying a trusted connection. In SQL Server 2000, you must code "trusted_connection=yes" to obtain trusted connection.

Extended Objects in SQL-DMO

Some objects in SQL-DMO are extended in SQL Server 2000. For more information about using extended SQL-DMO objects, methods, and properties with SQL Server 7.0 or earlier, see Programming Extended SQL-DMO Objects.

SQL-SCM

The SQL-SCM (Service Control Manager) API has been removed and is no longer supported.

English Query and OLAP Services for SQL Server 7.0

For users of OLAP Services for SQL Server 7.0 who want to install or uninstall English Query, these issues apply:

  • OLAP Services for SQL Server 7.0 must not be running during installation. Shut down the OLAP Services service before installing English Query. (See the Services application in Control Panel.)

  • If you have installed OLAP Services for SQL Server 7.0 and you uninstall English Query, you must reinstall OLAP Services. Conversely, if you have installed English Query and you uninstall OLAP Services, you must reinstall English Query to maintain OLAP connectivity.

These issues do not occur with SQL Server 2000 Analysis Services (formerly OLAP Services).


SQL Server 2000 and SQL Server version 6.5

Microsoft® SQL Server™ 2000 is compatible with SQL Server version 6.5 in many respects. Most product functionality of SQL Server version 6.5 remains in SQL Server 2000. Most applications for SQL Server 6.5 work unchanged after the database server is upgraded to SQL Server 2000 by the SQL Server Upgrade Wizard.

The SQL Server 2000 upgrade process:

  • Adds functionality, either new to SQL Server 2000 or changed from earlier versions, which makes tasks easier to accomplish.

  • Minimizes the time and effort needed to upgrade.

In some cases, compatibility issues can arise:

  • Configuration Options

    Some server configuration options have changed.

  • SQL-DMO, Tasks, and Replication

    Task, replication, and device objects have changed. SQL Server 2000 uses jobs instead of tasks, and provides new system tables and system stored procedures.

  • Replication and Triggers

Replication types that allow data modifications at the Subscriber use triggers to track changes to published tables. If there are triggers on your application that modify published tables, the sp_configure server option nested triggers should be enabled. This option affects tables used in merge replication or tables used in snapshot replication or transactional replication with the immediate updating or queued updating option. Before adding these types of replication to an existing database that uses triggers, be sure your application works correctly with the nested triggers option enabled. The nested triggers option is enabled by default; however, if this option was disabled previously, you will need to enable it again.

  • Segments and Devices

    SQL Server 7.0 and SQL Server 2000 use files and filegroups instead of segments and devices for storing indexes or tables. Unless your application depends upon the physical layout of segments within devices, this does not create compatibility problems for your application.

  • System Tables

    If your applications depend upon accessing system tables directly, the applications may need to be revised. It is recommended that you use system stored procedures or information schema views.

    Here are the SQL Server 6.x system tables that are not included with SQL Server 2000.

    master.dbo.spt_datatype_info | sysprocedures
    sysbackupdetail | sysrestoredetail
    sysbackuphistory | sysrestorehistory
    syshistory | syssegments
    syskeys | systasks
    syslocks | sysusages

  • Backup and Restore

    SQL Server 2000 uses BACKUP and RESTORE statements in place of DUMP and LOAD. DUMP and LOAD are supported for backward compatibility, but with some limitations.

  • System Stored Procedures

    Some system stored procedures are no longer supported.

For more information, see the discussion of specific backward compatibility issues.

Setting a Backward Compatibility Level

When running at its default settings, Microsoft SQL Server 2000 implements SQL-92 behaviors for some Transact-SQL statements whose behaviors differed from the standard in earlier versions of SQL Server. SQL Server 2000 also enforces reserved keywords that were not keywords in earlier versions of SQL Server. If upgrading existing systems with existing applications, you can use the database compatibility level settings to retain the earlier behaviors if your existing applications depend on those behaviors. This gives you time to upgrade applications in an orderly fashion. Most applications, however, are not affected by the changes in behavior and work at the SQL Server 2000 compatibility level.

The compatibility level is specified for each database using the sp_dbcmptlevel system stored procedure. The database compatibility level can be set to 60 (version 6.0 compatibility), 65 (version 6.5 compatibility), 70 (version 7.0 compatibility), and the default 80 (SQL Server 2000 compatibility). The effects of the compatibility level settings are generally limited to the behaviors of a small number of Transact-SQL statements that also existed in earlier versions of SQL Server. Even when the database compatibility level is set to 60 or 65, applications gain almost all of the benefits of the new performance enhancements of SQL Server 2000. Applications still benefit from features such as the improved query processor. For more information, see the discussion of specific behaviors controlled by the different settings in sp_dbcmptlevel.

For installations of all instances of SQL Server 2000, the default level for all databases is 80. For upgrades from SQL Server 7.0 to SQL Server 2000, the default level for all databases is 80. For upgrades from SQL Server 6.5 and SQL Server 6.0 to SQL Server 2000, the existing default compatibility level is retained.

Important The compatibility level for the master database is 80 and cannot be changed. If you have added any user-defined objects to master, you must ensure they work correctly at the 80 compatibility level.

The model database is set automatically to the SQL Server 2000 compatibility level during an upgrade. All new user-defined databases are created with the same compatibility level setting as model. If you do not want to use any SQL Server 2000 behavior in new databases created after an upgrade, use sp_dbcmptlevel to change the compatibility level setting in model.

Certain behaviors are not enabled at lower compatibility levels. For example, the keywords LEFT, OUTER, and JOIN are not keywords at compatibility level 60. This means the database compatibility level must be set to 65 or higher before the LEFT OUTER JOIN clause becomes valid. Before any applications can take advantage of features only available at a higher compatibility level, all applications using the database must be upgraded to work correctly at the higher compatibility level.

Likewise, setting the compatibility level of a database to 65 makes the database version-6.5 compatible, but does not necessarily provide version 6.5 behaviors. For example, when SET ANSI_PADDING is ON and you attempt to insert the strings 'abc' and 'abc ' into a primary key column, SQL Server 2000 considers the strings to be duplicates and does not violate the primary key constraint. In SQL Server 6.5, the two strings are considered to be unique and both insertions succeed. Setting the compatibility level to 65 does not force SQL Server 2000 to treat the strings as unique values.

Note While running at compatibility level 60 or 65 preserves legacy behaviors on SQL Server 2000, support for these behaviors may be dropped in future versions of SQL Server. It is recommended that you plan to upgrade your applications to work correctly with the compatibility level set to 80 as soon as is practicable.

See Also

Reserved Keywords

System Stored Procedures

System Tables


SQL Server Backward Compatibility Details

Microsoft® SQL Server™ 2000 adds many new features. Most of the changes are internal and will not affect your database scripts or applications. All Transact-SQL statements are compatible. However, administration tools or scripts should be updated to work with SQL Server 2000.

The backward compatibility topics in this section contain a detailed list of features and behaviors supported in SQL Server version 6.5 that have changed and could possibly affect your administration tools or scripts. These changes are not controlled by the backward compatibility level.

To indicate their potential effect on administration tools or scripts, feature changes have been grouped into four levels.

Level | Consists of
1 | Administrative statements, stored procedures, or SQL Server items that have been removed from, or are no longer supported in, SQL Server 2000. Administrative tools or scripts using these items must be fixed prior to using SQL Server 2000. For more information about these features, see Level 1: Handling Discontinued Functionality.
2 | Important changes that produce different behavior from earlier versions of SQL Server. For example, items in this category are those that have changed behavior in data type conversion or usage of selected functions, changed behavior of clauses in selected Transact-SQL statements and stored procedures, changed column names in selected system tables, and changed behavior due to the database compatibility setting. For more information about these features, see Level 2: Handling Major Changes to Behavior.
3 | Items supported for backward compatibility only. Any item included in this category is fully supported, but may be removed or unsupported in a future release. SQL Server 2000 provides features that accomplish these tasks more efficiently and have ongoing support. For more information about these features, see Level 3: Updating to Improve Earlier Functionality.
4 | Minor changes that produce different behavior from earlier versions of SQL Server. For example, items in this category are either ignored or have one or more ignored parameters, changed byte lengths, added parameters or columns, or changed data type columns. For more information about these features, see Level 4: Handling Minor Changes to Behavior.

Note You might find it helpful to review SQL Server 2000 and SQL Server version 7.0 as well.


SetHostName property not used in SQL Server 2000

When using SQL Server 6.5 integrated security, SQL Server 6.5 did not report the Windows NT account used by a connection unless the system administrator activated the SET HOSTNAME TO USERNAME option in SQL Enterprise Manager.

The setting could also be activated through the SQL-DMO SetHostName property. With this setting in effect, these functions and columns returned the user's Windows NT account name instead of the network name of the client computer:

  • Transact-SQL HOST_NAME() function

  • hostname column in the result set returned by sp_who

  • hostname column in sysprocesses

In SQL Server 2000, the loginame column in the sp_who result set contains the Windows NT account name for connections made using Windows NT Authentication. Applications needing the Windows NT account associated with a connection using Windows NT Authentication should reference this column.

SQL Server 2000 Enterprise Manager no longer presents the SET HOSTNAME TO USERNAME option. SQL Server 2000 ignores the setting of the SQL-DMO SetHostName property.


Level 1: Handling Discontinued Functionality

Backward Compatibility Level 1 consists of administrative statements, stored procedures, or Microsoft® SQL Server™ items that were supported in SQL Server 6.5 but have been removed from, or are no longer supported in, SQL Server 2000. Administrative tools or scripts using these items must be fixed prior to using SQL Server 2000.

This subheading | Relates to
Backup and Restore | BACKUP RESTORE DUMP LOAD sysbackuphistory sysbackupdetail sysrestorehistory sysrestoredetail backupfile backupmediafamily backupmediaset backupset restorefile restorefilegroup restorehistory
Configuration Options | sp_configure (backup buffer size, backup threads, database size, free buffers, hash buckets, LE threshold maximum, LE threshold minimum, LE threshold percent, logwrite sleep, max lazywrite IO, memory, open databases, procedure cache, RA cache hit limit, RA cache miss limit, RA delay, RA pre-fetches, RA slots per thread, RA worker threads, recovery flags, remote conn timeout, SMP concurrency, sort pages, min memory per query, index create memory, tempdb in ram, and user connections options) trace flag 204
Custom Sort Orders | Character sets, sort orders, and Unicode collations
Databases | ALTER DATABASE
Database Options | sp_dboption (subscribe and no chkpt. on recovery options) sp_addsubscription RESTORE
Data Access Objects (DAO) | odbccmpt utility
DBCC | DBCC DBREINDEX DBCC MEMUSAGE DBCC SHRINKDB
DB-Library | Two-Phase Commit DB-Library for Visual Basic
DECnet Network Library | DECnet Sockets Net-Library
Disk Commands | DISK REINIT DISK REFIT ALTER DATABASE
Disk Mirroring | DISK MIRROR DISK REMIRROR DISK UNMIRROR
Indexes | CREATE INDEX
Open Data Services | Windows NT Component Services SRV_CONFIG SRV_PROC SRV_SERVER srv.h Opends60.lib
Program Group Tools and Utilities | Client Network Utility ISQL_w MS Query SQL Client Configuration SQL Enterprise Manager SQL Help SQL Security Manager SQL Trace SQL Performance Monitor SQL Service Manager SQL Setup SQL Query Analyzer SQL Server Enterprise Manager SQL Server Profiler SQL Server Service Manager
Replication | Restricted publications DBOption object ReplicationDatabase object EnablePublishing property repl_publisher login
Security | DENY Delimited Identifiers
Segments | CREATE INDEX CREATE TABLE sp_addsegment sp_dropsegment sp_extendsegment sp_helpsegment CREATE DATABASE ALTER DATABASE
Services | SQL Executive
SET DISABLE_DEF_CNST_CHK | SET DISABLE_DEF_CNST_CHK
SET SHOWPLAN | SET SHOWPLAN SET SHOWPLAN_ALL SET SHOWPLAN_TEXT
SQL Alerter | SQLALRTR.exe
SQL-DMO | sqlole.dll
System Stored Procedures (General Extended Procedures) | xp_snmp_getstate xp_snmp_raisetrap
System Stored Procedures (Replication) | sp_replica sp_replsync sp_helppublicationsync sp_subscribe sp_unsubscribe @@ERROR sp_changepublication sp_addpublisher sp_adddistpublisher sp_droppublisher sp_dropdistpublisher sp_distcounters sp_helpreplicationdb sp_helpreplicationdboption sp_replstatus
System Stored Procedures (System) | ALTER TABLE CREATE TABLE sp_help sp_helpconstraint sp_commonkey sp_dropkey sp_foreignkey sp_helpjoins sp_helpkey sp_primarykey sp_placeobject sp_dbinstall sp_attach_db sp_makestartup sp_unmakestartup sp_procoption sp_helplogins sp_helprotect sp_tableoption sp_serveroption (fallback option) sp_setlangalias sp_droplanguage sp_fallback_activate_svr_db sp_fallback_deactivate_svr_db sp_fallback_enroll_svr_db sp_fallback_help sp_fallback_permanent_svr sp_fallback_upd_dev_drive sp_fallback_withdraw_svr_db sp_devoption sp_diskdefault sp_helplog sp_helpstartup sp_help_revdatabase sp_sqlexec sp_addlanguage
System Stored Procedures (Tasks) | sp_addalert sp_addnotification sp_addoperator sp_dropalert sp_dropnotification sp_dropoperator sp_helpalert sp_helphistory sp_helpnotification sp_helpoperator sp_purgehistory sp_runtask sp_stoptask sp_updatealert sp_updatenotification sp_updateoperator sp_add_alert sp_add_notification sp_add_operator sp_delete_alert sp_delete_notification sp_delete_operator sp_help_alert sp_help_jobhistory sp_help_notification sp_help_operator sp_purge_jobhistory sp_start_job sp_stop_job sp_update_alert sp_update_notification sp_update_operator
System Tables | Information Schema Views System Stored Procedures (Catalog Procedures) sysdevices (mirrorname and stripeset columns) syshistory sysjobhistory sysindexes (distribution, segment, rowpage, keys1, and keys2 columns) syskeys syslocks syslockinfo syslogs sysprocesses (gid and suid columns) sysprocedures syscomments syssegments CREATE DATABASE ALTER DATABASE CREATE TABLE ALTER TABLE CREATE INDEX systasks sysjobs sysjobsteps sysjobservers sysusages master.dbo.spt_datatype_info
Transactions | Data type conversions
Utilities | probe login


Level 2: Handling Major Changes to Behavior

Backward Compatibility Level 2 consists of important changes in Microsoft® SQL Server™ 2000 that produce different behavior from earlier versions of SQL Server. For example, items in this category are those that have changed behavior in data type conversion or usage of selected functions, changed behavior of clauses in selected Transact-SQL statements and stored procedures, changed column names in selected system tables, and changed behavior due to the database compatibility setting. This topic covers backward compatibility details for these items.

This subheading | Relates to
Backup and Restore | BACKUP CREATE DATABASE ALTER DATABASE RESTORE sp_dboption
Bulk Copy | bcp Utility
Configuration Options | Setting Configuration Options sp_configure (open objects and user connections options)
Database Pages and Extents | Pages and Extents
Data Types | CAST and CONVERT Data Types
DB-Library | dbcursorfetchex
Empty Strings | sp_dbcmptlevel CHARINDEX DATALENGTH LEFT LTRIM PATINDEX REPLICATE RIGHT RTRIM SPACE SUBSTRING UPDATETEXT
Indexes | CREATE INDEX
INSERT | sp_dbcmptlevel INSERT
Keyset Cursors | Keyset cursors
LTRIM and RTRIM Trimming Functions | LTRIM RTRIM
ODBC | SQLGetDiagRec SQLMoreResults
RIGHT | Using Identifiers Reserved Keywords
Security | GRANT REVOKE DENY sp_addlinkedsrvlogin
SELECT | SELECT
SET SHOWPLAN | SET SHOWPLAN_ALL SET SHOWPLAN_TEXT
System Tables | Information Schema Views System Stored Procedures (Catalog Procedures) sysdatabases (logptr and dumptrdate columns) sysmessages (langid column) syslogins (language column) computed columns
Table Hints | DELETE FROM INSERT SELECT UPDATE
Transactions | SET TRANSACTION ISOLATION LEVEL SET CURSOR_CLOSE_ON_COMMIT ROLLBACK DECLARE CURSOR
Triggers and System Stored Procedures | sp_dbcmptlevel sp_create_removable CREATE TRIGGER SET QUOTED_IDENTIFIER SET ANSI_NULLS SET ANSI_DEFAULTS
UPDATE | @@ERROR UPDATE INSERT
UPDATETEXT | UPDATETEXT WRITETEXT
Views | DELETE INSERT UPDATE


Level 3: Updating to Improve Earlier Functionality

New Information - SQL Server 2000 SP3.

Backward Compatibility Level 3 consists of items that were supported in SQL Server version 6.5 but are supported in SQL Server 2000 (and SQL Server 7.0) for backward compatibility only. Any item included in this category is fully supported, but may be removed or unsupported in a future release. It is recommended that, as time allows, the backward compatible item be replaced with the recommended item. SQL Server 2000 provides features that accomplish these tasks more efficiently and have ongoing support.

This topic covers backward compatibility details for these items.

This subheading | Relates to
Backup and Restore | BACKUP RESTORE CREATE DATABASE
Database Options | sp_dboption (publish option) sp_replicationdboption
DBCC | DBCC NEWALLOC DBCC CHECKALLOC DBCC ROWLOCK Architecture Enhancements DBCC TEXTALL DBCC CHECKDB DBCC TEXTALLOC DBCC CHECKTABLE DBCC DBREPAIR DROP DATABASE
Devices | Overview of SQL Server Architecture DISK INIT CREATE DATABASE ALTER DATABASE DISK REINIT sp_logdevice sp_dropdevice
Open Data Services | srv_config srv_config_alloc srv_getconfig srv_init srv_run srv_getuserdata srv_setuserdata srv_errhandle srv_iodead srv_log srv_sendstatus srv_sfield srv_event srv_eventdata srv_getserver srv_got_attention srv_handle srv_pre_handle srv_post_handle srv_setevent srv_terminatethread srv_attention srv_connect srv_disconnect srv_language srv_rpc srv_exit srv_start srv_sleep srv_restart srv_stop srv_langcpy srv_langlen srv_langptr srv_paramdata srv_paramlen srv_parammaxlen srv_paramname srv_paramnnumber srv_paramset srv_paramstatus srv_paramtype srv_returnval srv_rpcdb srv_rpcnumber srv_rpcoptions srv_clearstatistics srv_sendstatistics srv_alloc srv_bmove srv_bzero srv.h srv_describe srv_setcollen srv_setcoldata srv_paramsetoutput srv_paraminfo
Query Performance | SUSER_ID SUSER_SID SUSER_NAME SUSER_SNAME syslogins sysdatabases sysremotelogins sysusers sysalternates
Security | GRANT Authentication SETUSER
SELECT | FASTFIRSTROW SELECT INDEX = (index hint)
SET SHOWPLAN | SET SHOWPLAN_TEXT SET SHOWPLAN_ALL SQLGetDiagRec
System Stored Procedures (Extended) | xp_grantlogin xp_revokelogin sp_grantlogin sp_revokelogin
System Stored Procedures (System) | sp_add_job sp_add_jobschedule sp_add_jobstep sp_addtask sp_delete_job sp_delete_jobschedule sp_delete_jobstep sp_droptask sp_help_jobhistory sp_help_jobschedule sp_help_jobstep sp_helptask sp_purge_jobhistory sp_reassigntask sp_start_job sp_stop_job sp_update_job sp_update_jobschedule sp_update_jobstep sp_updatetask


Level 4: Handling Minor Changes to Behavior

Backward Compatibility Level 4 consists of minor changes in Microsoft® SQL Server™ 2000 that produce different behavior from earlier versions of SQL Server. For example, items in this level are either ignored or have one or more ignored parameters, changes to byte lengths, added parameters or columns, or changed data type columns.

This topic covers backward compatibility details for these items.

This subheading | Relates to these items
Aliases | Roles Managing Permissions
Backup and Restore | RESTORE HEADERONLY LOAD HEADERONLY
Configuration | sp_configure (media retention option) Setting Configuration Options
CREATE PROCEDURE | CREATE TABLE SELECT INTO
Data Types | decimal and numeric Using Mathematical Functions + (Add) - (Subtract) * (Multiply) / (Divide) ATN2 AVG CAST and CONVERT EXP POWER RADIANS ROUND SUM
DATEPART and SET DATEFIRST | SET DATEFIRST DATEPART
DBCC | DBCC
DBCS String Comparisons | Unicode space characters
DELETE and SELECT | FROM
Devices | ALTER DATABASE
Functions | @@DBTS
Global Variables | Functions
ODBC | SQL_COPT_SS_PERF_QUERY_INTERVAL SQLMoreResults SQL_NO_DATA
Rebuilding the master Database | Rebuild Master Utility
Rebuilding the Registry (Level 4) | setup/t RegistryRebuild = On
Replication | Replication Between Different Versions of SQL Server Subscribing to One or More Articles of a Publication
Security | SYSTEM_USER
SELECT | SELECT FROM
Triggers and System Stored Procedures (System) | CREATE TRIGGER sp_dboption (recursive triggers option) sp_tableoption xp_readmail xp_sendamil
UPDATE | UPDATE
Utilities | SQL Query Analyzer isql utility


How to Install SQL Server 2000

This set of How To topics includes common procedures used in installing Microsoft® SQL Server™ 2000.


How to install SQL Server 2000 (Setup)

New Information - SQL Server 2000 SP3.

To install SQL Server 2000

  1. Insert the Microsoft® SQL Server™ 2000 compact disc in your CD-ROM drive. If the compact disc does not autorun, double-click Autorun.exe in the root directory of the compact disc.

  2. Select SQL Server 2000 Components.

    If you are running Microsoft Windows® 95, click SQL Server 2000 Prerequisites, and then click Install Common Controls Library Update.

  3. Select Install Database Server and setup prepares the SQL Server Installation Wizard. At the Welcome screen, click Next.

  4. In the Computer Name dialog box, Local Computer is the default option and the local computer name appears in the edit box. Click Next.

    For a remote installation, click Remote Computer. You can then type a computer name or click Browse to locate a remote computer.

    If a cluster is detected, Virtual server is the default option.

  5. In the Installation Selection dialog box, click Create a new instance of SQL Server, or install Client Tools, and then click Next.

  6. Follow directions on the User Information, Software License Agreement and related screens.

  7. In the Installation Definition dialog box, click Server and Client Tools, and then click Next.

  8. In the Instance Name dialog box, if the Default check box is available, you can install either the default or a named instance. If the Default check box is not available, a default instance has already been installed, and you can install only a named instance.
    • To install the default instance, select the Default check box, and click Next.

    • To install a named instance, clear the Default check box, and type a new named instance in the Instance Name edit box. Click Next.
  9. In the Setup Type dialog box, click Typical or Minimum, and then click Next.

    If you want to select components and subcomponents, change character set, network libraries or other settings, click Custom, and then click Next.

  10. In the Service Accounts dialog box, accept the default settings, enter your domain password, and then click Next.

    For information about services account options, see Services Accounts.

  11. In the Authentication Mode dialog box, accept the default setting, and click Next.

    Security Note When possible, use Windows Authentication.

    To use Mixed Mode, see Authentication Modes.

  12. When you are finished specifying options, click Next in the Start Copying Files dialog box.

  13. In the Choose Licensing Mode dialog box, make selections according to your license agreement, and click Continue to begin the installation.

    Click Help for information about licensing or see your system administrator.

  14. In the Setup Complete dialog box, click Yes, I want to restart my computer now, and then click Finish.

See Also

How to add components to an instance of SQL Server 2000 (Setup)

How to create a case-sensitive instance of SQL Server (Setup)

How to install a named instance of SQL Server (Setup)


How to install client tools only (Setup)

You can install client tools only using any SQL Server compact disc, on any supported operating system. For more information, see How to install tools only from any compact disc.

To install client tools only for SQL Server 2000

  1. Insert the Microsoft® SQL Server™ 2000 compact disc in your CD-ROM drive. If the compact disc does not autorun, double-click Autorun.exe in the root directory of the compact disc.

  2. Select SQL Server 2000 Components, select Install Database Server, and then click Next at the Welcome screen of the SQL Server Installation Wizard.

  3. In Computer Name dialog box, Local Computer is the default option, and the local computer name appears in the edit box. Click Next.

  4. In the Installation Selection dialog box, click Create a new instance of SQL Server, or install Client Tools, and then click Next.

  5. Follow the directions on the User Information, Software License Agreement, and related screens.

  6. In the Installation Definition dialog box, click Client tools only, and then click Next.

  7. In the Select Components dialog box, accept the defaults or select the components you want, and then click Next.

    You can select an item in the Components list, such as Management Tools, and then select items from the related Sub-Components list, such as Enterprise Manager. Click to select items you want to install; clear the check box of the items you do not want to install.

    For information about each component, select the item, and view the Description box.

  8. In the Start Copying Files dialog box, click Next to complete the installation of the client tools.


How to install tools only from any compact disc (Setup)

Note In this procedure, you can use the installation disc for any edition of SQL Server 2000 on a computer with any of the operating systems supported by SQL Server 2000.

To install tools only from any compact disc

  1. Insert a Microsoft® SQL Server™ 2000 compact disc in your CD-ROM drive. This can be the installation disc for any edition of SQL Server 2000, without regard to operating system support. If the compact disc does not autorun, double-click Autorun.exe in the root directory of the compact disc.

  2. Select SQL Server 2000 Components, select Install Database Server, and then click Next at the Welcome screen of the SQL Server Installation Wizard.

  3. In Computer Name dialog box, Local Computer is the default option, and the local computer name appears in the edit box. Click Next.

  4. Follow the directions on the User Information, Software License Agreement, and related screens.

  5. In the Select Components dialog box, accept the defaults or select the components you want, and then click Next.

    You can select an item in the Components list, such as Management Tools, and then select items from the related Sub-Components list, such as Enterprise Manager. Click to select items you want to install; clear the check box of the items you do not want to install.

    For information about each component, select the item, and view the Description box.

  6. In the Start Copying Files dialog box, click Next to complete the installation of the client tools.


How to install connectivity only (Setup)

The connectivity-only option installs Network Libraries and MDAC (Microsoft® Data Access Components).

To install connectivity only for SQL Server 2000

  1. Insert the Microsoft SQL Server™ 2000 compact disc in your CD-ROM drive. If the compact disc does not autorun, double-click Autorun.exe in the root directory of the compact disc.

  2. Select SQL Server 2000 Components.

    If you are running Microsoft Windows® 95, click Install Common Controls Library Update.

  3. Select Install Database Server and setup prepares the SQL Server Installation Wizard. At the Welcome screen, click Next.

  4. In the Computer Name dialog box, Local Computer is the default option, and the local computer name appears in the edit box. Click Next.

  5. In the Installation Selection dialog box, click Create a new instance of SQL Server, or install Client Tools, and then click Next.

  6. Follow the directions on the User Information, Software License Agreement and related screens.

  7. In the Installation Definition dialog box, click Connectivity Only, and then click Next.

  8. In the Start Copying Files dialog box, click Next to complete the installation.


How to install a named instance of SQL Server 2000 (Setup)

New Information - SQL Server 2000 SP3.

You can install a named instance of Microsoft® SQL Server™ 2000 the first time you run SQL Server Setup or later after the default instance is installed. For each additional named instance you want to install, follow this procedure.

Note If you have a SQL Server 7.0 installation on your computer, the installation remains intact during the installation of a named instance of SQL Server 2000. A default instance of SQL Server 2000 will overwrite a SQL Server 7.0 installation (as the previous default installation), but a named instance does not overwrite SQL Server 7.0.

To install a named instance of SQL Server 2000

  1. Insert the SQL Server 2000 compact disc in your CD-ROM drive. If the compact disc does not autorun, double-click Autorun.exe in the root directory of the compact disc.

  2. Select SQL Server 2000 Components.

    If you are running Microsoft Windows® 95, Install Common Controls Library Update.

  3. Select Install Database Server and setup prepares the SQL Server Installation Wizard. At the Welcome screen, click Next. In the Computer Name dialog box, Local Computer is the default option, and the local computer name appears in the edit box. Click Next.

  4. In the Installation Selection dialog box, click Create a new instance of SQL Server, or install Client Tools, and then click Next.
    • If this is the first SQL Server 2000 installation on your computer, follow the directions on the User Information, Software License Agreement, and related screens.

    • If an installation of SQL Server 2000 exists on your computer, these screens are omitted.
  5. In the Installation Definition dialog box, click Server and Client Tools, and then click Next.

  6. In the Instance Name dialog box, clear the Default check box, and type a name for the new named instance, and then click Next.

    Note If you have an existing default installation (either SQL Server 7.0 or 2000), the Default check box is not available.

    If you have typed an instance name, and later return to the Instance Name dialog box to change the name before completing setup, you can do so. However, a workaround is necessary to edit the instance name box, which will be unavailable after clicking Back to get to this dialog box. Select the Default checkbox, then immediately clear it, and you will be able to edit the instance name.

    For more information about instance names, click Help.

  7. In the Setup Type dialog box, select Typical, Minimum, or Custom, and then click Next.

    If you want to select subcomponents or change character set, network libraries, or other settings, click Custom.

  8. In the Service Accounts dialog box, accept the default settings, enter your domain password, and then click Next.

    For information about services account options, see Services Accounts.

  9. In the Authentication Mode dialog box, accept the default setting, and click Next.

    Security Note When possible, use Windows Authentication.

    To use Mixed Mode authentication, see Authentication Modes.

  10. When you are finished specifying options, click Next in the Start Copying Files dialog box.

  11. In the Choose Licensing Mode dialog box, make selections according to your license agreement, and click Continue to begin the installation.

    Click Help for information about licensing, or see your system administrator.

  12. In the Setup Complete dialog box, click Yes, I want to restart my computer now, and then click Finish.

See Also

Working with Named and Multiple Instances of SQL Server 2000

Running SQL Server 7.0 Along with a Named Instance of SQL Server 2000


How to upgrade a SQL Server 7.0 installation to SQL Server 2000 (Setup)

Caution This version upgrade procedure overwrites your Microsoft® SQL Server™ 7.0 installation; the installation no longer exists on your computer. In addition, previous registry settings are removed. For example, after upgrading you will need to re-register your servers.

To restore the SQL Server 7.0 installation, you must first uninstall SQL Server 2000, perform a complete reinstall of the SQL Server 7.0 files, and then restore your backed-up SQL Server 7.0 databases.

To upgrade SQL Server 7.0 to SQL Server 2000

  1. Insert the Microsoft SQL Server 2000 compact disc for the edition to which you want to upgrade into your CD-ROM drive. If the compact disc does not autorun, double-click Autorun.exe in the root directory of the compact disc.

    Note If you have purchased an edition of SQL Server with more features than your current SQL Server 7.0 installation, the upgrade process will perform both the version and edition upgrade at the same time.

  2. Select SQL Server 2000 Components, select Install Database Server, and then setup prepares the SQL Server Installation Wizard. At the Welcome screen, click Next.

  3. In Computer Name dialog box, Local Computer is the default option and the local computer name appears in the edit box. Click Next.

  4. In the Installation Selection dialog box, click Upgrade, remove, or add components to an existing instance of SQL Server, and then click Next.

  5. In the Instance Name dialog box, Default will be selected. Click Next.

    Note When upgrading, SQL Server 7.0 automatically becomes the default instance of SQL Server 2000.

  6. In the Existing Installation dialog box, click Upgrade your existing installation, and then click Next.

  7. In the Upgrade dialog box, you are prompted as to whether you want to proceed with the requested upgrade. Click Yes, upgrade my <text specific to the upgrade> to start the upgrade process, and then click Next. The upgrade runs until finished.

  8. In the Connect to Server dialog box, select an authentication mode, and then click Next.

    If you are not sure which mode to use, accept the default: The Windows account information I use to log on to my computer with (Windows).

  9. In Start Copying Files dialog box, click Next.

  10. In the Setup Complete dialog box, click Yes, I want to restart my computer now, and then click Finish.

See Also

Authentication Modes

How to perform an edition upgrade within SQL Server 2000 (Setup)


How to upgrade databases online using the Copy Database Wizard (Enterprise Manager)

To upgrade a SQL Server 7.0 database to a SQL Server 2000 database

  1. Expand a server group, and then expand a server.

  2. Right-click the server, point to All Tasks, and then click Copy Database Wizard.

  3. Complete the steps in the wizard.

Important After upgrading databases from SQL Server 7.0, run sp_updatestats (update statistics) against the database on the destination server to ensure optimal performance of the copied database.

See Also

Copy Database Wizard Help

Database Upgrade from SQL Server 7.0 (Copy Database Wizard)


How to perform an edition upgrade within SQL Server 2000 (Setup)

To upgrade a SQL Server 2000 installation to a different edition of SQL Server 2000

  1. Insert the Microsoft® SQL Server 2000™ compact disc for the edition you want to install into your CD-ROM drive. If the compact disc does not autorun, double-click Autorun.exe in the root directory of the compact disc.

  2. Select SQL Server 2000 Components, select Install Database Server, and then setup prepares the SQL Server Installation Wizard. At the Welcome screen, click Next.

  3. In Computer Name dialog box, select Local Computer or Remote computer.

  4. In the Installation Selection dialog box, click Upgrade, Remove, or Add Components to an existing instance of SQL Server, and then click Next.

  5. In the Instance Name dialog box, click Next.

  6. In the Existing Installation dialog box, click Upgrade your existing installation, and then click Next.

  7. If Setup detects that you are doing an edition upgrade, the Upgrade dialog box appears. Click Yes, Upgrade my <text specific to the upgrade> to upgrade the feature set of your current installation, and click Next.

  8. After the upgrade is completed, you are prompted as to whether you want to install additional components. If you click Yes, the Select Components dialog box appears. Accept the defaults or select the additional components you want to install, and then click Next.

    You can select an item in the Components list, and then select items from the related Sub-Components list. Click to select items you want to install; clear the check box of the items you do not want to install.

  9. When you are finished specifying options, in the Start Copying Files dialog box, click Next.

  10. In the Setup Complete dialog box, click Yes, I want to restart my computer now, and then click Finish to complete the edition upgrade.

See Also

Upgrading an Existing Installation of SQL Server


How to uninstall an existing installation of SQL Server (Setup)

To uninstall an existing installation of SQL Server 7.0 or SQL Server 2000 (default or named instance)

  1. Insert the Microsoft® SQL Server™ 2000 compact disc in your CD-ROM drive. If the compact disc does not autorun, double-click Autorun.exe in the root directory of the compact disc.

  2. Select SQL Server 2000 Components, select Install Database Server, and then setup prepares the SQL Server Installation Wizard. At the Welcome screen, click Next.

  3. In Computer Name dialog box, select Local Computer or Remote computer.

  4. In the Installation Selection dialog box, click Upgrade, Remove, or Add Components to an existing instance of SQL Server, and then click Next.

  5. In the Instance Name dialog box, Default is selected if you have the Default instance installed. If you want to uninstall a named instance, select it from the Instance Name list box, and then click Next.

  6. In the Existing Installation dialog box, click Uninstall your existing installation, and then click Next.

  7. Setup removes the selected installation. In the Uninstalling dialog box, click Next, and then in the Setup Complete dialog box, click Finish.


How to test an installation of SQL Server 2000 (Command Prompt)

To test the installation

  1. Start Microsoft® SQL Server™ 2000 by entering from a command prompt:

    For the default instance, use:

    net start mssqlserver

    For a named instance, include the instance name, for example:

    net start MSSQL$Instance1
  2. Connect to SQL Server by entering:

    For the default instance, use:

    osql /Usa /P [sapassword]

    For a named instance, include both the server and instance name, for example:

    osql /Usa /P [sapassword] /S Machine1\Instance1

    When osql connects, this osql prompt appears:

    1>

    If osql cannot connect, an ODBC error is returned.

  3. Enter a simple query, such as:
    SELECT @@SERVERNAME
GO

    The osql utility returns the server name:

    1> SELECT @@SERVERNAME
2> GO
-------------------------------
WOLFHOUND

(1 row affected)
1>
  4. Verify that you have checked a SQL Server 2000 server by entering:
    SELECT @@VERSION
GO

    The osql utility returns the version information.

  5. Quit the osql utility by entering:
    Exit


How to change SQL Server services login account information (Windows NT)

To change SQL Server services login account information (Windows NT)

  1. On the Start menu, point to Settings, and then click Control Panel.

  2. Double-click Services.

  3. In the Services dialog box, double-click MSSQLSERVER in the Service list.

    Note For named instances, the instance name is included. For example, to modify the user account for Instance1, you double-click MSSQL$Instance1.

  4. In the Service dialog box, under Log on as, select This account, and then enter the changed account information.

  5. Repeat Steps 3 and 4 above for SQL Server Agent. In the Services dialog box, double-click SQLSERVERAGENT (or SQLAgent$Instance1 for a named instance), and then enter the changed account information in the Service dialog box.

  6. Start SQL Server Enterprise Manager, and change the user account information there, as well, for both SQL Server and SQL Server Agent For more information see How to change SQL Server services login account information (Enterprise Manager).


How to change SQL Server services login account information (Windows)

To change SQL Server services login account information (Windows 2000)

  1. On the Start menu, point to Programs/Administrative Tools, and then click Services.

  2. Right-click MSSQLServer, and then click Properties.

  3. On the Log On tab, enter and confirm the new password, and then restart services using the SQL Server Service Manager.

  4. Repeat the password reset for SQLServerAgent and other services.

  5. Start SQL Server Enterprise Manager, and change user account information there, as well, for both SQL Server and SQL Server Agent For more information, see How to change SQL Server services login account information (Enterprise Manager).


How to change SQL Server services login account information (Enterprise Manager)

Note If you are running Microsoft® Windows® 2000 and want to use the Windows 2000 Encrypted File System to encrypt any Microsoft SQL Server™ files, you must unencrypt the files before you can change the SQL Server service accounts. If you do not unencrypt the files and then reset the SQL Server service accounts, you cannot unencrypt the files.

To change the MSSQLServer service login (Enterprise Manager)

  1. Expand a server group.

  2. Right-click a server, and then click Properties.

  3. In the SQL Server Properties dialog box, click the Security tab.

  4. In the Startup service account box, the option for This Account is selected, indicating that the SQL Server service account is a Windows domain account. Enter changes as necessary for the account and password.

To change the SQLServerAgent service login (Enterprise Manager)

Note You can change the SQLServerAgent service account to a non Microsoft Windows NT® 4.0 administrator account. However, the Windows NT 4.0 account must be a member of the sysadmin fixed server role to run SQL Server Agent.

  1. Expand a server group, and then expand a server.

  2. Expand Management.

  3. Right-click SQL Server Agent, and then click Properties.

  4. In the SQL Server Agent Properties dialog box, click the General tab.

  5. In the Service startup account box, enter the appropriate account and password.

See Also

Creating SQL Server Services User Accounts

Changing Passwords and User Accounts


How to rebuild the registry (Setup)

To rebuild the registry

  1. Insert the Microsoft® SQL Server™ 2000 compact disc in your CD-ROM drive. If the compact disc does not autorun, double-click Autorun.exe in the root directory of the compact disc.

  2. Select SQL Server 2000 Components, select Install Database Server, and then click Next at the Welcome screen of the SQL Server Installation Wizard.

  3. In the Computer Name dialog box, click Next.

  4. In the Installation Selection dialog box, click Advanced options, and then in the Advanced Options dialog box, click Registry Rebuild. Click Next.

  5. A message appears informing you that Setup rebuilds the registry based on information you supply in the subsequent screens.

    Caution The setup options you enter must be the same choices that you entered during the initial installation. If you do not know or are not sure of this information, do not use this registry rebuild process. Instead, you must uninstall and reinstall SQL Server to restore the registry.

  6. To prepare for the registry rebuild, enter the same information and options that you entered during the initial installation of SQL Server in the setup screens as they appear. When you have finished, the registry rebuild will occur.

    Note Rebuilding the registry includes re-copying external components such as MDAC and MS DTC.


How to rebuild the master database (Rebuild Master utility)

To rebuild the master database

  1. Shutdown Microsoft® SQL Server™ 2000, and then run Rebuildm.exe. This is located in the Program Files\Microsoft SQL Server\80\Tools\Binn directory.

  2. In the Rebuild Master dialog box, click Browse.

  3. In the Browse for Folder dialog box, select the \Data folder on the SQL Server 2000 compact disc or in the shared network directory from which SQL Server 2000 was installed, and then click OK.

  4. Click Settings. In the Collation Settings dialog box, verify or change settings used for the master database and all other databases.

    Initially, the default collation settings are shown, but these may not match the collation selected during setup. You can select the same settings used during setup or select new collation settings. When done, click OK.

  5. In the Rebuild Master dialog box, click Rebuild to start the process.

    The Rebuild Master utility reinstalls the master database.

    Note To continue, you may need to stop a server that is running.

See Also

Collation Settings in Setup


How to perform a remote installation of SQL Server 2000 (Setup)

To perform a remote installation

  1. Insert the Microsoft® SQL Server™ 2000 compact disc in your CD-ROM drive. If the compact disc does not autorun, double-click Autorun.exe in the root directory of the compact disc.

  2. Select SQL Server 2000 Components, select Install Database Server, and then click Next at the Welcome screen of the SQL Server Installation Wizard.

  3. In Computer Name dialog box, click Remote Computer. You can then type a computer name or click Browse to locate a remote computer.

  4. In the Installation Selection dialog box, click Create a new instance of SQL Server, or install Client Tools.

  5. Follow the directions on the User Information, Software License Agreement, and related screens.

  6. In the Remote Setup Information dialog box, enter password and other information. For more information, see Remote Setup Information. After you finish defining options, click Next.

  7. In the Installation Definition, Instance Name, Setup Type, and subsequent setup screens, select the options you want for the remote installation.

    SQL Server Setup creates the Setup.iss file in your local system folder with the options you have specified.

  8. After Setup creates Setup.iss, the Setup Complete dialog box appears. Click Finish to start the remote installation process.

  9. When the process is finished, click OK in the message box that appears. Reboot the remote computer before running the remote instance.


How to record an unattended installation file (Setup)

The Record Unattended Setup option allows you to simulate an installation and create an .iss file that can be used later for an unattended installation of Microsoft® SQL Server™ 2000. SQL Server files are not installed in this process.

To create a file for an unattended installation

  1. Insert the Microsoft SQL Server 2000 compact disc in your CD-ROM drive. If the compact disc does not autorun, double-click Autorun.exe in the root directory of the compact disc.

  2. Select SQL Server 2000 Components, select Install Database Server, and then click Next at the Welcome screen of the SQL Server Installation Wizard.

  3. In the Computer Name dialog box, select the option you want, and click Next.

  4. In the Installation Selection dialog box, click Advanced options, and then in the Advanced Options dialog box, click Record Unattended .ISS file. Click Next.

  5. In subsequent Setup screens, select the options you want for the unattended installation. After you finish selecting the options, in the Setup Information screen, click Next.

  6. In the Setup Complete screen, click Finish.

    This message appears: "Setup has collected the information needed to create an unattended installation file (.iss) for use with later unattended installations of SQL Server."

    SQL Server Setup then creates the Setup.iss file in the %windir% location with the options you have specified.

    To run the file, see How to run an unattended installation of SQL Server 2000 (Command Prompt).

See Also

Performing an Unattended Installation


How to run an unattended installation of SQL Server 2000 (Command Prompt)

You can run an unattended installation by using sample batch files and setup initialization files included on the Microsoft® SQL Server™ 2000 compact disc. Or, you can run the Setup program directly from the command prompt in the appropriate directory for the edition of SQL Server you want to install, using arguments as needed.

To run an unattended installation using ready-made batch files

  1. Locate the .bat and .iss files in the root directory of your SQL Server 2000 compact disc.

  2. View the .bat and associated .iss files, and modify if necessary. For more information, see Creating a Specialized Setup File.

  3. Run the appropriate batch and setup files from the command prompt:
    • For a standard unattended installation, run Sqlins.bat.

    • For a client-only unattended installation, run Sqlcli.bat.

    • For a custom unattended installation, run Sqlcst.bat.

To run an unattended installation directly from the command prompt

  1. Run Setupsql.exe from the Setup directory in the appropriate architecture directory.

  2. Use arguments as needed:
-f1 <initialization file path>
Selects an unattended setup initialization file.
start /wait command (with the -SMS option)
Returns control to the command prompt only after SQL Server Setup completes.
-s flag
Causes the Setup program to run in silent mode with no user interface.

For examples of command prompt options and arguments, see the sample .bat files on your SQL Server 2000 compact disc.

See Also

Performing an Unattended Installation

How to record an unattended installation file (Setup)


How to add components to an instance of SQL Server 2000 (Setup)

Note You cannot remove components by clearing checkboxes in the Select Components dialog box. If you need to remove components from an instance of SQL Server, you must uninstall the instance.

To add components to an instance (default or named) of SQL Server 2000

  1. Run SQL Server Setup, select SQL Server 2000 Components, select Install Database Server, and then click Next at the Welcome screen of the SQL Server Installation Wizard.

  2. In Computer Name dialog box, Local Computer is the default option and the local computer name appears in the edit box. Click Next.

  3. In the Installation Selection dialog box, click Upgrade, Remove, or Add Components to an existing instance of SQL Server, and then click Next.

  4. In the Instance Name dialog box, Default is selected if you have the Default instance installed. If you want to add components to a named instance, select it from the Instance Name list, and then click Next.

  5. In the Existing Installation dialog box, click Add Components to your existing installation, and then click Next.

  6. In the Select Components dialog box, select a component from the Components list, and then select items from the related Sub-Components list. Click to select items you want to add, and then click Next.

    For information about each component, select the item, and view the Description box.

  7. When you are finished specifying options, click Next in the Start Copying Files dialog box to add components to the selected instance of SQL Server.

See Also

How to uninstall an existing installation of SQL Server (Setup)


How to access SQL Server Books Online for SQL Server 7.0

If you have Microsoft® SQL Server™ 7.0 running as the default instance (and SQL Server 2000 as a named instance), SQL Server Books Online for SQL Server 7.0 remains intact on your computer. You can access SQL Server Books Online from the Start menu or create a shortcut to it on your desktop.

To access SQL Server Books Online for SQL Server 7.0 from the Start menu

  • On the Start menu, point to Programs and Microsoft SQL Server 7.0, and then click Books Online.

To create a shortcut to SQL Server Books Online for SQL Server 7.0

  1. Locate Sqlbol.chm on your computer. (The default location is C:\Mssql7\Books.)

  2. Right-click Sqlbol.chm, and then click Create Shortcut.

  3. Copy the shortcut to your desktop, where you can use it to access SQL Server Books Online.

To install SQL Server Books Online for SQL Server 7.0 for the first time, or to reinstall it, you must install it from the SQL Server 7.0 compact disc or the SQL Server Web site.

To reinstall SQL Server Books Online for SQL Server 7.0 from the SQL Server 7.0 compact disc

  1. Insert the Microsoft SQL Server 7.0 compact disc in your CD-ROM drive.

  2. Locate the file Sqlbol.chm on the compact disc, and copy it to a location on your computer.

  3. Create a shortcut on your desktop to SQL Server Books Online for SQL Server 7.0.

To download SQL Server Books Online for SQL Server 7.0 from the SQL Server Web site

  1. Go to the Microsoft SQL Server Web site, at Microsoft Web site.

  2. On the SQL Server Welcome page, click Support.

  3. On the Support page, click Documentation and follow instructions to access SQL Server 7.0 Books Online.


How to install English Query (Setup)

To install English Query

  1. Insert the Microsoft® SQL Server™ 2000 compact disc in your CD-ROM drive. If the compact disc does not autorun, double-click Autorun.exe in the root directory of the compact disc.

  2. Select SQL Server 2000 Components.

  3. On the Install Components screen, select Install English Query.

    No further selections are necessary. SQL Server Setup installs English Query on your computer.


How to install Analysis Services (Setup)

The following procedure is a shortened version of the steps to install Analysis Services. For a more complete installation procedure and for related information, see Running Setup.

To install Analysis Services

  1. Insert the Microsoft® SQL Server™ 2000 compact disc in your CD-ROM drive. If the compact disc does not autorun, double-click Autorun.exe in the root directory of the compact disc.

  2. Select SQL Server 2000 Components.

  3. On the Install Components screen, select Install Analysis Services.

  4. At the Welcome screen for Microsoft SQL Server 2000 Analysis Services, click Next.

  5. Follow the directions on the User Information, Software License Agreement, and related screens.

  6. In the Select Components dialog box, select or clear components as needed, and then click Next.

    If you want to change the default location of the Analysis Services program files, click Browse at Destination Folder and select a folder location.

  7. In the Data Folder Location dialog box, accept or change the default location for data files, and then click Next.

  8. In the Select Program Folder dialog box, accept or change the default settings, and then click Next.

SQL Server Setup installs Analysis Services on your computer.


How to create a case-sensitive instance of SQL Server 2000 (Setup)

New Information - SQL Server 2000 SP3.

To create a case-sensitive instance of SQL Server 2000

  1. Run SQL Server Setup to install SQL Server 2000 Components, select Install Database Server, and then click Next at the Welcome screen of the SQL Server Installation Wizard.

  2. In Computer Name dialog box, Local Computer is the default option and the local computer name appears in the edit box. Click Next.

  3. In the Installation Selection dialog box, click click Create a new instance of SQL Server, or install Client Tools, and then click Next.

  4. Follow the directions on the User Information and related screens.

  5. In the Installation Definition dialog box, click Server and Client Tools, and then click Next.

  6. In the Instance Name dialog box:
    • To create a case-sensitive default instance, accept the Default check box and click Next.

    • To create a case-sensitive named instance, clear the Default check box and type an instance name.
  7. In the Setup Type dialog box, click Custom, and click Next.

  8. In the Select Components, Services Accounts, and Authentication Mode dialog boxes, change or accept the default settings, and then click Next.

    Security Note When possible, use Windows Authentication.

  9. In the Collation Settings dialog box, you have two options:
    • To make a Windows Locale collation case-sensitive, select Collation designator and then select the correct collation designator from the list. Clear the Binary check box, and then select the Case-sensitive check box.

    • To make a SQL collation case-sensitive, select SQL Collations, and then select the correct collation name.

    For more information about collation options, click Help. When you finish setting the options, click Next.

  10. In subsequent dialog boxes, change or accept the default settings, and then click Next.

  11. When you are finished specifying options, click Next in the Start Copying Files dialog box.

  12. In the Choose Licensing Mode dialog box, make selections according to your license agreement, and click Continue to begin the installation.

  13. Click Help for information about licensing, or see your system administrator.

See Also

Collation Settings in Setup


How to set client code pages

To set client code pages under the Windows NT, Windows 98, or Windows 2000 operating systems

  • Use the Regional Settings application in Control Panel as described in the Microsoft® Windows NT®, Microsoft Windows® 98, or Microsoft Windows 2000 documentation.


How to switch from SQL Server 6.5 to SQL Server 2000 (Command Prompt)

To switch from SQL Server 6.5 to SQL Server 2000

  • Run Vswitch.exe.
-SwitchTo <65|80>
Determines which version of Microsoft® SQL Server™ 2000 to activate.
-Silent <0|1>
Determines if any user interface or messages are displayed. If 1 is specified, a user interface or messages are not displayed. The default is 0.
Examples
c:\...\vswitch -SwitchTo 80 -Silent 1


How to switch from SQL Server 6.5 to SQL Server 2000 (Windows)

To switch from SQL Server 6.5 to SQL Server 2000

  • On the Start menu, point to Programs/Microsoft SQL Server-Switch, and then click Microsoft SQL Server 2000.

    SQL Server Setup switches from Microsoft® SQL Server™ 2000 version 6.5 to SQL Server 2000.


How to remove SQL Server 2000 (Windows)

You can remove instances of Microsoft® SQL Server™ 2000 using Control Panel. Each named instance must be removed separately. When upgrading or maintaining instances, you can remove SQL Server using the Uninstall option in Setup. For more information, see How to uninstall an existing installation (Setup).

You cannot remove a selected component of SQL Server 2000 after it is installed. To remove components, you must remove the entire instance.

To remove a named instance of SQL Server 2000

  1. In Control Panel, click Add/Remove programs.

  2. Select a name of an instance of SQL Server 2000, and click Remove.

To remove all instances of SQL Server 2000

  1. In Control Panel, click Add/Remove programs.

  2. Repeat the removal process for each instance of SQL Server 2000 that is installed.

SQL Server 2000 is uninstalled, but some files may remain. Manually delete directories if any files related to SQL Server 2000 still exist.

See Also

Directories and File Locations


How To Upgrade from SQL Server 6.5

The How To topics in this section are specific to the process of converting data from Microsoft® SQL Server™ 6.5 to Microsoft SQL Server 2000 using the SQL Server Upgrade Wizard.

Note To run the SQL Server Upgrade Wizard, you must have an instance of Microsoft SQL Server 2000 already installed on your computer.

Considerations when upgrading from SQL Server 6.5:
  • During the upgrade process, the SQL Server 6.5 server is stopped and started while objects are scripted and data is extracted. When the data transfer starts, only SQL Server 2000 is running, and it is not possible to access SQL Server 6.5.

  • If you are upgrading your existing SQL Server 6.5 server to a different computer that is running SQL Server 2000, both computers should be configured to use a domain user name and password for the MSSQLServer service.

  • During this upgrade, user-defined messages created in SQL Server 6.5 using sp_addmessage are not converted to SQL Server 2000. To retain these custom messages, manually copy the messages added in SQL Server 6.5 to your installation of SQL Server 2000.

See Also

Troubleshooting the SQL Server Upgrade Wizard

Completing the SQL Server Upgrade Wizard

Upgrade Log Files

Upgrading to SQL Server 2000 FAQ


How to change the size of tempdb in SQL Server 6.5 (ISQL/w)

To change the size of tempdb in SQL Server 6.5

  1. On the Start menu, point to Programs/Microsoft SQL Server 6.5, and then click ISQL/w.

  2. Enter the sa password, and then click Connect.

  3. Execute a DISK INIT command to increase the size of the tempdb device to at least 25 MB.

  4. Execute an ALTER DATABASE command to increase the size of the tempdb database to at least 25 MB.
Examples
--Increase the size of the tempdb device
DISK INIT name = 'tempdb1',physname = 'c:\mssql\data\tempdb1.DAT',vdevno = 100, size = 12800
GO
--Increase the size of tempdb
ALTER DATABASE tempdb ON tempdb1 = 25


How to change to the current server name in the SQL Server 6.5 master database (ISQL/w)

To change to the current server name in the SQL Server 6.5 master database

  1. Start Microsoft® SQL Server™ in minimal configuration mode. In a command prompt window, from the \Mssql\Binn directory, run:
    sqlservr -f
  2. On the Start menu, point to Programs /Microsoft SQL Server 6.5, and then click ISQL/w.

  3. Enter the sa password, and then click Connect.

  4. Execute SELECT @@SERVERNAME to retrieve the former server name.

  5. Execute sp_dropserver to drop the former server.

  6. Execute sp_addserver to add the current server.

  7. Stop SQL Server. In the command prompt window, press Ctrl+C.

  8. Restart SQL Server.

  9. Execute SELECT @@SERVERNAME to verify the current server name.
Examples
--Start SQL Server in minimal configuration mode.
--Retrieve the former server name.
SELECT @@SERVERNAME
--Drop the server returned from the previous select.
sp_dropserver 'SERVER6X'
--Add the current server.
sp_addserver 'SERVER70', local
--Stop SQL Server.
--Restart SQL Server in minimal configuration mode.
--Verify the current server name.
SELECT @@SERVERNAME


How to update the device file locations in the SQL Server 6.5 master database (ISQL/w)

To update the device file locations in the SQL Server 6.5 master database

  1. On the Start menu, point to Programs/Microsoft SQL Server 6.5, and then click ISQL/w.

  2. Enter the sa password, and then click Connect.

  3. Select from sysdevices in the master database to view the old device file locations.

  4. Execute sp_configure to allow updates to the system tables, and then reconfigure with override.

  5. Update the device file locations that have changed.

  6. Execute sp_configure to disallow updates to the system tables, and then reconfigure with override.
Examples
--View the old device file locations
SELECT phyname FROM sysdevices

--Allow updates to the system tables
sp_configure 'allow updates',1
GO
RECONFIGURE WITH OVERRIDE
GO
--Update device file locations that have changed
UPDATE sysdevices
SET phyname = "E:\Data\HR\HR1.dat"
WHERE name = "HumanResources1"
GO
UPDATE sysdevices
SET phyname = "E:\Data\HR\HR1Log.dat"
WHERE name = "HumanResources1Log"
GO
--Disallow updates to the system tables
sp_configure 'allow updates',0
GO
RECONFIGURE WITH OVERRIDE
GO


How to estimate the disk space required for an upgrade from SQL Server version 6.5 to SQL Server 2000 (SQL Server Upgrade Wizard)

Note To run the SQL Server Upgrade Wizard, you must have an instance of Microsoft® SQL Server™ 2000 already installed on your computer.

To estimate the disk space required for an upgrade

  1. On the Start menu, point to Programs/Microsoft SQL Server-Switch, click SQL Server Upgrade Wizard, and then click Next.

  2. Select Named pipe; then click Next.

  3. In Export server (6.5), in the Server name box, enter the name of the local or remote computer on which SQL Server 6.5 resides.

  4. In the Administrator password ('sa') box, enter the sa password for SQL Server 6.5, and then click Next.

    Unless you have changed it already, the default system administrator password for SQL Server 2000 is blank. Although the SQL Server 2000 default for the sa password is blank, to conform with best security practices, it should be changed to a strong password at the first opportunity.

  5. Include the databases to upgrade. Move any database not to include in the disk space estimation to the Exclude list, and then click Next.

  6. Select Use the default configuration or edit the default; then click Edit.

    The SQL Server Upgrade Wizard layout utility appears, showing the proposed layout of the SQL Server 2000 data files.

  7. Click Advanced.

  8. Click an object in the Proposed database layout box to view details in the Object details box.

  9. The Drive summary box shows the estimated size of all SQL Server 2000 data files and the free disk space left on all of the local fixed disks. On the Options menu, select Freespace includes 6.5 files to view the free space that would exist if the SQL Server 6.5 data files were deleted.

  10. Click Accept to return to the Database Creation dialog box.

  11. Click Cancel to quit the SQL Server Upgrade Wizard.


How to edit the default database configuration (SQL Server Upgrade Wizard)

Note To run the SQL Server Upgrade Wizard, you must have an instance of Microsoft® SQL Server™ 2000 already installed on your computer.

To edit the default database configuration

  1. In the Database Creation dialog box of the SQL Server Upgrade Wizard, click Edit.

  2. Click Advanced to view object details and drive summaries.

  3. In the Proposed database layout box, double-click a database file.

  4. Change any database file attributes, and then click OK.

  5. View the changes to the drive summary.

  6. When all changes have been made, click Accept to save the database configuration.

See Also

Proposed Database Layout


How to perform a SQL Server version 6.5 to SQL Server 2000 upgrade using a direct pipeline (SQL Server Upgrade Wizard)

Note To run the SQL Server Upgrade Wizard, you must have an instance of Microsoft® SQL Server™ 2000 already installed on your computer.

To perform a SQL Server version 6.5 to SQL Server 2000 upgrade by named pipe

  1. On the Start menu, point to Programs/Microsoft SQL Server-Switch, click SQL Server Upgrade Wizard, and then click Next.

  2. In the Data and Object Transfer screen, accept the default selections, including Named pipe, and then click Next. Verification options are recommended, but not required. Click Help for information.

  3. On the Logon screen, in the Server name box in the Export server (6.5) group box, enter the name of the local or remote computer on which Microsoft SQL Server version 6.5 is installed.

    In the Administrator password ('sa') box, enter the sa password for SQL Server 6.5, and then click Next.

    Unless you have changed it already, the default system administrator password for SQL Server 2000 is blank. Although the SQL Server 2000 default for the sa password is blank, to conform with best security practices, it should be changed to a strong password at the first opportunity.

    For Import Server (2000), the server name is filled in. Enter the optional startup arguments, if you want. Click Help for information. When you are finished setting options, click Next.

  4. In the message box asking if you want to continue, click Yes if you are ready to upgrade. The SQL Server Upgrade Wizard shuts down SQL Server 6.5 and starts SQL Server 2000.

  5. In the Code Page Selection screen, accept or change the default settings, and then click Next.

  6. In the Database Selection screen, include the databases to upgrade. Move any databases you do not want upgraded at this time to the Exclude list, and then click Next.

    Converting all databases is recommended.

  7. In the Database Creation dialog box, select Use the default configuration or edit the default, and then click Next.

    Click Edit to examine and make changes to the proposed disk configuration within the layout utility. In the Proposed Database Layout box, make changes as needed. Click Advanced to view Object Details and Drive Summary. When you are finished, click Accept to return to the SQL Server Upgrade Wizard.

  8. In the System Configuration screen, in System objects to transfer, select the object types to transfer from SQL Server 6.5 to SQL Server 2000:
    • Server configuration

      Login and remote login registrations and server configuration options relevant to SQL Server 2000 are transferred as part of the version upgrade.

    • Replication settings

      All articles, subscriptions and publications of each selected database, plus the distribution database, if any, are transferred and upgraded.

    • SQL Executive settings

      All tasks scheduled by SQL Executive are transferred and upgraded so that SQL Server 2000 can schedule and run those tasks in SQL Server Agent.

  9. In the System Configuration screen, in Advanced settings, for ANSI Nulls, select:
    • Off, if ANSI nulls should not be used when stored procedures are created. This is the default.

    • On, if ANSI nulls should be used when stored procedures are created.
  10. In Quoted identifiers, select one of these options, and then click Next:
    • Mixed (or don't know), if some of your objects were created with QUOTED_IDENTIFIER set to ON and others with it set to OFF, or if you are not sure how they were created.

    • Off, if all objects should be compiled with QUOTED_IDENTIFIER set to OFF.

    • On, if all objects should be compiled with QUOTED_IDENTIFIER set to ON.
  11. In the Completing the SQL Server Wizard screen, view the summary of choices you have made. Click View warnings and choices in notepad to open a text version of the upgrade script. If all options are correct, click Finish.

The SQL Server Upgrade Script Interpreter screen appears, with information on the progress of the upgrade.

See Also

Order of Upgrade Using a Direct Pipeline or Tape Drive


How to perform a SQL Server version 6.5 to SQL Server 2000 upgrade using a tape drive (SQL Server Upgrade Wizard)

Note To run the SQL Server Upgrade Wizard, you must have an instance of Microsoft® SQL Server™ 2000 already installed on your computer.

To perform a SQL Server version 6.5 to SQL Server 2000 upgrade using a tape drive

  1. On the Start menu, point to Programs/Microsoft SQL Server-Switch, click SQL Server Upgrade Wizard, and then click Next.

  2. In the Data and Object Transfer screen, click Tape, and then click Next. Verification options are recommended, but not required. Click Help for information.

  3. On the Logon screen, in the Server name box in the Export server (6.5) group box, enter the name of the computer on which Microsoft SQL Server version 6.5 is installed.

    In the Administrator password ('sa') box, enter the sa password for SQL Server 6.5, and then click Next.

    Unless you have changed it already, the default system administrator password for SQL Server 2000 is blank. Although the SQL Server 2000 default for the sa password is blank, to conform with best security practices, it should be changed to a strong password at the first opportunity.

    For Import Server (2000), the server name is filled in. Enter optional startup arguments, if you want. Click Help for information. When you are finished setting options, click Next.

  4. In the message box asking if you want to continue, click Yes if you are ready to upgrade. The SQL Server Upgrade Wizard switches to the SQL Server 2000 server.

  5. In the Code Page Selection screen, accept or change the default settings, and then click Next.

  6. In the Database Selection screen, include the databases to upgrade. Move any database not to be upgraded at this time to the Exclude list, and then click Next.

  7. In Device for data transfer, specify the location of the tape drive.

  8. In 6.5 device backup options, select Backup 6.5 devices before exporting data if you have not backed up the databases already.

    Prior to creating the SQL Server 2000 databases, the SQL Server Upgrade Wizard either prompts you to back up the SQL Server 6.5 devices or copies the devices for you automatically.

  9. Select Delete 6.5 devices before importing data if necessary due to lack of disk space, and then click Next.

    After objects and data are exported, and before creating databases in SQL Server 2000, the SQL Server Upgrade Wizard deletes the SQL Server 6.5 devices to reclaim disk space.

  10. Select Use the default configuration or edit the default, and then click Next.

    Click Edit to examine and make changes to the proposed disk configuration within the layout utility. In the Proposed Database Layout box, make changes as needed. Click Advanced to view Object Details and Drive Summary. When you are finished, click Accept to return to the SQL Server Upgrade Wizard.

  11. In System objects to transfer, select the object types to transfer from SQL Server 6.5 to SQL Server 2000:
    • Server configuration

      Login and remote login registrations and server configuration options relevant to SQL Server 2000 are transferred as part of the version upgrade.

    • Replication settings

      All articles, subscriptions, and publications of each selected database, plus the distribution database, if any, are transferred and upgraded.

    • SQL Executive settings

      All tasks scheduled by SQL Executive are transferred and upgraded so that SQL Server 2000 can schedule and run those tasks in SQL Server Agent.

  12. In ANSI Nulls, select:
    • Off, if ANSI nulls should not be used when stored procedures are created. This is the default.

    • On, if ANSI nulls should be used when stored procedures are created.
  13. In Quoted Identifiers, select one of these options, and then click Next:
    • Mixed (or don't know), if some of your objects were created with QUOTED_IDENTIFIER set to ON and others with it set to OFF, or if you are not sure how they were created.

    • Off, if all objects should be compiled with QUOTED_IDENTIFIER set to OFF.

    • On, if all objects should be compiled with QUOTED_IDENTIFIER set to ON.
  14. In the Completing the SQL Server Wizard screen, view the summary of choices you have made. Click View warnings and choices in notepad to open a text version of the upgrade script. If all options are correct, click Finish.

    The SQL Server Upgrade Script Interpreter screen appears with information about the progress of the upgrade.

See Also

Order of Upgrade Using a Direct Pipeline or Tape Drive


Database Architecture

Microsoft® SQL Server™ 2000 data is stored in databases. The data in a database is organized into the logical components visible to users. A database is also physically implemented as two or more files on disk.

When using a database, you work primarily with the logical components such as tables, views, procedures, and users. The physical implementation of files is largely transparent. Typically, only the database administrator needs to work with the physical implementation.

Each instance of SQL Server has four system databases (master, model, tempdb, and msdb) and one or more user databases. Some organizations have only one user database, containing all the data for their organization. Some organizations have different databases for each group in their organization, and sometimes a database used by a single application. For example, an organization could have one database for sales, one for payroll, one for a document management application, and so on. Sometimes an application uses only one database; other applications may access several databases.

It is not necessary to run multiple copies of the SQL Server database engine to allow multiple users to access the databases on a server. An instance of the SQL Server Standard or Enterprise Edition is capable of handling thousands of users working in multiple databases at the same time. Each instance of SQL Server makes all databases in the instance available to all users that connect to the instance, subject to the defined security permissions.

When connecting to an instance of SQL Server, your connection is associated with a particular database on the server. This database is called the current database. You are usually connected to a database defined as your default database by the system administrator, although you can use connection options in the database APIs to specify another database. You can switch from one database to another using either the Transact-SQL USE database_name statement, or an API function that changes your current database context.

SQL Server 2000 allows you to detach databases from an instance of SQL Server, then reattach them to another instance, or even attach the database back to the same instance. If you have a SQL Server database file, you can tell SQL Server when you connect to attach that database file with a specific database name.

See Also

Database Design Considerations


Logical Database Components

The data in a Microsoft® SQL Server™ 2000 database is organized into several different objects. These objects are what a user can see when they connect to the database.

In SQL Server 2000, these components are defined as objects:

Constraints | Tables
Defaults | Triggers
Indexes | User-defined data types
Keys | User-defined functions
Stored procedures | Views


Data Types and Table Structures

New Information - SQL Server 2000 SP3.

All the data in Microsoft® SQL Server™ 2000 databases is contained in objects called tables. Each table represents some type of object meaningful to the users. For example, in a school database you would find tables such as a class table, an instructor table, and a student table.

SQL Server tables have two main components:

  • Columns

    Each column represents some attribute of the object modeled by the table, such as a parts table having columns for ID, color, and weight.

  • Rows

    Each row represents an individual occurrence of the object modeled by the table. For example, the parts table would have one row for each part carried by the company.

Data Types

Because each column represents one attribute of an object, the data in each occurrence of the column is similar. One of the properties of a column is called its data type, which defines the type of data the column can hold. SQL Server has several base data types that can be specified for columns:

binary | Bigint | bit | Char | datetime
decimal | Float | image | Int | Money
nchar | Ntext | nvarchar | Numeric | Real
smalldatetime | smallint | smallmoney | sql_variant | sysname
text | timestamp | tinyint | varbinary | varchar
uniqueidentifier |  |  |  |

SQL Server 2000 also supports a table base data type, which can be used to store the result set of an SQL statement. The table data type cannot be used for columns in a table. It can only be used for Transact-SQL variables and the return values of user-defined functions. For more information, see Using Special Data.

Users can also create their own user-defined data types, for example:

-- Create a birthday data type that allows nulls.
EXEC sp_addtype birthday, datetime, 'NULL'
GO
-- Create a table using the new data type.
CREATE TABLE employee
   (emp_id         char(5),
   emp_first_name   char(30),
   emp_last_name   char(40),
   emp_birthday      birthday)

A user-defined data type makes a table structure more meaningful to programmers and helps ensure that columns holding similar classes of data have the same base data type.

SQL Server provides several data type synonyms to help support SQL-92 data type names not included as base data types, such as national character and character varying. When a synonym is specified in a CREATE TABLE statement, the column is assigned the base data type associated with the synonym. For more information, see Data Type Synonyms.

A domain is the set of all allowable values in a column. It includes not only the concept of enforcing data types, but also the values allowed in the column. For example, a part color domain would include both the data type, such as char(6), and the character strings allowed in the column, such as Red, Blue, Green, Yellow, Brown, Black, White, Teal, Grey, and Silver. Domain values can be enforced through mechanisms such as CHECK constraints and triggers.

When a column has been assigned a data type, all values placed into the column must be of that data type. SQL statements can specify that values of different data types be used as the source value only if SQL Server can implicitly convert the source value data type to the data type of the column. For example, SQL Server supports the implicit conversion of int values to decimal; therefore, SQL statements can specify int values as the value to be assigned to a decimal column.

The SQL Server 2000 sql_variant data type is a special data type that allows you to store values of multiple base data types in the same column. For example, you can store nchar values, int values, and decimal values in the same column. For more information, see Using sql_variant Data.

Null Values

Columns can either accept or reject null values. NULL is a special value in databases that represents the concept of an unknown value. NULL is not the same as a blank character or 0. Blank is actually a valid character, and 0 is a valid number. NULL simply represents the idea that we do not know what this value is. NULL is also different from a zero-length string. If a column definition contains the NOT NULL clause, you cannot insert rows having the value NULL for that row. If the column definition has only the NULL keyword, it accepts NULL values.

Allowing NULL values in a column can increase the complexity of any logical comparisons using the column. The SQL-92 standard states that any comparison against a NULL value does not evaluate to TRUE or FALSE, it evaluates to UNKNOWN. This introduces three-value logic to comparison operators, which can be difficult to manage correctly.

System Tables

SQL Server stores the data defining the configuration of the server and all its tables in a special set of tables known as system tables. SQL Server does not support direct updates to the system tables by users or applications. Only SQL Server should update the system tables in response to administration commands issued by users. Additionally, users should not query the system tables directly unless there is no other way to get the data required by the application. The system tables can change from version to version; applications referencing system tables directly may have to be rewritten before they can be upgraded to a newer version of SQL Server with a different version of the system tables. SQL Server exposes most of the information from the system tables through other means. For more information, see System Tables.

Temporary Tables

SQL Server supports temporary tables. These tables have names that start with a number sign (#). If a temporary table is not dropped when a user disconnects, SQL Server automatically drops the temporary table. Temporary tables are not stored in the current database; they are stored in the tempdb system database.

There are two types of temporary tables:

  • Local temporary tables

    The names of these tables begin with one number sign (#). These tables are visible only to the connection that created them.

  • Global temporary tables

    The names of these tables begin with two number signs (##). These tables are visible to all connections. If the tables are not dropped explicitly before the connection that created them disconnects, they are dropped as soon as all other tasks stop referencing them. No new tasks can reference a global temporary table after the connection that created it disconnects. The association between a task and a table is always dropped when the current statement completes executing; therefore, global temporary tables are usually dropped soon after the connection that created them disconnects.

Many traditional uses of temporary tables can now be replaced with variables that have the table data type.

Working with Tables

Users work with the data in tables using data manipulation language (DML) SQL statements:

-- Get a list of all employees named Smith:
SELECT emp_first_name, emp_last_name
FROM employee
WHERE emp_last_name = 'Smith'

-- Delete an employee who quit:
DELETE employee
WHERE emp_id = 'OP123'

-- Add a new employee:
INSERT INTO employee
VALUES ( 'OP456', 'Dean', 'Straight', '01/01/1960')

-- Change an employee name:
UPDATE employee
SET emp_last_name = 'Smith'
WHERE emp_id = 'OP456'

See Also

Specifying a Column Data Type

Tables


SQL Views

A view can be thought of as either a virtual table or a stored query. The data accessible through a view is not stored in the database as a distinct object. What is stored in the database is a SELECT statement. The result set of the SELECT statement forms the virtual table returned by the view. A user can use this virtual table by referencing the view name in Transact-SQL statements the same way a table is referenced. A view is used to do any or all of these functions:

  • Restrict a user to specific rows in a table.

    For example, allow an employee to see only the rows recording his or her work in a labor-tracking table.

  • Restrict a user to specific columns.

    For example, allow employees who do not work in payroll to see the name, office, work phone, and department columns in an employee table, but do not allow them to see any columns with salary information or personal information.

  • Join columns from multiple tables so that they look like a single table.

  • Aggregate information instead of supplying details.

    For example, present the sum of a column, or the maximum or minimum value from a column.

Views are created by defining the SELECT statement that retrieves the data to be presented by the view. The data tables referenced by the SELECT statement are known as the base tables for the view. In this example, titleview in the pubs database is a view that selects data from three base tables to present a virtual table of commonly needed data:

CREATE VIEW titleview
AS
SELECT title, au_ord, au_lname, price, ytd_sales, pub_id
FROM authors AS a
     JOIN titleauthor AS ta ON (a.au_id = ta.au_id)
     JOIN titles AS t ON (t.title_id = ta.title_id)

You can then reference titleview in statements in the same way you would reference a table:

SELECT *
FROM titleview

A view can reference another view. For example, titleview presents information that is useful for managers, but a company typically discloses year-to-date figures only in quarterly or annual financial statements. A view can be built that selects all the titleview columns except au_ord and ytd_sales. This new view can be used by customers to get lists of available books without seeing the financial information:

CREATE VIEW Cust_titleview
AS
SELECT title, au_lname, price, pub_id
FROM titleview

Views can be used to partition data across multiple databases or instances of Microsoft® SQL Server™ 2000. Partitioned views can be used to distribute database processing across a group of servers. The group of servers has the same performance benefits as a cluster of servers, and can be used to support the processing needs of the largest Web sites or corporate data centers. An original table is subdivided into several member tables, each of which has a subset of the rows from the original table. Each member table can be placed in databases on separate servers. Each server also gets a partitioned view. The partitioned view uses the Transact-SQL UNION operator to combine the results of selects against all the member tables into a single result set that behaves exactly like a copy of the full original table. For example, a table is partitioned across three servers. On the first server you define a partitioned view similar to this:

CREATE VIEW PartitionedView AS
SELECT *
    FROM MyDatabase.dbo.PartitionTable1
UNION ALL
SELECT *
    FROM Server2.MyDatabase.dbo.PartitionTable2
UNION ALL
SELECT *
    FROM Server3.MyDatabase.dbo.PartitionTable3

You define similar partitioned views on each of the other servers. With these three views, any Transact-SQL statements on any of the three servers that reference PartitionedView will see the same behavior as from the original table. It is as if a copy of the original table exists on each server, when in fact there is only one member table and a partitioned view on each table. For more information, see Scenarios for Using Views.

Views in all versions of SQL Server are updatable (can be the target of UPDATE, DELETE, or INSERT statements), as long as the modification affects only one of the base tables referenced by the view, for example:

-- Increase the prices for publisher '0736' by 10%.
UPDATE titleview
SET price = price * 1.10
WHERE pub_id = '0736'
GO

SQL Server 2000 supports more complex types of INSERT, UPDATE, and DELETE statements that reference views. INSTEAD OF triggers can be defined on a view to specify the individual updates that must be performed against the base tables to support the INSERT, UPDATE, or DELETE statement. Also, partitioned views support INSERT, UPDATE, and DELETE statements that modify multiple member tables referenced by the view.

Indexed views are a SQL Server 2000 feature that greatly improves the performance of complex views of the type usually found in data warehouses or other decision support systems.

Views are called virtual tables because the result set of a view is us not usually saved in the database The result set for a view is dynamically incorporated into the logic of the statement and the result set is built dynamically at run time. For more information, see View Resolution.

Complex queries, such as those in decision support systems, can reference large numbers of rows in base tables, and aggregate large amounts of information into relatively concise aggregates such as sums or averages. SQL Server 2000 supports creating a clustered index on a view that implements such a complex query. When the CREATE INDEX statement is executed the result set of the view SELECT is stored permanently in the database. Future SQL statements that reference the view will have substantially better response times. Modifications to the base data are automatically reflected in the view.

The SQL Server 2000 CREATE VIEW statement supports a SCHEMABINDING option that prevents the tables referenced by the view being changed without adjusting the view. You must specify SCHEMABINDING for any view on which you create an index.

See Also

CREATE INDEX

CREATE TRIGGER

CREATE VIEW

Designing an Indexed View

Views


SQL Stored Procedures

A stored procedure is a group of Transact-SQL statements compiled into a single execution plan.

Microsoft® SQL Server™ 2000 stored procedures return data in four ways:

  • Output parameters, which can return either data (such as an integer or character value) or a cursor variable (cursors are result sets that can be retrieved one row at a time).

  • Return codes, which are always an integer value.

  • A result set for each SELECT statement contained in the stored procedure or any other stored procedures called by the stored procedure.

  • A global cursor that can be referenced outside the stored procedure.

Stored procedures assist in achieving a consistent implementation of logic across applications. The SQL statements and logic needed to perform a commonly performed task can be designed, coded, and tested once in a stored procedure. Each application needing to perform that task can then simply execute the stored procedure. Coding business logic into a single stored procedure also offers a single point of control for ensuring that business rules are correctly enforced.

Stored procedures can also improve performance. Many tasks are implemented as a series of SQL statements. Conditional logic applied to the results of the first SQL statements determines which subsequent SQL statements are executed. If these SQL statements and conditional logic are written into a stored procedure, they become part of a single execution plan on the server. The results do not have to be returned to the client to have the conditional logic applied; all of the work is done on the server. The IF statement in this example shows embedding conditional logic in a procedure to keep from sending a result set to the application:

IF (@QuantityOrdered < (SELECT QuantityOnHand
                  FROM Inventory
                  WHERE PartID = @PartOrdered) )
   BEGIN
   -- SQL statements to update tables and process order.
   END
ELSE
   BEGIN
   -- SELECT statement to retrieve the IDs of alternate items
   -- to suggest as replacements to the customer.
   END

Applications do not need to transmit all of the SQL statements in the procedure: they have to transmit only an EXECUTE or CALL statement containing the name of the procedure and the values of the parameters.

Stored procedures can also shield users from needing to know the details of the tables in the database. If a set of stored procedures supports all of the business functions users need to perform, users never need to access the tables directly; they can just execute the stored procedures that model the business processes with which they are familiar.

An illustration of this use of stored procedures is the SQL Server system stored procedures used to insulate users from the system tables. SQL Server includes a set of system stored procedures whose names usually start with sp_. These system stored procedures support all of the administrative tasks required to run a SQL Server system. You can administer a SQL Server system using the Transact-SQL administration-related statements (such as CREATE TABLE) or the system stored procedures, and never need to directly update the system tables.

Stored Procedures and Execution Plans

In SQL Server version 6.5 and earlier, stored procedures were a way to partially precompile an execution plan. At the time the stored procedure was created, a partially compiled execution plan was stored in a system table. Executing a stored procedure was more efficient than executing an SQL statement because SQL Server did not have to compile an execution plan completely, it only had to finish optimizing the stored plan for the procedure. Also, the fully compiled execution plan for the stored procedure was retained in the SQL Server procedure cache, meaning that subsequent executions of the stored procedure could use the precompiled execution plan.

SQL Server 2000 and SQL Server version 7.0 incorporate a number of changes to statement processing that extend many of the performance benefits of stored procedures to all SQL statements. SQL Server 2000 and SQL Server 7.0 do not save a partially compiled plan for stored procedures when they are created. A stored procedure is compiled at execution time, like any other Transact-SQL statement. SQL Server 2000 and SQL Server 7.0 retain execution plans for all SQL statements in the procedure cache, not just stored procedure execution plans. The database engine uses an efficient algorithm for comparing new Transact-SQL statements with the Transact-SQL statements of existing execution plans. If the database engine determines that a new Transact-SQL statement matches the Transact-SQL statement of an existing execution plan, it reuses the plan. This reduces the relative performance benefit of precompiling stored procedures by extending execution plan reuse to all SQL statements.

SQL Server 2000 and SQL Server version 7.0 offer new alternatives for processing SQL statements. For more information, see Query Processor Architecture.

Temporary Stored Procedures

SQL Server 2000 also supports temporary stored procedures that, like temporary tables, are dropped automatically when you disconnect. Temporary stored procedures are stored in tempdb and are useful when connected to earlier versions of SQL Server. Temporary stored procedures can be used when an application builds dynamic Transact-SQL statements that are executed several times. Rather than have the Transact-SQL statements recompiled each time, you can create a temporary stored procedure that is compiled on the first execution, and then execute the precompiled plan multiple times. Heavy use of temporary stored procedures, however, can lead to contention on the system tables in tempdb.

Two features of SQL Server 2000 and SQL Server 7.0 eliminate the need for using temporary stored procedures:

  • Execution plans from prior SQL statements can be reused. This is especially powerful when coupled with the use of the new sp_executesql system stored procedure.

  • Natively support for the prepare/execute model of OLE DB and ODBC without using any stored procedures.

For more information about alternatives to using temporary stored procedures, see Execution Plan Caching and Reuse.

Stored Procedure Example

This simple stored procedure example illustrates three ways stored procedures can return data:

  1. It first issues a SELECT statement that returns a result set summarizing the order activity for the stores in the sales table.

  2. It then issues a SELECT statement that fills an output parameter.

  3. Finally, it has a RETURN statement with a SELECT statement that returns an integer. Return codes are generally used to pass back error checking information. This procedure runs without errors, so it returns another value to illustrate how returned codes are filled.
USE Northwind
GO
DROP PROCEDURE OrderSummary
GO
CREATE PROCEDURE OrderSummary @MaxQuantity INT OUTPUT AS
-- SELECT to return a result set summarizing
-- employee sales.
SELECT Ord.EmployeeID, SummSales = SUM(OrDet.UnitPrice * OrDet.Quantity)
FROM Orders AS Ord
     JOIN [Order Details] AS OrDet ON (Ord.OrderID = OrDet.OrderID)
GROUP BY Ord.EmployeeID
ORDER BY Ord.EmployeeID

-- SELECT to fill the output parameter with the
-- maximum quantity from Order Details.
SELECT @MaxQuantity = MAX(Quantity) FROM [Order Details]

-- Return the number of all items ordered.
RETURN (SELECT SUM(Quantity) FROM [Order Details])
GO

-- Test the stored procedure.

-- DECLARE variables to hold the return code
-- and output parameter.
DECLARE @OrderSum INT
DECLARE @LargestOrder INT

-- Execute the procedure, which returns
-- the result set from the first SELECT.
EXEC @OrderSum = OrderSummary @MaxQuantity = @LargestOrder OUTPUT

-- Use the return code and output parameter.
PRINT 'The size of the largest single order was: ' +
                 CONVERT(CHAR(6), @LargestOrder)
PRINT 'The sum of the quantities ordered was: ' +
                 CONVERT(CHAR(6), @OrderSum)
GO

The output from running this sample is:

EmployeeID  SummSales
----------- --------------------------
1           202,143.71
2           177,749.26
3           213,051.30
4           250,187.45
5           75,567.75
6           78,198.10
7           141,295.99
8           133,301.03
9           82,964.00
The size of the largest single order was: 130
The sum of the quantities ordered was: 51317

See Also

Stored Procedures


SQL User-Defined Functions

Functions in programming languages are subroutines used to encapsulate frequently performed logic. Any code that must perform the logic incorporated in a function can call the function rather than having to repeat all of the function logic.

Microsoft® SQL Server™ 2000 supports two types of functions:

  • Built-in functions

    Operate as defined in the Transact-SQL Reference and cannot be modified. The functions can be referenced only in Transact-SQL statements using the syntax defined in the Transact-SQL Reference. For more information about these built-in functions, see Using Functions.

  • User-defined functions

    Allow you to define your own Transact-SQL functions using the CREATE FUNCTION statement. For more information about these built-in functions, see User-defined Functions.

User-defined functions take zero or more input parameters, and return a single value. Some user-defined functions return a single, scalar data value, such as an int, char, or decimal value.

For example, this statement creates a simple function that returns a decimal:

CREATE FUNCTION CubicVolume
-- Input dimensions in centimeters.
   (@CubeLength decimal(4,1), @CubeWidth decimal(4,1),
    @CubeHeight decimal(4,1) )
RETURNS decimal(12,3) -- Cubic Centimeters.
AS
BEGIN
   RETURN ( @CubeLength * @CubeWidth * @CubeHeight )
END

This function can then be used anywhere an integer expression is allowed, such as in a computed column for a table:

CREATE TABLE Bricks
   (
    BrickPartNmbr   int PRIMARY KEY,
    BrickColor      nchar(20),
    BrickHeight     decimal(4,1),
    BrickLength     decimal(4,1),
    BrickWidth      decimal(4,1),
    BrickVolume AS
              (
               dbo.CubicVolume(BrickHeight,
                         BrickLength, BrickWidth)
              )
   )

SQL Server 2000 also supports user-defined functions that return a table data type:

  • A function can declare an internal table variable, insert rows into the variable, and then return the variable as its return value.

  • A class of user-defined functions known as in-line functions, return the result set of a SELECT statement as a variable of type table.

These functions can be used in places where table expressions can be specified. For more information about the table data type, see Using Special Data.

User-defined functions that return a table can be powerful alternatives to views. A user-defined function that returns a table can be used where table or view expressions are allowed in Transact-SQL queries. Views are limited to a single SELECT statement; however, user-defined functions can contain additional statements that allow more powerful logic than is possible in views.

A user-defined function that returns a table can also replace stored procedures that return a single result set. The table returned by a user-defined function can be referenced in the FROM clause of a Transact-SQL statement, whereas stored procedures that return result sets cannot. For example, fn_EmployeesInDept is a user-defined function that returns a table and can be invoked by a SELECT statement:

SELECT *
FROM tb_Employees AS E,
     dbo.fn_EmployeesInDept('shipping') AS EID
WHERE E.EmployeeID = EID.EmployeeID

This is an example of a statement that creates a function in the Northwind database that will return a table:

CREATE FUNCTION LargeOrderShippers ( @FreightParm money )
RETURNS @OrderShipperTab TABLE
   (
    ShipperID     int,
    ShipperName   nvarchar(80),
    OrderID       int,
    ShippedDate   datetime,
    Freight       money
   )
AS
BEGIN
   INSERT @OrderShipperTab
        SELECT S.ShipperID, S.CompanyName,
               O.OrderID, O.ShippedDate, O.Freight
        FROM Shippers AS S
             INNER JOIN Orders AS O ON (S.ShipperID = O.ShipVia)
        WHERE O.Freight > @FreightParm
   RETURN
END

In this function, the local return variable name is @OrderShipperTab. Statements in the function build the table result returned by the function by inserting rows into the variable @OrderShipperTab. External statements invoke the function to reference the table returned by the function:

SELECT *
FROM LargeOrderShippers( $500 )


Constraints, Rules, Defaults, and Triggers

Table columns have properties other than data type and size. These other properties are an important part in ensuring the integrity of data in a database:

  • Data integrity refers to each occurrence of a column having a correct data value.

    The data values must be of the right data type and in the correct domain.

  • Referential integrity indicates that the relationships between tables have been properly maintained.

    Data in one table should only point to existing rows in another table; it should not point to rows that do not exist.

Objects used to maintain both types of integrity include:

  • Constraints

  • Rules

  • Defaults

  • Triggers


Constraints

Constraints allow you to define the way Microsoft® SQL Server™ 2000 automatically enforces the integrity of a database. Constraints define rules regarding the values allowed in columns and are the standard mechanism for enforcing integrity. Using constraints is preferred to using triggers, rules, and defaults. The query optimizer also uses constraint definitions to build high-performance query execution plans.

Classes of Constraints

SQL Server 2000 supports five classes of constraints.

  • NOT NULL specifies that the column does not accept NULL values.

  • CHECK constraints enforce domain integrity by limiting the values that can be placed in a column.

    A CHECK constraint specifies a Boolean (evaluates to TRUE or FALSE) search condition that is applied to all values entered for the column; all values that do not evaluate to TRUE are rejected. You can specify multiple CHECK constraints for each column. This sample shows the creation of a named constraint, chk_id, that further enforces the domain of the primary key by ensuring that only numbers within a specified range are entered for the key.

    CREATE TABLE cust_sample
    (
    cust_id                int        PRIMARY KEY,
    cust_name            char(50),
    cust_address            char(50),
    cust_credit_limit    money,
    CONSTRAINT chk_id CHECK (cust_id BETWEEN 0 and 10000 )
    )
  • UNIQUE constraints enforce the uniqueness of the values in a set of columns.

    No two rows in the table are allowed to have the same not null values for the columns in a UNIQUE constraint. Primary keys also enforce uniqueness, but primary keys do not allow null values. A UNIQUE constraint is preferred over a unique index.

  • PRIMARY KEY constraints identify the column or set of columns whose values uniquely identify a row in a table.

    No two rows in a table can have the same primary key value. You cannot enter a NULL for any column in a primary key. NULL is a special value in databases that represents an unknown value, which is distinct from a blank or 0 value. Using a small, integer column as a primary key is recommended. Each table should have a primary key.

    A table may have more than one combination of columns that could uniquely identify the rows in a table; each combination is a candidate key. The database administrator picks one of the candidate keys to be the primary key. For example, in the part_sample table both part_nmbr and part_name could be candidate keys, but only part_nmbr is chosen as a primary key.

    CREATE TABLE part_sample
            (part_nmbr        int            PRIMARY KEY,
            part_name        char(30),
            part_weight        decimal(6,2),
            part_color        char(15) )
  • FOREIGN KEY constraints identify the relationships between tables.

    A foreign key in one table points to a candidate key in another table. Foreign keys prevent actions that would leave rows with foreign key values when there are no candidate keys with that value. In the following sample, the order_part table establishes a foreign key referencing the part_sample table defined earlier. Usually, order_part would also have a foreign key against an order table, but this is a simple example.

    CREATE TABLE order_part
        (order_nmbr        int,
        part_nmbr        int
            FOREIGN KEY REFERENCES part_sample(part_nmbr)
                ON DELETE NO ACTION,
        qty_ordered        int)
GO

    You cannot insert a row with a foreign key value (except NULL) if there is no candidate key with that value. The ON DELETE clause controls what actions are taken if you attempt to delete a row to which existing foreign keys point. The ON DELETE clause has two options:

    • NO ACTION specifies that the deletion fails with an error.

    • CASCADE specifies that all the rows with foreign keys pointing to the deleted row are also deleted.

    The ON UPDATE clause defines the actions that are taken if you attempt to update a candidate key value to which existing foreign keys point. It also supports the NO ACTION and CASCADE options.

Column and Table Constraints

Constraints can be column constraints or table constraints:

  • A column constraint is specified as part of a column definition and applies only to that column (the constraints in the earlier samples are column constraints).

  • A table constraint is declared independently from a column definition and can apply to more than one column in a table.

Table constraints must be used when more than one column must be included in a constraint.

For example, if a table has two or more columns in the primary key, you must use a table constraint to include both columns in the primary key. Consider a table that records events happening in a computer in a factory. Assume that events of several types can happen at the same time, but that no two events happening at the same time can be of the same type. This can be enforced in the table by including both the type and time columns in a two-column primary key.

CREATE TABLE factory_process
   (event_type   int,
   event_time   datetime,
   event_site   char(50),
   event_desc   char(1024),
CONSTRAINT event_key PRIMARY KEY (event_type, event_time) )

See Also

CREATE TABLE

Creating and Modifying a Table


Rules

Rules are a backward-compatibility feature that perform some of the same functions as CHECK constraints. CHECK constraints are the preferred, standard way to restrict the values in a column. CHECK constraints are also more concise than rules; there can only be one rule applied to a column, but multiple CHECK constraints can be applied. CHECK constraints are specified as part of the CREATE TABLE statement, while rules are created as separate objects and then bound to the column.

This example creates a rule that performs the same function as the CHECK constraint example in the preceding topic. The CHECK constraint is the preferred method to use in Microsoft® SQL Server™ 2000.

CREATE RULE id_chk AS @id BETWEEN 0 and 10000
GO
CREATE TABLE cust_sample
   (
   cust_id            int
   PRIMARY KEY,
   cust_name         char(50),
   cust_address         char(50),
   cust_credit_limit   money,
   )
GO
sp_bindrule id_chk, 'cust_sample.cust_id'
GO

See Also

CREATE TABLE

Creating and Modifying a Table


Defaults

Defaults specify what values are used in a column if you do not specify a value for the column when inserting a row. Defaults can be anything that evaluates to a constant, such as:

  • Constant

  • Built-in function

  • Mathematical expression

There are two ways to apply defaults:

  • Create a default definition using the DEFAULT keyword in CREATE TABLE to assign a constant expression as a default on a column.

    This is the preferred, standard method. It is also the more concise way to specify a default.

  • Create a default object using the CREATE DEFAULT statement and bind it to columns using the sp_bindefault system stored procedure.

    This is a backward compatibility feature.

This example creates a table using one of each type of default. It creates a default object to assign a default to one column, and binds the default object to the column. It then does a test insert without specifying values for the columns with defaults and retrieves the test row to verify the defaults were applied.

USE pubs
GO
CREATE TABLE test_defaults
   (keycol      smallint,
   process_id   smallint DEFAULT @@SPID,   --Preferred default definition
   date_ins   datetime DEFAULT getdate(),   --Preferred default definition
   mathcol      smallint DEFAULT 10 * 2,   --Preferred default definition
   char1      char(3),
   char2      char(3) DEFAULT 'xyz') --Preferred default definition
GO
/* Illustration only, use DEFAULT definitions instead.*/
CREATE DEFAULT abc_const AS 'abc'
GO
sp_bindefault abc_const, 'test_defaults.char1'
GO
INSERT INTO test_defaults(keycol) VALUES (1)
GO
SELECT * FROM test_defaults
GO

The output of this sample is:

Default bound to column.

(1 row(s) affected)

keycol process_id date_ins                    mathcol char1 char2
------ ---------- --------------------------- ------- ----- -----
1      7          Oct 16 1997  8:34PM         20      abc   xyz

(1 row(s) affected)

See Also

CREATE TABLE

Creating and Modifying a Table


Triggers

Microsoft® SQL Server™ 2000 triggers are a special class of stored procedure defined to execute automatically when an UPDATE, INSERT, or DELETE statement is issued against a table or view. Triggers are powerful tools that sites can use to enforce their business rules automatically when data is modified. Triggers can extend the integrity checking logic of SQL Server constraints, defaults, and rules, although constraints and defaults should be used instead whenever they provide all the needed functionality.

Tables can have multiple triggers. The CREATE TRIGGER statement can be defined with the FOR UPDATE, FOR INSERT, or FOR DELETE clauses to target a trigger to a specific class of data modification actions. When FOR UPDATE is specified, the IF UPDATE (column_name) clause can be used to target a trigger to updates affecting a particular column.

Triggers can automate the processing for a company. In an inventory system, update triggers can detect when a stock level reaches a reorder point and generate an order to the supplier automatically. In a database recording the processes in a factory, triggers can e-mail or page operators when a process exceeds defined safety limits.

The following trigger generates an e-mail whenever a new title is added in the pubs database:

CREATE TRIGGER reminder
ON titles
FOR INSERT
AS
   EXEC master..xp_sendmail 'MaryM',
      'New title, mention in the next report to distributors.'

Triggers contain Transact-SQL statements, much the same as stored procedures. Triggers, like stored procedures, return the result set generated by any SELECT statements in the trigger. Including SELECT statements in triggers, except statements that only fill parameters, is not recommended. This is because users do not expect to see any result sets returned by an UPDATE, INSERT, or DELETE statement.

You can use the FOR clause to specify when a trigger is executed:

  • AFTER

    The trigger executes after the statement that triggered it completes. If the statement fails with an error, such as a constraint violation or syntax error, the trigger is not executed. AFTER triggers cannot be specified for views, they can only be specified for tables. You can specify multiple AFTER triggers for each triggering action (INSERT, UPDATE, or DELETE). If you have multiple AFTER triggers for a table, you can use sp_settriggerorder to define which AFTER trigger fires first and which fires last. All other AFTER triggers besides the first and last fire in an undefined order which you cannot control.

    AFTER is the default in SQL Server 2000. You could not specify AFTER or INSTEAD OF in SQL Server version 7.0 or earlier, all triggers in those versions operated as AFTER triggers.

  • INSTEAD OF

    The trigger executes in place of the triggering action. INSTEAD OF triggers can be specified on both tables and views. You can define only one INSTEAD OF trigger for each triggering action (INSERT, UPDATE, and DELETE). INSTEAD OF triggers can be used to perform enhance integrity checks on the data values supplied in INSERT and UPDATE statements. INSTEAD OF triggers also let you specify actions that allow views, which would normally not support updates, to be updatable.

See Also

Enforcing Business Rules with Triggers


Collations

The physical storage of character strings in Microsoft® SQL Server™ 2000 is controlled by collations. A collation specifies the bit patterns that represent each character and the rules by which characters are sorted and compared.

SQL Server 2000 supports objects that have different collations being stored in a single database. Separate SQL Server 2000 collations can be specified down to the level of columns. Each column in a table can be assigned different collations. Earlier versions of SQL Server support only one collation for each instance of SQL Server. All databases and database objects created in an instance of SQL Server 7.0 or earlier have the same collation.

How Character Data Is Stored

In a computer, characters are represented by different patterns of bits being either ON or OFF. There are 8 bits in a byte, and the 8 bits can be turned ON and OFF in 256 different patterns. A program that uses 1 byte to store each character can therefore represent up to 256 different characters by assigning a character to each of the bit patterns. There are 16 bits in 2 bytes, and 16 bits can be turned ON and OFF in 65,536 unique patterns. A program that uses 2 bytes to represent each character can represent up to 65,536 characters.

Single-byte code pages are definitions of the characters mapped to each of the 256 bit patterns possible in a byte. Code pages define bit patterns for uppercase and lowercase characters, digits, symbols, and special characters such as !, @, #, or %. Each European language, such as German or Spanish, has its own single-byte code page. Although the bit patterns used to represent the Latin alphabet characters A through Z are the same for all the code pages, the bit patterns used to represent accented characters such as 'é' and 'á' vary from one code page to the next. If data is exchanged between computers running different code pages, all character data must be converted from the code page of the sending computer to the code page of the receiving computer. If the source data has extended characters that are not defined in the code page of the receiving computer, data is lost. When a database serves clients from many different countries/regions, it is difficult to pick a code page for the database that contains all the extended characters required by all the client computers. Also, there is a lot of processing time spent doing the constant conversions from one code page to another.

Single-byte character sets are also inadequate to store all the characters used by many languages. For example, some Asian languages have thousands of characters, so must use two bytes per character. Double-byte character sets have been defined for these languages. Still, each of these languages have their own code page, and there are difficulties in transferring data from a computer running one double-byte code page to a computer running another.

SQL Server 2000 supports these code pages.

Code page | Description
1258 | Vietnamese
1257 | Baltic
1256 | Arabic
1255 | Hebrew
1254 | Turkish
1253 | Greek
1252 | Latin1 (ANSI)
1251 | Cyrillic
1250 | Central European
950 | Chinese (Traditional)
949 | Korean
936 | Chinese (Simplified)
932 | Japanese
874 | Thai
850 | Multilingual (MS-DOS Latin1)
437 | MS-DOS U.S. English

To address the character conversion and interpretation problems that occur when trying to support multiple code pages in a network, the ISO standards organization and a group called the Unicode Consortium defined the Unicode standard. Unicode uses two bytes to store each character. Because 65,536 characters are enough to cover all the commonly used characters from all the languages of the world, all major languages are covered by the Unicode standard. If all the computers and programs in a network use Unicode, there is no need for any character conversions, each user will see exactly the same characters as all other users, and no loss of characters will occur.

On computers running Microsoft Windows® operating systems, the code page used by the operating system and Windows applications is defined by the Windows locale. The locale is selected when the operating system is installed. Windows applications interpret character data using the code page defined by the Windows locale. Windows applications also support wide character, or Unicode, data.

SQL Server 2000 supports two categories of character data types:

  • The Unicode data types nchar, nvarchar, and ntext. These data types use the Unicode character representation. Code pages do not apply to these data types.

  • The non-Unicode character data types char, varchar, and text. These data types use the character representation scheme defined in a single or double-byte code page.

For more information about how character data is stored and the operation of code pages, Unicode, and sort orders, see Developing International Software for Windows 95 and Windows NT 4.0 in the MSDN® page at http://msdn.microsoft.com.

International Data and Unicode

Storing data in multiple languages within one database is difficult to manage when using only character data and code pages. It is difficult to find one code page for the database that can store all the required language-specific characters. It is also difficult to ensure the proper translation of special characters when being read or updated by different clients running various code pages. Databases that support international clients should always use Unicode data types instead of non-Unicode data types.

For example, a database of customers in North America has to handle three major languages:

  • Spanish names and addresses for Mexico.

  • French names and addresses for Quebec.

  • English names and addresses for the rest of Canada and the United States.

When you use only character columns and code pages, care has to be taken to ensure the database is installed with a code page that will handle the characters of all three languages. More care must be taken to ensure the proper translation of characters from one of the languages when read by clients running a code page for another language.

With the growth of the Internet, it is becoming more important than ever before to support many client computers running different locales. It is difficult to pick a code page for character data types that will support all of the characters required by a worldwide audience.

The easiest way to manage character data in international databases is to always use the Unicode nchar, nvarchar, and ntext data types in place of their non-Unicode equivalents (char, varchar, and text). If all the applications that work with international databases also use Unicode variables instead of non-Unicode variables, character translations do not have to be performed anywhere in the system. All clients will see exactly the same characters in data as all other clients.

For systems that could use single-byte code pages, the fact that Unicode data needs twice as much storage space as non-Unicode character data is at least partially offset by eliminating the need to convert extended characters between code pages. Systems using double-byte code pages do not have this issue.

SQL Server 2000 stores all textual system catalog data in columns having Unicode data types. The names of database objects such as tables, views, and stored procedures are stored in Unicode columns. This allows applications to be developed using only Unicode, which avoids all issues with code page conversions.

Sort Order

A sort order specifies the rules used by SQL Server to interpret, collate, compare, and present character data. For example, a sort order defines whether 'a' is less than, equal to, or greater than 'b'. A sort order defines whether the collation is case-sensitive, for example whether 'm' is equal or not equal to 'M'. It also defines if the collation is accent-sensitive, for example whether 'á' is equal or not equal to 'ä'.

SQL Server 2000 uses two sort orders with each collation, one for Unicode data and another for the character code page.

Many SQL Server collations use the same code page, but have a different sort order for the code page. This allows sites to choose:

  • Whether characters will simply be sorted based on the numeric value represented by their bit patterns. Binary sorting is fastest because SQL Server does not have to make any adjustments and can use fast, simple sorting algorithms. Binary sort orders are always case-sensitive. Because the bit patterns in a code page may not be arranged in the same sequence as defined by the dictionary rules for a specific language, binary sorting sometimes does not sort characters in a sequence users who speak that language might expect.

  • Between case-sensitive or case-insensitive behavior.

  • Between accent-sensitive or accent-insensitive behavior.

See Also

Collation Options for International Support

SQL Server Collation Fundamentals

Unicode Data

Using Unicode Data


SQL Server Collation Fundamentals

Microsoft® SQL Server™ 2000 supports several collations. A collation encodes the rules governing the proper use of characters for either a language, such as Greek or Polish, or an alphabet, such as Latin1_General (the Latin alphabet used by western European languages).

Each SQL Server collation specifies three properties:

  • The sort order to use for Unicode data types (nchar, nvarchar, and ntext). A sort order defines the sequence in which characters are sorted, and the way characters are evaluated in comparison operations.

  • The sort order to use for non-Unicode character data types (char, varchar, and text).

  • The code page used to store non-Unicode character data.

    Note You cannot specify the equivalent of a code page for the Unicode data types (nchar, nvarchar, and ntext). The double-byte bit patterns used for Unicode characters are defined by the Unicode standard and cannot be changed.

SQL Server 2000 collations can be specified at many levels. When you install an instance of SQL Server 2000, you specify the default collation for that instance. Each time you create a database, you can specify the default collation used for the database. If you do not specify a collation, the default collation for the database is the default collation for the instance. Whenever you define a character column, you can specify its collation. If you do not specify a collation, the column is created with the default collation of the database. You cannot specify a collation for character variables and parameters; they are always created with the default collation of the database.

If all of the users of your instance of SQL Server speak the same language, you should pick the collation that supports that language. For example, if all of the users speak French, choose the French collation.

If the users of your instance of SQL Server speak multiple languages, you should pick a collation that best supports the requirements of the various languages. For example, if the users generally speak western European languages, choose the Latin1_General collation. When you support users who speak multiple languages, it is most important to use the Unicode data types, nchar, nvarchar, and ntext, for all character data. Unicode was designed to eliminate the code page conversion difficulties of the non-Unicode char, varchar, and text data types. Collation still makes a difference when you implement all columns using Unicode data types because it defines the sort order for comparisons and sorts of Unicode characters. Even when you store your character data using Unicode data types you should pick a collation that supports most of the users in case a column or variable is implemented using the non-Unicode data types.

A SQL Server collation defines how the database engine stores and operates on character and Unicode data. After data has been moved into an application, however, character sorts and comparisons done in the application are controlled by the Windows locale selected on the computer. The collation used for character data by applications is one of the items controlled by the Windows locale (a locale also defines other items, such as number, time, date, and currency formats). For Microsoft Windows NT® 4.0, Microsoft Windows® 98, and Microsoft Windows 95, the Windows locale is specified using the Regional Settings application in Control Panel. For Microsoft Windows 2000, the locale is specified using the Regional Options application in Control Panel. For more information about Windows locales, see Developing International Software for Windows 95 and Windows NT 4.0 in the MSDN® page at Microsoft Web site.

Multiple collations can use the same code page for non-Unicode data. For example, the 1251 code page defines a set of Cyrillic characters. This code page is used by several collations, such as Cyrillic_General, Ukrainian, and Russian. Although all of these collations use the same set of bits to represent non-Unicode character data, the sorting and comparison rules they apply are slightly different to handle the dictionary definitions of the correct sequence of characters in the language or alphabet associated with the collation.

Because SQL Server 2000 collations control both the Unicode and non-Unicode sort orders, you do not encounter problems caused by specifying different sorting rules for Unicode and non-Unicode data. In earlier versions of SQL Server, the code page number, the character sort order, and the Unicode collation are specified separately. Earlier versions of SQL Server also support varying numbers of sort orders for each code pages, and for some code pages support sort orders not available in Windows locales. In SQL Server 7.0, it is also possible to specify a Unicode sort order that is different from the sort order chosen for non-Unicode data. This can cause ordering and comparison operations to return different results when working with Unicode data as opposed to non-Unicode data.

See Also

COLLATE

Collation Options for International Support

Collations

Unicode Data

Using Unicode Data


Selecting Collations

In Microsoft® SQL Server™ 2000, you specify a single collation name that controls all three collation attributes: the Unicode sort order, the non-Unicode code page, and the non-Unicode sort order. None of the SQL Server 2000 collations allow different comparison and sorting rules for Unicode and non-Unicode character data. There are two groups of SQL Server 2000 collations: Windows collations and SQL collations.

Windows Collations

Windows collations are collations defined for SQL Server to support Microsoft Windows® locales. By specifying a Windows collation for SQL Server, the instance of SQL Server uses the same code pages and sorting and comparison rules as an application running on a computer for which you have specified the associated Windows locale. For example, the French Windows collation for SQL Server matches the collation attributes of the French locale for Windows.

There are more Windows locales than there are SQL Server Windows collations. The names of Windows locales are based on a language and territory, for example French (Canada). Several languages, however, share common alphabets and rules for sorting and comparing characters. For example, 33 Windows locales, including all of the Portuguese, and English Windows locales, use the Latin1 code page (1252) and follow a common set of rules for sorting and comparing characters. The SQL Server Windows collation based on the Latin1_General code page and sorting rules supports all 33 of these Windows locales. Also, Windows locales specify attributes not covered by SQL Server Windows collations, such as currency, date, and time formats. Because countries/regions such as the United Kingdom and the United States have different currency, date, and time formats, they require different Windows collations. They do not require different SQL Server collations because they have the same alphabet and rules for sorting and comparing characters.

SQL Collations

SQL collations are a compatibility option to match the attributes of common combinations of code page number and sort orders that have been specified in earlier versions of SQL Server. For example, for mapping a SQL Server 2000 SQL collation to what is specified in earlier versions of SQL Server, the SQL Server 2000 SQL collation SQL_Latin1_General_CP1_CI_AS matches the SQL Server version 7.0 default specification of:

  • The ISO code page 1252.

  • The dictionary order, case-insensitive character sort order.

  • The General Unicode collation.

The SQL collations available in SQL Server 2000 do not match all combinations that can be specified in earlier versions of SQL Server. For example, no SQL Server 2000 SQL collation supports a case-sensitive sort order for non-Unicode data and case-insensitive sort order for Unicode data. The earlier SQL collations that cannot be exactly specified in SQL Server 2000 are called obsolescent SQL collations.

In SQL Server 2000, you should primarily use Windows collations. You should use SQL collations only to maintain compatibility with existing instances of earlier versions of SQL Server, or to maintain compatibility in applications developed using SQL collations in earlier versions of SQL Server.

Collation Comparison and Ordering Rules

Most of the comparison and ordering rules defined in a collation are governed by the dictionary definition of the correct sequence of characters for the alphabet or language. The attributes you can control are whether comparisons and sorts of character and Unicode data should be:

  • Based on the dictionary conventions that define the correct sequence of characters in the language or alphabet associated with the collation, or based on the sequence of the binary bit patterns representing the different characters.

  • Case-sensitive or case-insensitive. For example, defining whether 'a' is equal or not equal to 'A'. If you choose case-insensitive, comparisons always ignore case, so the uppercase version of a character evaluates to being equal to the lowercase version of the character. When you choose case-insensitivity, the relative sequence in which uppercase and lowercase are sorted is undefined unless you also specify uppercase preference. Uppercase preference affects only sort operations and specifies that uppercase versions of a character come earlier in the sort sequence than lowercase versions of the same character. Uppercase preference has no affect on comparisons, so 'A' still evaluates to being equal to 'a' when uppercase preference is on. Uppercase preference can be specified only in SQL collations, not in Windows collations.

  • Sensitive or insensitive to accented characters, also known as extended characters. Accented characters are those characters that have a diacritical mark, such as the German umlaut (ë) or the Spanish tilde (~). For example, accent sensitivity defines whether 'a' is equal or not equal to 'ä'.

When you choose a collation, you can specify if you want binary behavior, or dictionary sorting that is sensitive or insensitive to case and accents:

  • In binary collations, comparisons and sorting are based strictly on the bit pattern of the characters. This is the fastest option. Because uppercase characters are stored with different bit patterns than their corresponding lowercase characters, and accented characters have different bit patterns than characters without accents, binary sort orders are always case-sensitive and accent sensitive. Binary collations also ignore dictionary sequences that have been defined for specific languages. They simply order the characters based on the relative value of the bit patterns that represent each character. While the bit patterns defined for Latin characters, such as 'A' or 'z', are such that binary sorting yields the correct results, the bit patterns for some extended characters in some code pages may be different than the ordering sequence defined in dictionaries for the language associated with a collation. This can lead to occasional ordering and comparison results that are different than what a speaker of the language might expect.

  • If you do not specify a binary collation, SQL Server uses the dictionary ordering of the collation you have chosen. Dictionary order means characters are not sorted or compared based only on their bit patterns. The collation follows the conventions of the associated language regarding the proper sequence for characters. For example, case-insensitive sort orders must use dictionary rules to determine which lowercase and uppercase bit patterns are equal.

    Although the bit patterns in a code page generally yield the correct comparison and ordering results for any language that uses the code page, the conventions for some of the languages may require different results than are generated for the bit patterns of a small number of characters. For example, the Czech, Hungarian, and Polish collations use the same code page, 1250, which was designed for the Slavic languages. Each of these languages, however, use slightly different conventions for the sequence in which accented characters should be sorted.

    If you do not specify binary sorting, all SQL Server operations follow the dictionary conventions for sorting and comparing characters. When the dictionary order is used, you can specify whether you want the collation to be sensitive or insensitive to both case and accented characters.

Case-sensitivity applies to SQL identifiers and passwords as well as to data. If you specify a binary or case-sensitive default sort order for an instance of SQL Server or database, all references to objects must use the same case with which they were created. For example, consider this table:

CREATE TABLE MyTable (PrimaryKey int PRIMARY KEY, CharColumn nchar(10))

If the CREATE TABLE statement is executed on an instance of SQL Server or database that has a case-sensitive or binary sort order, all references to the table must use the same case that was specified in the CREATE TABLE statement:

-- Object not found error because case is not correct:
SELECT * FROM MYTABLE
-- Invalid column name error because case is not correct
-- for the WHERE clause reference to the PrimaryKey column.
SELECT *
FROM MyTable
WHERE PRIMARYKEY = 123
-- Correct statement:
SELECT CharColumn
FROM MyTable
WHERE PrimaryKey = 123

See Also

Collation Options for International Support

Specifying Collations

Unicode Data

Using Unicode Data


Specifying Collations

Microsoft® SQL Server™ 2000 collations can be specified at several levels, including the following:

  • When you install an instance of SQL Server, you can specify the default collation for that instance during setup. The default collation for the instance also becomes the default collation of the system databases: master, model, tempdb, msdb, and Distribution.

  • When you create a database, you can use the COLLATE clause of the CREATE DATABASE statement to specify the default collation of the database. You can also specify a collation when you create a database using SQL Server Enterprise Manager. If you do not specify a collation, the database is assigned the default collation of the model database. The default collation of the model database is the same as the default collation of the instance of SQL Server.

  • When you create a table, you can specify collations for each character string column using the COLLATE clause of the CREATE TABLE statement. You can also specify a collation when you create a table using SQL Server Enterprise Manager. If you do not specify a collation, the column is assigned the default collation of the database.

    You can also use the database_default option in the COLLATE clause to specify that a column in a temporary table use the collation default of the current user database for the connection instead of tempdb.

  • When you specify a literal string, you can use the COLLATE clause to specify the collation. If you do not specify a collation, the literal is assigned the database default collation.

  • In SQL-DMO you can use the Collation property to specify collations for instances, databases, and columns. For more information, see Collation Property.

  • Parameters for stored procedures or functions, user-defined data types, and variables are assigned the default collation of the database:

The collation of an identifier depends on the level at which it is defined. Identifiers of instance-level objects, such as logins and database names, are assigned the default collation of the instance. Identifiers of objects within a database, such as tables, views, and column names, are assigned the default collation of the database. Variables, GOTO labels, temporary stored procedures, and temporary tables can be created when the connection context is associated with one database, and then referenced when the context has been switched to another database. Because of this, the identifiers for variables, GOTO labels, and temporary tables are in the default collation of the instance.

Specifying collations for columns or literals can be done only for the char, varchar, text, nchar, nvarchar, and ntext data types.

Collations are generally identified by a collation name. There are two classes of names: Windows collation names for the new collations aligned with Windows locales, and SQL collation names for the compatibility mode collations that result when upgrading from earlier versions of SQL Server. For more information, see Windows Collation Name), and SQL Collation Name.

The exception to specifying collation names is in Setup:

  • You do not specify a collation name for Windows collations, but instead specify the collation designator, and then select check boxes to specify binary sorting or dictionary sorting that is either sensitive or insensitive to either case or accents.

  • You do not specify SQL collation names, but instead select a collation based on a longer, more human-readable display name.

You can execute the system function fn_helpcollations to retrieve a list of all the valid collation names for Windows collations and SQL collations, for example:

SELECT *
FROM ::fn_helpcollations()

You can also use the SQL-DMO ListCollations method to get a list of the valid collation names. For more information, see ListCollations Method.

The system catalog stored procedures have been enhanced to report the collation of all SQL Server objects that have a collation.

SQL Server can support only code pages that are supported by the underlying operating system. When you perform an action that depends on collations, the SQL Server collation used by the referenced object must use a code page supported by the operating system running on the computer. These actions can include:

  • Specifying a default collation for an instance of SQL Server.

  • Specifying a default collation for a database when you create the database.

  • Restoring a database backup. Windows must support the code page of the default collation used by the database.

  • Attaching a database. Windows must support the code page of the default collation used by the database.

  • Specifying a collation for a column when creating a table.

  • Specifying a collation when creating a user-defined data type.

  • Specifying a collation when declaring a character-string constant.

If the collation specified or the collation used by the referenced object, uses a code page not supported by the Microsoft Windows® operating systems, SQL Server issues error 2775:

"Code page codepagenumber is not supported by the system."

Your response to this message depends on the version of the Windows operating system installed on the computer:

  • Microsoft Windows 2000 supports all of the code pages used by SQL Server collations, so the error message will not occur.

  • Microsoft Windows NT® 4.0 may require that you install a language pack to support some code pages. For more information about installing a Windows NT language pack, see the Windows NT Help.

  • Microsoft Windows 98 supports only one code page on a computer. You must choose a SQL Server collation that uses the same code page used by Windows 98.

See Also

ALTER TABLE

Collation Options for International Support

Collations

Constants

CREATE DATABASE

CREATE TABLE

DECLARE @local_variable

table

Using Unicode Data


Specifying the Default Collation for an Instance of SQL Server

The default collation for an instance of Microsoft® SQL Server™ 2000 is defined during setup. If you choose the minimal or typical setup options, then Setup installs these collations:

  • If you upgrade a default instance of SQL Server version 6.5 or SQL Server version 7.0 to SQL Server 2000, or if you install a default instance of SQL Server 2000 that will be version switched with a default instance of SQL Server version 6.5, SQL Server Setup carries forward the same collation used in the existing instance of SQL Server version 6.5 or SQL Server version 7.0, including obsolescent collations.

  • In all other cases, Setup chooses the Windows collation that supports the Windows locale of the computer on which the instance of SQL Server 2000 is being installed.

Note The Setup program does not set the instance default collation to the Windows collation Latin1_General_CI_AS if the computer is using the U.S. English locale. Instead, it sets the instance default collation to the SQL collation SQL_Latin1_General_Cp1_CI_AS. This may change in a future release.

If you choose the Custom setup option, Setup uses the same logic as in the minimal and typical options to set the collation that is selected when the Character Set / Sort Order / Windows Collation window is displayed. You should not use the selected collation in these cases:

  • If the instance will be included in a replication scheme, all instances of SQL Server involved in the replication scheme (Publishers, Subscribers, and Distributors) should use the same code page. You should make sure the collation selected by Setup uses the same code page as the other instances of SQL Server in the replication scheme.

  • If the primary language that the instance must support is different than the Windows locale of the computer on which the instance is being installed.

For a table showing which collation designator to specify for a Windows locale, see Windows Collation Names Table.

During setup, the master, model, tempdb, msdb, and Distribution system databases are assigned the same default collation as the default collation chosen for the instance.

See Also

Collation Options for International Support


Mixed Collation Environments

Compatibility issues can have an impact on organizations that use multiple collations to store their data. Most organizations use the same collation for all of their Microsoft® SQL Server™ 2000 databases, thereby eliminating all collation compatibility issues. Other organizations, however, must store data viewed by users who speak various languages and want to do so with a minimum of collation compatibility issues.

All character and Unicode objects (such as columns, variables, and constants) have a collation. Whenever you work with objects that have different collations and code pages, you must code your queries to comply with the rules of collation coercion. When you code a complex expression that uses operators to combine multiple simple expressions that have different collations, all of the collations must be implicitly convertible, or explicitly converted using the COLLATE clause. For more information about collation coercion, see Collation Precedence.

If you do not specify a collation in a character or Unicode expression, the default collation may vary depending on the current database setting for the connection. For example, if you do not specify a COLLATE clause on a character or Unicode constant, the constant is assigned the default collation of the current database. This means that the result of a Transact-SQL statement may have different collations when executed in the context of different databases.

If you are setting up replication, all of the databases involved in a replication network, including Publishers, Subscribers, and Distributors, must have the same code page.

The bulk copy functions, BULK INSERT, and the bcp command prompt utility support column collations. For more information, see Copying Data Between Different Collations.

Minimizing Collation Issues

If you must store character data that reflects multiple languages, you can minimize collation compatibility issues by always using the Unicode nchar, nvarchar, and ntext data types instead of the char, varchar, text data types. Using the Unicode data types eliminates code page conversion issues.

Another recommendation that minimizes collation compatibility issues is to standardize your site as either sensitive or insensitive to case and accented characters. If you always choose collations with the same case and accent sensitivity, end users experience consistent behavior across all systems. Most SQL Server 2000 sites choose to be case-insensitive and accent-sensitive. Case sensitivity also applies to the names of SQL Server objects; therefore, if you specify case-sensitive collations, all users must specify the correct case when querying the database. For example, if you have a case-sensitive server and create a table named Employees, all queries must refer to the table as Employees. References that do not use the correct case, such as EMPLOYEES or employees, are invalid.

Collations and tempdb

The tempdb database is built each time SQL Server is started, and has the same default collation as the model database, which is typically the same as the default collation of the instance. If you create a user database and specify a different default collation than model, the user database has a different default collation than tempdb. All temporary stored procedures or temporary tables are created and stored in tempdb, which means that all implicit columns in temporary tables and all coercible-default constants, variables, and parameters in temporary stored procedures have different collations than comparable objects created in permanent tables and stored procedures.

This can lead to problems with the text data type, which does not support code page conversions. For example, an instance of SQL Server 2000 defaults to the Latin1_General_CS_AS collation, and you execute these statements:

CREATE DATABASE TestDB COLLATE Estonian_CS_AS
USE TestDB
CREATE TABLE TestPermTab (PrimaryKey int PRIMARY KEY, TextCol text )

In this system, the tempdb database uses the Latin1_General_CS_AS collation with code page 1252, and TestDB and TestPermTab.TextCol use the Estonian_CS_AS collation with code page 1257. If you then execute:

USE TestDB
GO
-- Create a temporary table with the same column declarations
-- as TestPermTab
CREATE TABLE #TestTempTab (PrimaryKey int PRIMARY KEY, TextCol text )
-- This statement gets an code page conversion not allowed error
-- because the temporary table is created in tempdb, which has a
-- different default collation than TestDB.
INSERT INTO #TestTempTab
         SELECT * FROM TestPermTab
GO

To eliminate the error you can use one of these alternatives:

  • Use the Unicode data type ntext instead of text for the two TextCol columns.

  • Specify that the temporary table column use the default collation of the user database, not tempdb. This allows the temporary table to work with similarly formatted tables in multiple databases, if that is a requirement of your system.
    CREATE TABLE #TestTempTab
   (PrimaryKey int PRIMARY KEY,
    TextCol text COLLATE database_default
   )
  • Specify the correct collation for the #TestTempTab column:
    CREATE TABLE #TestTempTab
   (PrimaryKey int PRIMARY KEY,
    TextCol text COLLATE Estonian_CS_AS
   )
Collations in BACKUP and RESTORE

If you restore a database, RESTORE uses the collation of the source database that was recorded in the backup file. The restored database has the same collation as the original database that was backed up. Individual objects within the database that have different collations also retain their original collation. The database can be restored even if the instance on which you run restore has a different default collation than the instance on which BACKUP was run.

If there is already a database with the same name on the target server, the only way to restore from the backup is to specify REPLACE on the RESTORE statement. If you specify REPLACE, the existing database is completely replaced with the contents of the database on the backup file, and the restored version of the database will have the same collation recorded in the backup file.

If you are restoring log backups, the destination database must have the same collation as the source database.

Collations and text column

If you create a table with a text column that has a different code page than the code page of the database's default collation, there are only two ways you can specify data values to be inserted into the column, or update existing values. You can:

  • Specify a Unicode constant.

  • Select a value from another column with the same code page.

Assume the following database and table:

-- Create a database with a default of code page 1252.
CREATE DATABASE TestDB COLLATE Latin1_General_CS_AS
-- Create a table with a different code page, 1253.
CREATE TABLE TestTab
   (PrimaryKey int PRIMARY KEY,
    TextCol text COLLATE Greek_CS_AS
   )

-- This INSERT statement successfully inserts a Unicode string.
INSERT INTO TestTab VALUES (1, N'abc')
-- This INSERT statement successfully inserts data by selecting
-- from a similarly formatted table in another database that uses
-- uses the Greek 1253 code page as its default.
INSERT INTO TestTab
     SELECT * FROM GreekDatabase.dbo.TestTab


Changing Collations

You can change the collation of a column by using the ALTER TABLE statement:

CREATE TABLE MyTable
  (PrimaryKey   int PRIMARY KEY,
   CharCol      varchar(10) COLLATE French_CI_AS NOT NULL
  )
GO
ALTER TABLE MyTable ALTER COLUMN CharCol
            varchar(10)COLLATE Latin1_General_CI_AS NOT NULL
GO

You cannot alter the collation of a column that is currently referenced by:

  • A computed column.

  • An index.

  • Distribution statistics, either generated automatically or by the CREATE STATISTICS statement.

  • A CHECK constraint.

  • A FOREIGN KEY constraint.

You can also use the COLLATE clause on an ALTER DATABASE to change the default collation of the database:

ALTER DATABASE MyDatabase COLLATE French_CI_AS

Altering the default collation of a database does not change the collations of the columns in any existing user-defined tables. These can be changed with ALTER TABLE. The COLLATE CLAUSE on an ALTER DATABASE statement changes:

  • The default collation for the database. This new default collation is applied to all columns, user-defined data types, variables, and parameters subsequently created in the database. It is also used when resolving the object identifiers specified in SQL statements against the objects defined in the database.

  • Any char, varchar, text, nchar, nvarchar, or ntext columns in system tables to the new collation.

  • All existing char, varchar, text, nchar, nvarchar, or ntext parameters and scalar return values for stored procedures and user-defined functions to the new collation.

  • The char, varchar, text, nchar, nvarchar, or ntext system data types, and all user-defined data types based on these system data types, to the new default collation.

After a collation has been assigned to any object other than a column or database, you cannot change the collation except by dropping and re-creating the object. This can be a complex operation. To change the default collation for an instance of Microsoft® SQL Server™ 2000 you must:

  • Make sure you have all of the information or scripts needed to re-create your user databases and all of the objects in them.

  • Export all of your data using a tool such as bulk copy.

  • Drop all of the user databases.

  • Rebuild the master database specifying the new collation.

  • Create all of the databases and all of the objects in them.

  • Import all of your data.

    Note Instead of changing the default collation of an instance of SQL Server 2000, you can specify a default collation for each new database you create.


SQL Indexes

A Microsoft® SQL Server™ 2000 index is a structure associated with a table or view that speeds retrieval of rows from the table or view. An index contains keys built from one or more columns in the table or view. These keys are stored in a structure that allows SQL Server to find the row or rows associated with the key values quickly and efficiently.


Table Indexes

Microsoft® SQL Server™ 2000 supports indexes defined on any column in a table, including computed columns.

If a table is created with no indexes, the data rows are not stored in any particular order. This structure is called a heap.

The two types of SQL Server indexes are:

  • Clustered

    Clustered indexes sort and store the data rows in the table based on their key values. Because the data rows are stored in sorted order on the clustered index key, clustered indexes are efficient for finding rows. There can only be one clustered index per table, because the data rows themselves can only be sorted in one order. The data rows themselves form the lowest level of the clustered index.

    The only time the data rows in a table are stored in sorted order is when the table contains a clustered index. If a table has no clustered index, its data rows are stored in a heap.

  • Nonclustered

    Nonclustered indexes have a structure completely separate from the data rows. The lowest rows of a nonclustered index contain the nonclustered index key values and each key value entry has pointers to the data rows containing the key value. The data rows are not stored in order based on the nonclustered key.

    The pointer from an index row in a nonclustered index to a data row is called a row locator. The structure of the row locator depends on whether the data pages are stored in a heap or are clustered. For a heap, a row locator is a pointer to the row. For a table with a clustered index, the row locator is the clustered index key.

The only time the rows in a table are stored in any specific sequence is when a clustered index is created on the table. The rows are then stored in sequence on the clustered index key. If a table only has nonclustered indexes, its data rows are stored in a unordered heap.

Indexes can be unique, which means no two rows can have the same value for the index key. Otherwise, the index is not unique and multiple rows can share the same key value.

There are two ways to define indexes in SQL Server. The CREATE INDEX statement creates and names an index. The CREATE TABLE statement supports the following constraints that create indexes:

  • PRIMARY KEY creates a unique index to enforce the primary key.

  • UNIQUE creates a unique index.

  • CLUSTERED creates a clustered index.

  • NONCLUSTERED creates a nonclustered index.

When you create an index on SQL Server 2000, you can specify whether the keys are stored in ascending or descending order.

SQL Server 2000 supports indexes defined on computed columns, as long as the expression defined for the column meets certain restrictions, such as only referencing columns from the table containing the computed column, and being deterministic.

A fill factor is a property of a SQL Server index that controls how densely the index is packed when created. The default fill factor usually delivers good performance, but in some cases it may be beneficial to change the fill factor. If the table is going to have many updates and inserts, create an index with a low fill factor to leave more room for future keys. If the table is a read-only table that will not change, create the index with a high fill factor to reduce the physical size of the index, which lowers the number of disk reads SQL Server uses to navigate through the index. Fill factors are only applied when the index is created. As keys are inserted and deleted, the index will eventually stabilize at a certain density.

Indexes not only speed up the retrieval of rows for selects, they also usually increase the speed of updates and deletes. This is because SQL Server must first find a row before it can update or delete the row. The increased efficiency of using the index to locate the row usually offsets the extra overhead needed to update the indexes, unless the table has a lot of indexes.

This example shows the Transact-SQL syntax for creating indexes on a table.

USE pubs
GO
CREATE TABLE emp_sample
   (emp_id      int         PRIMARY KEY CLUSTERED,
   emp_name      char(50),
   emp_address   char(50),
   emp_title   char(25)      UNIQUE NONCLUSTERED )
GO
CREATE NONCLUSTERED INDEX sample_nonclust ON emp_sample(emp_name)
GO

Deciding which particular set of indexes will optimize performance depends on the mix of queries in the system. Consider the clustered index on emp_sample.emp_id. This works well if most queries referencing emp_sample have equality or range comparisons on emp_id in their WHERE clauses. If the WHERE clauses of most queries reference emp_name instead of emp_id, performance could be improved by instead making the index on emp_name the clustered index.

Many applications have a complex mix of queries that is difficult to estimate by interviewing users and programmers. SQL Server 2000 provides an Index Tuning Wizard to help design indexes in a database. The easiest way to design indexes for large schemas with complex access patterns is to use the Index Tuning Wizard.

You provide the Index Tuning Wizard with a set of SQL statements. This could be a script of statements you build to reflect a typical mix of statements in the system, but it is usually a SQL Profiler trace of the actual SQL statements processed on the system during a period of time that reflects the typical load on the system. The Index Tuning Wizard analyzes the workload and the database, and then recommends an index configuration that will improve the performance of the workload. You can choose to either replace the existing index configuration, or to keep the existing index configuration and implement new indexes to improve the performance of a slow-running subset of the queries.

See Also

Indexes

Parallel Operations Creating Indexes


View Indexes

Microsoft® SQL Server™ 2000 supports defining indexes on views. Views are sometimes called virtual tables because the result set returned by the view has the same general form as a table with columns and rows, and views can be referenced the same way as tables in SQL statements. The result set of a non-indexed view is not stored permanently in the database. Each time a query references the view, SQL Server dynamically merges the logic needed to build the view result set into the logic needed to build the complete query result set from the data in the base tables. The process of building the view results is called materializing the view. For more information, see View Resolution.

For a nonindexed view, the overhead of dynamically building the result set for each query that references a view can be substantial for views that involve complex processing of large numbers of rows. Examples include views that aggregate large amounts of data, or join many rows. If such views are frequently referenced in queries, you can improve performance by creating a unique clustered index on the view. When a unique clustered index is created on a view, the view is executed and the result set is stored in the database in the same way a table with a clustered index is stored. For more information about the structure used to store clustered indexes, see Clustered Indexes.

Another benefit of creating an index on a view is that the optimizer starts using the view index in queries that do not directly name the view in the FROM clause. Existing queries can benefit from the improved efficiency of retrieving data from the indexed view without having to be recoded.

Creating a clustered index on a view stores the result set built at the time the index is created. An indexed view also automatically reflects modifications made to the data in the base tables after the index is created, the same way an index created on a base table does. As modifications are made to the data in the base tables, the data modifications are also reflected in the data stored in the indexed view. The requirement that the view's clustered index be unique improves the efficiency with which SQL Server can find the rows in the index that are affected by any data modification.

You must have set specific SET options before you can create an index on a view. The query optimizer will not consider the index for any subsequent SQL statements unless the connection executing the statement has the same option settings. For more information, see SET Options That Affect Results.

Indexed views can be more complex to maintain than indexes on base tables. You should create indexes only on views where the improved speed in retrieving results outweighs the increased overhead of making modifications. This usually occurs for views mapped over relatively static data, that process many rows, and are referenced by many queries.

The first index created on a view must be a unique clustered index. After the unique clustered index has been created, you can create additional nonclustered indexes. The naming conventions for indexes on views are the same as for indexes on tables. The only difference is that the table name is replaced with a view name.

All indexes on a view are dropped if the view is dropped. All nonclustered indexes on the view are dropped if the clustered index is dropped. Nonclustered indexes can be dropped individually. Dropping the clustered index on the view removes the stored result set, and the optimizer returns to processing the view like a standard view.

Although only the columns that make up the clustered index key are specified in the CREATE UNIQUE CLUSTERED INDEX statement, the complete result set of the view is stored in the database. As in a clustered index on a base table, the b-tree structure of the clustered index contains only the key columns, but the data rows contain all of the columns in the view result set.

See Also

CREATE INDEX

Creating an Indexed View

Resolving Indexes on Views


Maximum Size of Index Keys

Microsoft® SQL Server™ 2000 retains the 900-byte limit for the maximum size of an index key but changes the algorithm used by CREATE INDEX to check if the specified index key exceeds the maximum allowable key size of 900 bytes. The new CREATE INDEX algorithm is similar to the row size algorithm used for CREATE TABLE.

Microsoft SQL Server version 7.0 and earlier always used the maximum size of variable columns when checking whether the key specified in a CREATE INDEX statement exceeded 900 bytes, for example:

CREATE TABLE TestTable
    (PrimaryKey      int PRIMARY KEY,
     VarCharCol1     varchar(500),
     VarCharCol2     varchar(500)
    )
-- This statement fails because the maximum sizes
-- of the two columns exceeds 900 bytes:
CREATE INDEX TestIdx ON TestTable(VarCharCol1, VarCharCol2)

In SQL Server 2000, the preceding CREATE INDEX statement succeeds with a warning message, unless one or more rows of data will generate a key whose value exceeds 900 bytes.

The SQL Server 2000 CREATE INDEX statement uses these algorithms:

  • If the size of all fixed columns plus the maximum size of all variable columns specified in the CREATE INDEX statement is less than 900 bytes, the CREATE INDEX statement completes successfully with no warnings or errors.

  • If the size of all fixed columns plus the maximum size of all variable columns exceeds 900, but the size of all fixed columns plus the minimums of the variable columns is less than 900, the CREATE INDEX statement succeeds with a warning that a subsequent INSERT or UPDATE statement may fail if it specifies values that generates a key value larger than 900 bytes. The CREATE INDEX statement fails if existing data rows in the table have values that generate a key larger than 900 bytes. A subsequent INSERT or UPDATE statement that specifies data values that generates a key value longer than 900 bytes fails.

  • The CREATE INDEX statement fails if the size of all fixed columns plus the minimum size of all variable columns specified in the CREATE INDEX statement exceeds 900 bytes.

This table shows the results of creating indexes where the keys contain only fixed or only variable-length columns.

Index Columns |  |  |  |  |
Size of the fixed-data column(s) | Maximum size of variable-length column(s) | MAX of the SUM of the index key column lengths* | Index created | Message | INSERT or UPDATE run-time error due to oversized index key value
> 900 bytes | None | Not relevant | No | Error | No index present to generate error.
< = 900 bytes | None | Not relevant | Yes | None | No
None | < = 900 bytes | Not relevant | Yes | None | No
None | > 900 bytes | > 900 bytes | No | Error | No index present to generate error.
None | > 900 bytes | < = 900 bytes | Yes | Warning | Only if the sum of current lengths of all index columns is greater than 900 bytes.

* None of the rows in the table at time the CREATE INDEX statement is executed can have index key values whose total lengths exceed 900 bytes.

This table shows the results of creating indexes where the keys contain a mixture of fixed and variable-length columns.

Index Columns |  |  |  |  |
Minimum size of variable-length column(s) + Size of the fixed-data column(s) | Maximum size of variable-length column(s) + Size of the fixed-data column(s) | MAX of the SUM of the index key column lengths * | Index created | Message | INSERT or UPDATE run-time error due to oversized index key value
> 900 bytes | Not relevant | Not relevant | No | Error | No index present to generate error.
< = 900 bytes | < = 900 bytes | Not relevant | Yes | None | No.
< = 900 bytes | > 900 bytes | < = 900 bytes | Yes | Warning | Only if the sum of current lengths of all index columns is greater than 900 bytes.
<= 900 bytes | > 900 bytes | > 900 bytes | No | Error | No index present to generate error.

* None of the rows in the table at time the CREATE INDEX statement is executed can have index key values whose total lengths exceed 900 bytes.

See Also

CREATE INDEX


Property Management

Microsoft® SQL Server™ 2000 introduces extended properties that users can define on various objects in a database. These extended properties can be used to store application-specific or site-specific information about the database objects. Because the property is stored in the database, all applications reading the property can evaluate the object in the same way. This helps enforce consistency in how data is treated by all of the programs in the system.

Each extended property has a user-defined name and value. The value of an extended property is a sql_variant that can contain up to 7500 bytes of data. Individual database objects can have multiple extended properties.

Extended properties are managed using three system stored procedures: sp_addextendedproperty, sp_updateextendedproperty, and sp_dropextendedproperty. You can read the value of an existing extended property using the system function FN_LISTEXTENDEDPROPERTY.

There is no convention or standard for defining extended properties. The database designer sets the rules specifying the property names and contents when the database is designed, and then the applications accessing the database have to be coded to follow those rules or conventions.

See Also

Using Extended Properties on Database Objects

fn_listextendedproperty

sp_addextendedproperty

sp_dropextendedproperty

sp_updateextendedproperty


Full-Text Catalogs and Indexes

A Microsoft® SQL Server™ 2000 full-text index provides efficient support for sophisticated word searches in character string data. The full-text index stores information about significant words and their location within a given column. This information is used to quickly complete full-text queries that search for rows with particular words or combinations of words.

Full-text indexes are contained in full-text catalogs. Each database can contain one or more full-text catalogs. A catalog cannot belong to multiple databases and each catalog can contain full-text indexes for one or more tables. A table can only have one full-text index, so each table with a full-text index belongs to only one full-text catalog.

Full-text catalogs and indexes are not stored in the database to which they belong. The catalogs and indexes are managed separately by the Microsoft Search service.

A full-text index must be defined on a base table; it cannot be defined on a view, system table, or temporary table. A full-text index definition includes:

  • A column that uniquely identifies each row in the table (primary or candidate key) and does not allow NULLs.

  • One or more character string columns covered by the index.

The full-text index is populated with the key values. The entry for each key has information about the significant words (noise-words or stop-words are stripped out) that are associated with the key, the column they are in, and their location in the column.

Formatted text strings, such as Microsoft® Word™ document files or HTML files, cannot be stored in character string or Unicode columns because many of the bytes in these files contain data structures that do not form valid characters. Database applications may still have a need to access this data and apply full-text searches to it. Many sites store this type of data in image columns, because image columns do not require that each byte form a valid character. SQL Server 2000 introduces the ability to perform full-text searches against these types of data stored in image columns. SQL Server 2000 supplies filters that allow it to extract the textual data from Microsoft Office™ files (.doc, .xls, and .ppt files), text files (.txt files), and HTML files (.htm files). When you design the table, in addition to the image column that holds the data, you include a binding column to hold the file extension for the format of data stored in the image column. You can create a full-text index that references both the image column and the binding column to enable full-text searches on the textual information stored in the image column. The SQL Server 2000 full-text search engine uses the file extension information from the binding column to select the proper filter to extract the textual data from the column.

Full-text indexing is the component that implements two Transact-SQL predicates for testing rows against a full-text search condition:

  • CONTAINS

  • FREETEXT

Transact-SQL also has two functions that return a set of rows that match a full-text search condition:

  • CONTAINSTABLE

  • FREETEXTTABLE

Internally, SQL Server sends the search condition to the Microsoft Search service. The Microsoft Search service finds all the keys that match the full-text search condition and returns them to SQL Server. SQL Server then uses the list of keys to determine which table rows are to be processed.

See Also

Full-text Indexes

Full-Text Query Architecture

Full-text Querying SQL Server Data

Microsoft Search Service


Logins, Users, Roles, and Groups

Logins, users, roles, and groups are the foundation for the security mechanisms of Microsoft® SQL Server™ 2000. Users that connect to SQL Server must identify themselves using a specific login identifier (ID). Users can then only see the tables and views they are authorized to see, and can only execute the stored procedures and administrative functions they are authorized to execute. This system of security is based on the IDs used to identify users.

See Also

Managing Security


Logins

New Information - SQL Server 2000 SP3.

Login identifiers (IDs) are associated with users when they connect to an instance of Microsoft® SQL Server™ 2000. Login IDs are the accounts that control access to the instance of SQL Server. A user cannot connect to an instance without first specifying a valid login ID. Members of the sysadmin fixed server role define login IDs. There are two types of logins that can be defined for instances of SQL Server:

  • sp_grantlogin authorizes a Microsoft Windows® network account (either a group or a user account) to be used as a SQL Server login for connecting to SQL Server using Windows Authentication. The user does not have to specify a login when connecting to the instance of SQL Server. SQL Server uses the Windows account to validate the connection request.

  • sp_addlogin defines a login account for SQL Server connections using SQL Server Authentication. The user must supply a SQL Server login account and password when connecting to the instance of SQL Server.

Security Note When possible, use Windows Authentication.

See Also

Logins

sp_addlogin

sp_grantlogin


Users

New Information - SQL Server 2000 SP3.

A user identifier (ID) identifies a user within a database. All permissions and ownership of objects in the database are controlled by the user account. User accounts are specific to a database; the xyz user account in the sales database is different from the xyz user account in the inventory database, even though both accounts have the same ID. User IDs are defined by members of the db_owner fixed database role.

A login ID by itself does not give a user permissions to access objects in any databases. A login ID must be associated with a user ID in each database before anyone connecting with that login ID can access objects in the databases. If a login ID has not been explicitly associated with any user ID in a database, it is associated with the guest user ID. If a database has no guest user account, a login cannot access the database unless it has been associated with a valid user account.

When a user ID is defined, it is associated with a login ID. For example, a member of the db_owner role can associate the Microsoft® Windows® 2000 login NETDOMAIN\Joe with user ID abc in the sales database and user ID def in the employee database. The default is for the login ID and user ID to be the same.

This example shows giving a Windows 2000 account access to a database and associating the login with a user in the database:

USE master
GO
sp_grantlogin 'NETDOMAIN\Sue'
GO
sp_defaultdb @loginame = 'NETDOMAIN\Sue', defdb = 'sales'
GO
USE sales
GO
sp_grantdbaccess 'NETDOMAIN\Sue', 'Sue'
GO

In the sp_grantlogin statement, the Windows 2000 user NETDOMAIN\Sue is given access to Microsoft SQL Server™ 2000. The sp_defaultdb statement makes the sales database her default database. The sp_grantdbaccess statement gives the login NETDOMAIN\Sue access to the sales database and sets her user ID within sales to Sue.

This example shows defining a SQL Server login, assigning a default database, and associating the login with a user in the database:

USE master
GO
sp_addlogin @loginame = 'Joan', @password = 'fff', defdb = 'sales'
GO
USE sales
GO
sp_grantdbaccess 'Joan'
GO

Security Note Batch files may contain credentials stored in plain text. Credentials may be echoed to the user's screen during batch execution.

The sp_addlogin statement defines a SQL Server login for a worker named Joan. The statement also specifies the sales database as the default database for the login. The sp_grantdbaccess statement grants the Joan login access to the sales database; because no username is specified, it defaults to Joan.

A user in a database is identified by their user ID, not their login ID. For example, sa is a login account mapped to the special user account dbo (database owner) in every database. All the security-related Transact-SQL statements use the user ID as the security_name parameter. The administration and understanding of permissions is less confusing if the members of the sysadmin fixed server role and the db_owner fixed database role set up the system such that the login ID and user ID of each user are the same, but it is not a requirement.

The guest account is a special user account in SQL Server databases. If a user enters a USE database statement to access a database in which they are not associated with a user account, they are instead associated with the guest user.

See Also

guest User

sp_addlogin

sp_defaultdb

sp_grantdbaccess

sp_grantlogin


Roles

Roles are a powerful tool that allow you to collect users into a single unit against which you can apply permissions. Permissions granted to, denied to, or revoked from a role also apply to any members of the role. You can establish a role that represents a job performed by a class of workers in your organization and grant the appropriate permissions to that role. As workers rotate into the job, you simply add them as a member of the role; as they rotate out of the job, remove them from the role. You do not have to repeatedly grant, deny, and revoke permissions to or from each person as they accept or leave the job. The permissions are applied automatically when the users become members of the role.

Microsoft® Windows NT® and Windows® 2000 groups can be used in much the same way as roles. For more information, see Groups.

It is easy to manage the permissions in a database if you define a set of roles based on job functions and assign each role the permissions that apply to that job. You can then simply move users between roles rather than having to manage the permissions for each individual user. If the function of a job changes, it is easier to simply change the permissions once for the role and have the changes applied automatically to all members of the role.

In Microsoft® SQL Server™ 2000 and SQL Server version 7.0, users can belong to multiple roles.

The following script shows adding a few logins, users, and roles, and granting permissions to the roles.

USE master
GO
sp_grantlogin 'NETDOMAIN\John'
GO
sp_defaultdb 'NETDOMAIN\John', 'courses'
GO
sp_grantlogin 'NETDOMAIN\Sarah'
GO
sp_defaultdb 'NETDOMAIN\Sarah', 'courses'
GO
sp_grantlogin 'NETDOMAIN\Betty'
GO
sp_defaultdb 'NETDOMAIN\Betty', 'courses'
GO
sp_grantlogin 'NETDOMAIN\Ralph'
GO
sp_defaultdb 'NETDOMAIN\Ralph', 'courses'
GO
sp_grantlogin 'NETDOMAIN\Diane'
GO
sp_defaultdb 'NETDOMAIN\Diane', 'courses'
GO
USE courses
GO
sp_grantdbaccess 'NETDOMAIN\John'
GO
sp_grantdbaccess 'NETDOMAIN\Sarah'
GO
sp_grantdbaccess 'NETDOMAIN\Betty'
GO
sp_grantdbaccess 'NETDOMAIN\Ralph'
GO
sp_grantdbaccess 'NETDOMAIN\Diane'
GO
sp_addrole 'Professor'
GO
sp_addrole 'Student'
GO
sp_addrolemember 'Professor', 'NETDOMAIN\John'
GO
sp_addrolemember 'Professor', 'NETDOMAIN\Sarah'
GO
sp_addrolemember 'Professor', 'NETDOMAIN\Diane'
GO
sp_addrolemember 'Student', 'NETDOMAIN\Betty'
GO
sp_addrolemember 'Student', 'NETDOMAIN\Ralph'
GO
sp_addrolemember 'Student', 'NETDOMAIN\Diane'
GO
GRANT SELECT ON StudentGradeView TO Student
GO
GRANT SELECT, UPDATE ON ProfessorGradeView TO Professor
GO

This script gives the professors John and Sarah permission to update students' grades, while the students Betty and Ralph can only select their grades. Diane has been added to both roles because she is teaching one class while taking another. The view ProfessorGradeView should restrict professors to the rows for students in their classes, while StudentGradeView should restrict students to selecting only their own grades.

There are several fixed roles defined in SQL Server 2000 and SQL Server version 7.0 during setup. Users can be added to these roles to pick up the associated administration permissions. These are server-wide roles.

Fixed server role | Description
sysadmin | Can perform any activity in SQL Server.
serveradmin | Can set serverwide configuration options, shut down the server.
setupadmin | Can manage linked servers and startup procedures.
securityadmin | Can manage logins and CREATE DATABASE permissions, also read error logs and change passwords.
processadmin | Can manage processes running in SQL Server.
dbcreator | Can create, alter, and drop databases.
diskadmin | Can manage disk files.
bulkadmin | Can execute BULK INSERT statements.

You can get a list of the fixed server roles from sp_helpsrvrole, and get the specific permissions for each role from sp_srvrolepermission.

Each database has a set of fixed database roles. While roles with the same names exist in each database, the scope of an individual role is only within a specific database. For example, if Database1 and Database2 both have user IDs named UserX, adding UserX in Database1 to the db_owner fixed database role for Database1 has no effect on whether UserX in Database2 is a member of the db_owner role for Database2.

Fixed database role | Description
db_owner | Has all permissions in the database.
db_accessadmin | Can add or remove user IDs.
db_securityadmin | Can manage all permissions, object ownerships, roles and role memberships.
db_ddladmin | Can issue ALL DDL, but cannot issue GRANT, REVOKE, or DENY statements.
db_backupoperator | Can issue DBCC, CHECKPOINT, and BACKUP statements.
db_datareader | Can select all data from any user table in the database.
db_datawriter | Can modify any data in any user table in the database.
db_denydatareader | Cannot select any data from any user table in the database.
db_denydatawriter | Cannot modify any data in any user table in the database.

You can get a list of the fixed database roles from sp_helpdbfixedrole, and get the specific permissions for each role from sp_dbfixedrolepermission.

Every user in a database belongs to the public database role. If you want everyone in a database to be able to have a specific permission, assign the permission to the public role. If a user has not been specifically granted permissions on an object, they use the permissions assigned to public.

See Also

Adding a Member to a Predefined Role

sp_dbfixedrolepermission

sp_helpdbfixedrole

sp_helpsrvrole

sp_srvrolepermission


Groups

There are no groups in Microsoft® SQL Server™ 2000 or SQL Server version 7.0. You can, however, manage SQL Server security at the level of an entire Microsoft Windows NT® or Microsoft Windows® 2000 group.

If you use sp_grantlogin and specify the name of a Windows NT or Windows 2000 group, all members of the group can then connect to SQL Server using Windows Authentication.

After the group has been authorized to connect, you can use sp_grantdbaccess to associate the group members with a user identifier (ID) in each database they need to access. You can use two methods:

  • Associate the group with a user ID in the database.

    In this case, all members of the group will be associated with that user ID when they reference the database.

  • Associate an individual user account in the Windows NT or Windows 2000 group with a user ID in the database.

    This individual will be associated with the user ID when they reference the database. None of the other individuals in the group will be associated with the user ID. They will be assigned the user ID associated with the group login.

Consider a Windows NT or Windows 2000 group NETDOMAIN\Managers with three members: NETDOMAIN\Sue, NETDOMAIN\Fred, and NETDOMAIN\Mary. The following Transact-SQL statements add the Windows NT or Windows 2000 group as both a login and a user in the sales database, and then associate NETDOMAIN\Sue with a specific user ID:

USE master
GO
-- Authorize all members of NETDOMAIN\Managers to connect
-- using Windows Authentication.
sp_grantlogin 'NETDOMAIN\Managers'
GO
-- Make sales the default database for all members.
sp_defaultdb 'NETDOMAIN\Managers', 'sales'
USE sales
GO
-- Grant all members of the group access to sales
-- No user ID is specified, so SQL Server creates
-- one named 'NETDOMAIN\Managers'
sp_grantdbaccess 'NETDOMAIN\Managers'
GO
-- Grant a specific member of the group access to
-- sales with a specific user.
sp_grantdbaccess 'NETDOMAIN\Sue', 'Sue'

Permissions can now be granted to either user NETDOMAIN\Managers or user Sue:

USE sales
GO
GRANT SELECT ON SalesTable TO NETDOMAIN\Managers
GO
GRANT UPDATE ON SalesTable to NETDOMAIN\Sue

The permissions applied to NETDOMAIN\Sue are the union of the permissions granted, revoked, or denied to both the NETDOMAIN\Managers or Sue users. Any DENY permission overrides any corresponding GRANT permissions.

Unless their Windows NT or Windows 2000 account has been associated with a specific user, members of a group are subject to the permissions assigned to the user associated with the group. If a member of the group creates an object, however, the owner name of the object is their Windows NT or Windows 2000 account name, not the group name. Consider the NETDOMAIN\Manager account. If NETDOMAIN\Fred connects to the sales database, he can see all tables for which NETDOMAIN\Managers has been granted SELECT permission. If NETDOMAIN\Fred executes the following statement, the table is created as sales.NETDOMAIN\Fred.TableX, not sales.NETDOMAIN\Managers.TableX:

CREATE TableX (cola INT PRIMARY KEY, colb CHARACTER(200))

See Also

sp_grantdbaccess

sp_grantlogin


Owners and Permissions

Every object in Microsoft® SQL Server™ 2000 is owned by a user. The owner is identified by a database user identifier (ID). When an object is first created, the only user ID that can access the object is the user ID of the owner or creator. For any other user to access the object, the owner must grant permissions to that user. If the owner wants only specific users to access the object, the owner can grant permissions to those specific users.

For tables and views, the owner can grant INSERT, UPDATE, DELETE, SELECT, and REFERENCES permissions, or ALL permissions. A user must have INSERT, UPDATE, DELETE, or SELECT permissions on a table before they can specify it in INSERT, UPDATE, DELETE, or SELECT statements. The REFERENCES permission lets the owner of another table use columns in your table as the target of a REFERENCES FOREIGN KEY constraint from their table. The following example illustrates granting SELECT permissions to a group named Teachers and REFERENCES permissions to another development user:

GRANT SELECT ON MyTable TO Teachers
GRANT REFERENCES (PrimaryKeyCol) ON MyTable to DevUser1

The owner of a stored procedure can grant EXECUTE permissions for the stored procedure. If the owner of a base table wants to prevent users from accessing the table directly, they can grant permissions on views or stored procedures referencing the table, but not grant any permissions on the table itself. This is the foundation of the SQL Server mechanisms to ensure that users do not see data they are not authorized to access.

Users can also be granted statement permissions. Some statements, such as CREATE TABLE and CREATE VIEW, can only be executed by certain users (in this case, the dbo user). If the dbo wants another user to be able to create tables or views, they must grant the permission to execute these statements to that user.


Session Context Information

Microsoft® SQL Server™ 2000 introduces the ability to programmatically associate up to 128 bytes of binary information with the current session or connection. Session context information enables applications to set binary values that can be referenced in multiple batches, stored procedures, triggers, or user-defined functions operating on the same session, or connection. You can set a session context by using the new SET CONTEXT_INFO statement, and then you can retrieve the context string from the new context_info column in the master.dbo.sysprocesses table.

Session context information differs from Transact-SQL variables, whose scope is limited to the current batch, stored procedure, trigger, or function. Session context information can be used to store information specific to each user or the current state of the application, which can then be used to control the logic in Transact-SQL statements.

The SET CONTEXT_INFO statement supports:

  • A constant, with a maximum of 128 bytes, that is either binary or a data type that can be implicitly converted to binary.

  • The name of a varbinary(128) or binary(128) variable.

SET CONTEXT_INFO cannot be specified in a user-defined function. You cannot supply a null value to SET CONTEXT_INFO because the sysprocesses table, where the information is stored, does not allow null values.

To get the current session context for the current connection, select the context_info column from the master.dbo.sysprocesses row whose SQL Server Process ID (SPID) is equal to the SPID for the connection. The SPID for the current connection is returned by the @@SPID function:

SELECT context_info
FROM master.dbo.sysprocesses
WHERE spid = @@SPID

The value in the context_info column is initialized to 128 bytes of binary zeros if SET CONTEXT_INFO has not yet been executed for the current connection. If SET CONTEXT_INFO has been executed, the context_info column contains the value set by the last execution of SET CONTEXT_INFO for the current connection. The context_info column is a varbinary(128) column.

This is an example of using session context information:

-- Set context information at start.
SET CONTEXT_INFO 0x1256698456
GO
-- Perform several non-related batches.
sp_who
GO
USE Northwind
GO
SELECT CustomerID
FROM Customers
WHERE City = 'London'
GO
-- Select context information set several batches earlier.
SELECT context_info
FROM master.dbo.sysprocesses
WHERE spid = @@spid
GO

SET CONTEXT_INFO does not support referencing expressions other than constants or variable names, such as functions. If you need to set the context information to the result of a function call, you must first place the function call result in a binary or varbinary variable:

DECLARE @BinVar varbinary(128)
SET @BinVar = CAST( REPLICATE( 0x20, 128 ) AS varbinary(128) )
SET CONTEXT_INFO @BinVar

See Also

SET CONTEXT_INFO

sysprocesses


Relational Database Components

The database component of Microsoft® SQL Server™ 2000 is a Structured Query Language (SQL)–based, scalable, relational database with integrated Extensible Markup Language (XML) support for Internet applications. Each of the following terms describes a fundamental part of the architecture of the SQL Server 2000 database component:

Database

A database is similar to a data file in that it is a storage place for data. Like a data file, a database does not present information directly to a user; the user runs an application that accesses data from the database and presents it to the user in an understandable format.

Database systems are more powerful than data files in that data is more highly organized. In a well-designed database, there are no duplicate pieces of data that the user or application must update at the same time. Related pieces of data are grouped together in a single structure or record, and relationships can be defined between these structures and records.

When working with data files, an application must be coded to work with the specific structure of each data file. In contrast, a database contains a catalog that applications use to determine how data is organized. Generic database applications can use the catalog to present users with data from different databases dynamically, without being tied to a specific data format.

A database typically has two main parts: first, the files holding the physical database and second, the database management system (DBMS) software that applications use to access data. The DBMS is responsible for enforcing the database structure, including:

  • Maintaining relationships between data in the database.

  • Ensuring that data is stored correctly, and that the rules defining data relationships are not violated.

  • Recovering all data to a point of known consistency in case of system failures.

Relational Database

Although there are different ways to organize data in a database, relational databases are one of the most effective. Relational database systems are an application of mathematical set theory to the problem of effectively organizing data. In a relational database, data is collected into tables (called relations in relational theory).

A table represents some class of objects that are important to an organization. For example, a company may have a database with a table for employees, another table for customers, and another for stores. Each table is built of columns and rows (called attributes and tuples in relational theory). Each column represents some attribute of the object represented by the table. For example, an Employee table would typically have columns for attributes such as first name, last name, employee ID, department, pay grade, and job title. Each row represents an instance of the object represented by the table. For example, one row in the Employee table represents the employee who has employee ID 12345.

When organizing data into tables, you can usually find many different ways to define tables. Relational database theory defines a process called normalization, which ensures that the set of tables you define will organize your data effectively.

Scalable

SQL Server 2000 supports having a wide range of users access it at the same time. An instance of SQL Server 2000 includes the files that make up a set of databases and a copy of the DBMS software. Applications running on separate computers use a SQL Server 2000 communications component to transmit commands over a network to the SQL Server 2000 instance. When an application connects to an instance of SQL Server 2000, it can reference any of the databases in that instance that the user is authorized to access. The communication component also allows communication between an instance of SQL Server 2000 and an application running on the same computer. You can run multiple instances of SQL Server 2000 on a single computer.

SQL Server 2000 is designed to support the traffic of the largest Web sites or enterprise data processing systems. Instances of SQL Server 2000 running on large, multiprocessor servers are capable of supporting connections to thousands of users at the same time. The data in SQL Server tables can be partitioned across multiple servers, so that several multiprocessor computers can cooperate to support the database processing requirements of extremely large systems. These groups of database servers are called federations.

Although SQL Server 2000 is designed to work as the data storage engine for thousands of concurrent users who connect over a network, it is also capable of working as a stand-alone database directly on the same computer as an application. The scalability and ease-of-use features of SQL Server 2000 allow it to work efficiently on a single computer without consuming too many resources or requiring administrative work by the stand-alone user. The same features allow SQL Server 2000 to dynamically acquire the resources required to support thousands of users, while minimizing database administration and tuning. The SQL Server 2000 relational database engine dynamically tunes itself to acquire or free the appropriate computer resources required to support a varying load of users accessing an instance of SQL Server 2000 at any specific time. The SQL Server 2000 relational database engine has features to prevent the logical problems that occur if a user tries to read or modify data currently used by others.

Structured Query Language

To work with data in a database, you have to use a set of commands and statements (language) defined by the DBMS software. Several different languages can be used with relational databases; the most common is SQL. The American National Standards Institute (ANSI) and the International Standards Organization (ISO) define software standards, including standards for the SQL language. SQL Server 2000 supports the Entry Level of SQL-92, the SQL standard published by ANSI and ISO in 1992. The dialect of SQL supported by Microsoft SQL Server is called Transact-SQL (T-SQL). T-SQL is the primary language used by Microsoft SQL Server applications.

Extensible Markup Language

XML is the emerging Internet standard for data. XML is a set of tags that can be used to define the structure of a hypertext document. XML documents can be easily processed by the Hypertext Markup Language, which is the most important language for displaying Web pages.

Although most SQL statements return their results in a relational, or tabular, result set, the SQL Server 2000 database component supports a FOR XML clause that returns results as an XML document. SQL Server 2000 also supports XPath queries from Internet and intranet applications. XML documents can be added to SQL Server databases, and the OPENXML clause can be used to expose data from an XML document as a relational result set.


Database Applications and Servers

Microsoft® SQL Server™ 2000 is designed to work effectively as:

  • A central database on a server shared by many users who connect to it over a network. The number of users can range from a handful in one workgroup, to thousands of employees in a large enterprise, to hundreds of thousands of Web users.

  • A desktop database that services only applications running on the same desktop.
Server Database Systems

Server-based systems are constructed so that a database on a central computer, known as a server, is shared among multiple users. Users access the server through an application:

  • In a multitier system, such as Windows® DNA, the client application logic is run in two or more locations:
    • A thin client is run on the user's local computer and is focused on displaying results to the user.

    • The business logic is located in server applications running on a server. Thin clients request functions from the server application, which is itself a multithreaded application capable of working with many concurrent users. The server application is the one that opens connections to the database server. The server application can be running on the same server as the database, or it can connect across the network to a separate server operating as a database server. In complex systems, the business logic may be implemented in several interconnected server applications, or in multiple layers of server applications.

      This is a typical scenario for an Internet application. For example, a multithreaded server application can run on a Microsoft® Internet Information Services (IIS) server and service thousands of thin clients running on the Internet or an intranet. The server application uses a pool of connections to communicate with one or more instances of SQL Server 2000. The instances of SQL Server 2000 can be on the same computer as IIS, or they can be on separate servers in the network.

  • In a two-tier client/server system, users run an application on their local computer, known as a client application, that connects over a network to an instance of SQL Server 2000 running on a server computer. The client application runs both business logic and the code to display output to the user, so this is sometimes referred to as a thick client.
Advantages of Server Database System

Having data stored and managed in a central location offers several advantages:

  • Each data item is stored in a central location where all users can work with it.

    Separate copies of the item are not stored on each client, which eliminates problems with users having to ensure they are all working with the same information. Their system does not need to ensure that all copies of the data are updated with the current values, because there is only one copy in the central location.

  • Business and security rules can be defined one time on the server and enforced equally among all users.

    Rule enforcement can be done in a database through the use of constraints, stored procedures, and triggers. Rules can also be enforced in a server application, since these applications are also central resources accessed by many thin clients.

  • A relational database server optimizes network traffic by returning only the data an application needs.

    For example, if an application working with a file server needs to display a list of the names of sales representatives in Oregon, it must retrieve the entire employee file. If the application is working with a relational database server, it sends this command:

    SELECT first_name, last_name
FROM employees
WHERE emp_title = 'Sales Representative'
  AND emp_state = 'OR'

    The relational database sends back only the names of the sales representatives in Oregon, not all of the information about all employees.

  • Hardware costs can be minimized.

    Because the data is not stored on each client, clients do not have to dedicate disk space to storing data. The clients also do not need the processing capacity to manage data locally, and the server does not need to dedicate processing power to displaying data.

    The server can be configured to optimize the disk I/O capacities needed to retrieve data, and clients can be configured to optimize the formatting and display of data retrieved from the server.

    The server can be stored in a relatively secure location and equipped with devices such as an Uninterruptable Power Supply more economically than fully protecting each client.

  • Maintenance tasks such as backing up and restoring data are simplified because they can focus on the central server.
Advantages of SQL Server 2000 as a Database Server

Microsoft SQL Server 2000 is capable of supplying the database services needed by extremely large systems. Large servers may have thousands of users connected to an instance of SQL Server 2000 at the same time. SQL Server 2000 has full protection for these environments, with safeguards that prevent problems, such as having multiple users trying to update the same piece of data at the same time. SQL Server 2000 also allocates the available resources effectively, such as memory, network bandwidth, and disk I/O, among the multiple users.

Extremely large Internet sites can partition their data across multiple servers, spreading the processing load across many computers, and allowing the site to serve thousands of concurrent users.

Multiple instances of SQL Server 2000 can be run on a single computer. For example, an organization that provides database services to many other organizations can run a separate instance of SQL Server 2000 for each customer organization, all on one computer. This isolates the data for each customer organization, while allowing the service organization to reduce costs by only having to administer one server computer.

SQL Server 2000 applications can run on the same computer as SQL Server 2000. The application connects to SQL Server 2000 using Windows Interprocess Communications (IPC) components, such as shared memory, instead of a network. This allows SQL Server 2000 to be used on small systems where an application must store its data locally.

The illustration shows an instance of SQL Server 2000 operating as the database server for both a large Web site and a legacy client/server system.

The largest Web sites and enterprise-level data processing systems often generate more database processing than can be supported on a single computer. In these large systems, the database services are supplied by a group of database servers that form a database services tier. SQL Server 2000 does not support a load-balancing form of clustering for building a database services tier, but it does support a mechanism that can be used to partition data across a group of autonomous servers. Although each server is administered individually, the servers cooperate to spread the database-processing load across the group. A group of autonomous servers that share a workload is called a federation of servers. For more information, see Designing Federated Database Servers.

Desktop Database Systems

Although SQL Server 2000 works effectively as a powerful database server, the same database engine can also be used in applications that need stand-alone databases stored locally on the client. SQL Server 2000 can configure itself dynamically to run efficiently with the resources available on a client desktop or laptop computer, without the need to dedicate a database administrator to each client. Application vendors can also embed SQL Server 2000 as the data storage component of their applications.

When clients use local SQL Server 2000 databases, applications connect to local instances of the database engine in much the same way they connect across the network to a database engine running on a remote server. The primary difference is that local connections are made through local IPCs such as shared memory, and remote connections must go through a network.

The illustration shows using SQL Server 2000 in a desktop database system.


Logins

New Information - SQL Server 2000 SP3.

To connect to an instance of Microsoft® SQL Server™ 2000, you typically give an application only two or three pieces of information:

  • The network name of the computer on which the SQL Server instance is running.

  • The name of the instance (optional, required only if you are connecting to a named instance).

  • Your login identifier (ID).

A login ID is the account identifier that controls access to any SQL Server 2000 system. SQL Server 2000 does not complete a connection unless it has first verified that the login ID specified is valid. Verification of the login is called authentication.

One of the properties of a login is the default database. When a login connects to SQL Server, this default database becomes the current database for the connection, unless the connection request specifies that another database be made the current database.

A login ID only enables you to connect to an instance of SQL Server. Permissions within specific databases are controlled by user accounts. The database administrator maps your login account to a user account in any database you are authorized to access. For more information, see Logins, Users, Roles, and Groups.

Authenticating Logins

Instances of SQL Server must verify that the login ID supplied on each connection request is authorized to access the instance. This process is called authentication. SQL Server 2000 uses two types of authentication: Windows Authentication and SQL Server Authentication. Each has a different class of login ID.

Windows Authentication

A member of the SQL Server 2000 sysadmin fixed server role must first specify to SQL Server 2000 all the Microsoft Windows NT® or Microsoft Windows® 2000 accounts or groups that can connect to SQL Server 2000. When using Windows Authentication, you do not have to specify a login ID or password when you connect to SQL Server 2000. Your access to SQL Server 2000 is controlled by your Windows NT or Windows 2000 account or group, which is authenticated when you log on to the Windows operating system on the client.

When you connect, the SQL Server 2000 client software requests a Windows trusted connection to SQL Server 2000. Windows does not open a trusted connection unless the client has logged on successfully using a valid Windows account. The properties of a trusted connection include the Windows NT and Windows 2000 group and user accounts of the client that opened the connection. SQL Server 2000 gets the user account information from the trusted connection properties and matches them against the Windows accounts defined as valid SQL Server 2000 logins. If SQL Server 2000 finds a match, it accepts the connection. When you connect to SQL Server 2000 using Windows 2000 Authentication, your identification is your Windows NT or Windows 2000 group or user account.

The Microsoft Windows Me and Windows 98 operating systems do not support the server side of the trusted connection API. When SQL Server is running on Windows Me or Windows 98, it does not support Windows Authentication. Users must supply a SQL Server login when they connect. When SQL Server is running on Windows NT or Windows 2000, Windows Me, Windows 8, and Windows 95 clients can connect to it using Windows 2000 Authentication.

SQL Server Authentication

A member of the sysadmin fixed server role first specifies to SQL Server 2000 all the valid SQL Server 2000 login accounts and passwords. These are not related to your Microsoft Windows account or network account. You must supply both the SQL Server 2000 login and password when you connect to SQL Server 2000. You are identified in SQL Server 2000 by your SQL Server 2000 login.

Security Note When possible, use Windows Authentication.

SQL Server Authentication Modes

When SQL Server 2000 is running on Windows NT or Windows 2000, members of the sysadmin fixed server role can specify one of two authentication modes:

  • Windows Authentication Mode

    Only Windows Authentication is allowed. Users cannot specify a SQL Server 2000 login ID. This is the default authentication mode for SQL Server 2000. You cannot specify Windows Authentication Mode for an instance of SQL Server running on Windows 98, because the operating system does not support Windows Authentication.

  • Mixed Mode

    If users supply a SQL Server 2000 login ID when they log on, they are authenticated using SQL Server Authentication. If they do not supply a SQL Server 2000 login ID, or request Windows Authentication, they are authenticated using Windows Authentication.

These modes are specified during setup or with SQL Server Enterprise Manager.

Login Delegation

If you use Windows Authentication to log on to an instance of SQL Server 2000 running on Windows 2000, and the computer has Kerberos support enabled, SQL Server 2000 can pass your Windows login credentials to other instances of SQL Server. Delegation of your credentials from one instance to another is sometimes called impersonation, typically when both instances of SQL Server are running on the same computer.

For example, if Instance A and Instance B are running on separate computers using Windows 2000, you can connect to Instance A and execute a distributed query that references tables on Instance B. When Instance A connects to Instance B to retrieve the required data, Instance A can use your Windows account credentials for the connection. Instance B has visibility to your specific account, and can validate your individual permissions to access the data requested.

Without delegation, administrators have to specify the login that Instance A uses to connect to Instance B (or any other instance). This login is used regardless of which user executes a distributed query on Instance A, and prevents Instance B from having any knowledge of the actual user executing the query. The administrators of Instance B cannot define permissions specific to individual users coming in from Instance A, they must define a global set of permissions for the login account used by Instance A. The administrators also cannot audit which specific users perform actions in Instance B. Using delegation with Windows Authentication on Windows 2000 allows administrators greater control over user permissions and gives auditors greater visibility to the actions of individual users.

Connections that use delegation are authenticated using a Kerberos ticket. Each ticket has a timeout period defined by the Windows 2000 security administrator. If a connection remains idle for a long period and the Kerberos ticket times out, all subsequent attempts to execute a distributed query will fail until the user disconnects and reconnects.

See Also

Managing Security

Security Account Delegation


Client Components

Clients do not access Microsoft® SQL Server™ 2000 directly; instead, clients use applications written to access the data in SQL Server. These can include utilities that come with SQL Server 2000, third-party applications that access SQL Server 2000, in-house applications developed by programmers at the SQL Server 2000 site, or Web pages. SQL Server 2000 can also be accessed through COM, Microsoft ActiveX®, or Windows® DNA components.

SQL Server 2000 supports two main classes of applications:

  • Relational database applications that send Transact-SQL statements to the database engine; results are returned as relational result sets.

  • Internet applications that send either Transact-SQL statements or XPath queries to the database engine; results are returned as XML documents.
Relational Database APIs

Relational database applications are written to access SQL Server 2000 through a database application programming interface (API). A database API contains two parts:

  • The language statements passed to the database.

    The language by relational SQL Server 2000 applications is Transact-SQL. Transact-SQL supports all SQL-92 Entry Level SQL statements and many additional SQL-92 features. It also supports the ODBC extensions to SQL-92 and other extensions specific to Transact-SQL.

  • A set of functions or object-oriented interfaces and methods used to send the language statements to the database and process the results returned by the database.
Native API Support

Native API support means the API function calls are mapped directly to the network protocol sent to the server. There is no intermediate translation to another API needed. SQL Server 2000 provides native support for two main classes of database APIs:

  • OLE DB

    SQL Server 2000 includes a native OLE DB provider. The provider supports applications written using OLE DB, or other APIs that use OLE DB, such as ActiveX Data Objects (ADO). Through the native provider, SQL Server 2000 also supports objects or components using OLE DB, such as ActiveX, ADO, or Windows DNA applications.

  • ODBC

    SQL Server 2000 includes a native ODBC driver. The driver supports applications or components written using ODBC, or other APIs using ODBC, such as DAO, RDO, and the Microsoft Foundation Classes (MFC) database classes.

An example of nonnative support for an API would be a database that does not have an OLE DB provider, but does have an ODBC driver. An OLE DB application could use the OLE DB provider for ODBC to connect to the database through an ODBC driver. This provider maps the OLE DB API function calls from the application to ODBC function calls it sends to the ODBC driver.

Additional SQL Server API Support

SQL Server 2000 also supports:

  • DB-Library

    DB-Library is an API specific to SQL Server 2000 and Microsoft SQL Server. SQL Server 2000 supports DB-Library applications written in C. DB-Library has not been extended beyond the functionality it had in Microsoft SQL Server version 6.5. Existing DB-Library applications developed against earlier versions of Microsoft SQL Server can be run against SQL Server 2000, but many features introduced in SQL Server 2000 and SQL Server version 7.0 are not available to DB-Library applications.

  • Embedded SQL

    SQL Server 2000 includes a C precompiler for the Embedded SQL API. Embedded SQL applications use the DB-Library DLL to access SQL Server 2000.

XML Access

Internet applications retrieve results in the form of XML documents rather than relational result sets. The applications execute either XPath queries or Transact-SQL statements that use the FOR XML clause to specify that results be returned as XML documents. If you define a virtual root on a Microsoft Internet Information Server (IIS) that points to an instance of SQL Server 2000, IIS applications can use three mechanisms for executing XPath queries or Transact-SQL statements:

  • Execute a Uniform Resource Locator (URL) that references the virtual root and contains an XPath query or Transact-SQL statement with FOR XML.

  • Use the ADO API to execute an XPath query to Transact-SQL statement with FOR XML.

  • Use the OLE DB API to execute an XPath query to Transact-SQL statement with FOR XML.
Client Communications

The Microsoft OLE DB Provider for SQL Server 2000, the SQL Server 2000 ODBC driver, and DB-Library are each implemented as a DLL that communicates to SQL Server 2000 through a component called a client Net-Library.

See Also

Application Development Architecture

Overview of Building SQL Server Applications


Communication Components

New Information - SQL Server 2000 SP3.

Microsoft® SQL Server™ 2000 supports several methods of communicating between client applications and the server. When the application is on the same computer as an instance of SQL Server 2000, Windows Interprocess Communication (IPC) components, such as local named pipes or shared memory, are used. When the application is on a separate client, a network IPC is used to communicate with SQL Server.

An IPC has two components:

  • Application Programming Interface (API)

    The API is a definition of the set of functions software uses to send requests to and retrieve results from the IPC.

  • Protocol

    The protocol defines the format of the information sent between any two components communicating through the IPC. In the case of a network IPC, the protocol defines the format of the packets sent between two computers using the IPC.

Some network APIs can be used over multiple protocols. For example, the Named Pipes API and the Microsoft Win32® RPC API can both be used with several protocols. Other network APIs, such as the Banyan VINES API, can be used with only one protocol.

The SQL Server 2000 client communication components require little or no administration when they connect to SQL Server 2000. Although the actual implementation of the communication components is more complex than in earlier versions of SQL Server, SQL Server 2000 users are shielded from this when connecting to instances of SQL Server 2000. The SQL Server 2000 client software dynamically determines the network address needed to communicate with any instance of SQL Server 2000. All the client software needs is the network name of the computer on which the SQL Server 2000 instance is running, and the name of the instance if connecting to a named instance. There are very few reasons for SQL Server 2000 users to manage the client communications components using the Client Network Utility.

System Area Networks

SQL Server 2000 Enterprise Edition introduces support for System Area Network (SAN) protocols built using the Virtual Interface Architecture (VIA). A SAN is a high-speed, highly reliable network for interconnecting servers or clusters of servers. A multi-tier, distributed system can generate extremely high levels of network traffic between servers. Gaining high performance in such a system is possible only if message transmissions are fast enough to minimize the time the servers spend processing messages and waiting for replies. Compared to local area networks (LANs) or wide area networks (WANs), SANs support high levels of messaging traffic by lowering CPU loads and message latency. SANs are also more reliable than LANs or WANs, and are implemented in groups or clusters of servers that are located close together, such as in the same computer room.

Compaq®, Intel®, Microsoft, and other companies have defined Virtual Interface Architecture (VIA) as a generic definition of a SAN that allows many possible hardware implementations. The Virtual Interface Architecture allows a VIA provider to implement a flexible, scalable, robust messaging component built at low cost using standard components. VIA SANs can support the intense messaging requirements of large Web servers.

The Virtual Interface Architecture defines both an API and a protocol. The API is referred to as the VIA API, and protocol is referred to as the VIA protocol.

SANs are well suited for these uses with SQL Server 2000:

  • The application servers forming the business services tier can use the SAN for high-speed communications with the data services tier. This is done when the application servers and database servers are at the same physical location.

  • SQL Server 2000 servers can use the SAN to improve the performance of distributed queries, distributed transactions, and data replication between database servers at the same location. A SAN can improve the distributed queries needed to support the distributed views used to implement federations of computers running SQL Server.

SQL Server 2000 supports the QLogic and Giganet VIA SAN implementations. Because SANs are intended to support the high communications bandwidth between servers, SQL Server 2000 only supports the VIA Net-Libraries on the Windows NT® Server, Windows 2000 Data Center, Advanced Server, and Server operating systems.


Client and Server Net-Libraries

New Information - SQL Server 2000 SP3.

Microsoft® SQL Server™ 2000 uses components called client Net-Libraries to shield the OLE DB Provider for SQL Server 2000, the SQL Server 2000 ODBC driver, and the DB-Library DLL, from the details of communicating with different Interprocess Communication (IPC) components. Server Net-Libraries perform the same function for the database engine.

The following components manage communications between SQL Server 2000 and its clients in this sequence:

  1. The client application calls the OLE DB, ODBC, DB-Library, or Embedded SQL API. This causes the OLE DB provider, ODBC driver, or DB-Library DLL to be used for SQL Server communications.

  2. The OLE DB provider, ODBC driver, or DB-Library DLL calls a client Net-Library. The client Net-Library calls an IPC API.

  3. The client calls to the IPC API are transmitted to a server Net-Library by the underlying IPC. If it is a local IPC, calls are transmitted using a Windows operating IPC such as shared memory or local named pipes. If it is a network IPC, the network protocol stack on the client uses the network to communicate with the network protocol stack on the server.

  4. The server Net-Library passes the requests coming from the client to the instance of SQL Server 2000.

Replies from SQL Server 2000 to the client follow the reverse sequence.

This illustration shows the communication path when a SQL Server application runs on the same computer as an instance of SQL Server.

This is a simplified illustration of the communication path when a SQL Server application connects through a LAN or WAN to an instance of SQL Server 2000 on a separate computer. Although the illustration shows the OLE DB Provider for SQL Server 2000, SQL Server 2000 ODBC driver, and DB-Library DLL using specific Net-Libraries, there is nothing that limits these components to these Net-Libraries. The provider, driver, and DB-Library can each use any of the SQL Server Net-Libraries.

SQL Server 2000 classifies the Net-Libraries as primary or secondary Net-Libraries. The OLE DB Provider for SQL Server 2000, the SQL Server 2000 ODBC driver, the DB-Library DLL, and the database engine communicate directly with only the two primary Net-Libraries:

  • By default, local connections between an application and an instance of SQL Server 2000 on the same computer use the Shared Memory primary Net-Library. This path is shown in the illustration above.

  • Intercomputer connections communicate through the Super Socket primary Net-Library. The Super Socket Net-Library has two communication paths:
    • If you choose a TCP/IP Sockets connection or an NWLINK IPX/SPX connection, the Super Socket Net-Library directly calls the Windows Socket 2 API for the communication between the application and the instance of SQL Server 2000.

    • If a Named Pipes, Virtual Interface Architecture (VIA) SAN, Multiprotocol, AppleTalk, or Banyan VINES connection is chosen, a subcomponent of the Super Socket Net-Library, called the Net-Library router, loads the secondary Net-Library for the chosen protocol and routes all Net-Library calls to it.

This illustration shows in more detail the communication paths through the client and server Net-Libraries for network connections between a computer running the SQL Server 2000 client components and an instance of SQL Server 2000.

The server Super Socket Net-Library is implemented as Ssnetlib.dll, and the client Super Socket Net-Library is implemented as Dbnetlib.dll.

This table shows how the Net-Libraries relate to the IPC APIs and protocols used to make connections.

Protocol specified in network utilities | Client Net-Library used | Server Net-Library used | IPC API called by Net-Library | Protocols supporting the IPC API
TCP/IP Sockets | Dbnetlib.dll | Ssnetlib.dll | Windows Socket 2 | TCP/IP
Named Pipes | Dbnetlib.dll routes to Dbnmpntw.dll | Ssnetlib.dll routes to Ssnmpn70.dll (Microsoft Windows NT® and Windows® 2000 only) | Windows Named Pipes | File system (local) TCP/IP NetBEUI NWLink
NWLink IPX/SPX | Dbnetlib.dll | Ssnetlib.dll | Windows Socket 2 | NWLink
GigaNet VIA SAN | Dbnetlib.dll routes to Dbmsgnet.dll (Microsoft Windows NT and Windows 2000 only) | Ssnetlib.dll routes to Ssmsgnet.dll (Microsoft Windows NT and Windows 2000 only) | Virtual Interface Architecture (VIA) | Virtual Interface Architecture (VIA)
QLogic VIA SAN | Dbnetlib.dll routes to DBmsqlgc.dll (Microsoft Windows NT and Windows 2000 only) | Ssnetlib.dll routes to SSmsqlgc.dll (Microsoft Windows NT and Windows 2000 only) | Virtual Interface Architecture (VIA) | Virtual Interface Architecture (VIA)
Multiprotocol | Dbnetlib.dll routes to Dbmsrpcn.dll | Ssnetlib.dll routes to Ssmsrpc.dll (default instance only) | Windows RPC | File system (local) TCP/IP NetBEUI NWLink
AppleTalk | Dbnetlib.dll routes to Dbmsadsn.dll | Ssnetlib.dll routes to Ssmsad70.dll (default instance only) | AppleTalk ADSP | AppleTalk
Banyan Vines | Dbnetlib.dll routes to Dbmsvinn.dll | Ssnetlib.dll routes to Ssmsvi70.dll (default instance only) | Banyan VINES SPP | Banyan VINES

Instances of SQL Server 2000 running on Microsoft Windows® Me or Windows 98 do not support the server Named Pipes and Banyan VINES Net-Libraries, because the Windows Me and Windows 98 operating systems do not support the server part of these APIs. SQL Server 2000 also does not support the server NWLink IPX/SPX Net-Library on Windows Me or Windows 98. SQL Server 2000 does support the client side of these Net-Libraries on Windows Me and Windows 98; therefore, applications running on Windows Me or Windows 98 can use the Net-Libraries to connect to instances of SQL Server on Microsoft Windows NT or Microsoft Windows 2000. Applications running on Windows 95 can also make connections using the client side of these Net-Libraries.

The AppleTalk Net-Library does not run on computers running Windows Me, Windows 98, or Windows 95.

VIA networks are designed to support the high levels of messaging traffic between servers in the same data center, such as in a Web site implemented as one or more Internet Information Services application servers connected to one or more database servers running SQL Server. VIA networks are not used to connect individual workstations. Both the client and server SQL Server VIA Net-Libraries are supported only on Windows NT Server and Advanced Server, and Windows 2000 Server, Advanced Server, and Data Center.

Named instances of SQL Server 2000 support only the Named Pipes, TCP/IP Sockets, NWLink IPX/SPX, and Shared Memory Net-Libraries. Named instances do not support the Multiprotocol, AppleTalk, or Banyan VINES Net-Libraries. To maintain compatibility with earlier versions of SQL Server, default instances support all server Net-Libraries.

Some of the Net-Libraries support only one type of protocol stack. For example, the AppleTalk Net-Library requires an AppleTalk protocol stack. Other Net-Libraries, such as the Named Pipes and Multiprotocol Net-Libraries support several protocol stacks.

The Microsoft SQL Server Net-Libraries have been tested intensively with the Microsoft protocol stacks and are supported with these stacks. Protocol stacks from other vendors should work, provided that the stacks fully support the APIs used by the Microsoft SQL Server Net-Libraries.

When the Named Pipes or Multiprotocol Net-Libraries are used to connect an application to an instance of SQL Server on the same computer, and the computer does not have a protocol stack, the IPC APIs are implemented by the file system.


Controlling Net-Libraries and Communications Addresses

New Information - SQL Server 2000 SP3.

After installing Microsoft® SQL Server™ 2000, you define the behaviors of the client Net-Libraries by using the Client Network Utility and server Net-Libraries by using the Server Network Utility.

Each instance of SQL Server 2000 can be listening on any combination of the server Net-Libraries at one time. There is one set of server Net-Libraries for each set of database engine executable files. The server Net-Libraries are installed in: C:\Program Files\Microsoft SQL Server\MSSQL$n, where n is the number associated with this set of database engine executable files.

All of the server Net-Libraries are installed during the server portion of SQL Server Setup, but some of them may not be active. The person running the Setup program can choose which combination of Net-Libraries is active for the instance being installed. The table shows the default server Net-Libraries that are activated by SQL Server Setup for the Microsoft Windows NT®, Microsoft Windows® 2000, Windows Me, and Microsoft Windows 98 operating systems.

Windows NT and Windows 2000 | Windows Me and Windows 98
TCP/IP Sockets | TCP/IP Sockets
Shared Memory | Shared Memory
Named Pipes |

Disabling and Enabling Net-Libraries

After setup, you can disable and enable individual server Net-Libraries for each instance of SQL Server on a database computer using the Server Network Utility. When a server Net-Library is disabled for a specific instance, the database engine for the instance does not load the server Net-Library and does not accept connections using that Net-Library. The server Net-Library remains installed and can be enabled for other instances sharing the same set of executable files. For more information, see SQL Server Network Utility.

There is always one set of the client Net-Library DLLs installed on any computer running SQL Server 2000 client components. The client Net-Library DLLs are installed in the C:\Windows\System32 or C:\Windows\System directory. All of the client Net-Libraries are installed when you install the SQL Server 2000 client utilities. You can enable and disable the various client Net-Libraries using the Client Network Utility. When a client Net-Library is disabled it remains installed but is not considered for any connections. You can:

  • Specify the sequence in which client Net-Libraries are considered for all connections except those that use a server alias.

  • Enable or disable specific client Net-Libraries.

  • As a compatibility option, define server aliases that define specific Net-Libraries and connection parameters to use when connecting to instances of SQL Server version 7.0 or earlier.

For more information, see Configuring Client Net-Libraries.

Connecting to SQL Server 2000

For a client to connect to a server running SQL Server 2000, the client must use a client Net-Library that matches one of the server Net-Libraries the server is currently listening on. Also, both the client and server must be running a protocol stack supporting the network API called by the Net-Library being used for the connection. For example, if the client tries using the client Multiprotocol Net-Library, and the server is listening on the server Multiprotocol Net-Library, but the server is running with the TCP/IP protocol while the client computer is running only with the IPX/SPX protocol stack, the client cannot connect to the server. Both the client and the server must be using the same Net-Library and running the same protocol stack.

Each instance of SQL Server on a computer must listen on different network addresses so that applications can connect to specific instances. Default instances of SQL Server 2000 listen on the same default network addresses as earlier versions of SQL Server so that existing client computers can continue to connect to the default instance. The table shows the default network addresses that instances of SQL Server 2000 listen on.

Net-Library | Default instance network address | Named instance network address
TCP/IP Sockets | TCP Port 1433 | A TCP port is chosen dynamically the first time the MSSQL$instancename service is started.
Named Pipes | \\computername\pipe\sql\query | \\computername\pipe\MSSQL$instancename\sql\query
NWLink IPX/SPX | Port 33854 | First available port after 33854 for each instance.
VIA SAN | VIA Port 0:1433 | VIA Port 0:1433

The VIA server Net-Libraries assign the same default address to both default and named instances. The system administrator must use the Server Network Utility to assign unique port addresses to each instance on a computer.

You can use the SQL Server 2000 Server Network Utility to find out what specific set of network address each instance of SQL Server is listening on for client connections.

When the SQL Server 2000 client Net-Libraries connect to an instance of SQL Server 2000, only the network name of the computer running the instance and the instance name are required. When an application requests a connection to a remote computer, Dbnetlib.dll opens a connection to UDP port 1434 on the computer network name specified in the connection. All computers running an instance of SQL Server 2000 listen on this port. When a client Dbnetlib.dll connects to this port, the server returns a packet listing all the instances running on the server. For each instance, the packet reports the server Net-Libraries and network addresses the instance is listening on. After the Dbnetlib.dll on the application computer receives this packet, it chooses a Net-Library that is enabled on both the application computer and on the instance of SQL Server, and makes a connection to the address listed for that Net-Library in the packet. The connection attempt fails only if:

  • The requested instance of SQL Server 2000 is not running.

  • None of the Net-Libraries that the instance of SQL Server 2000 is listening on is active on the application computer.

When Dbnetlib.dll compares the network protocols enabled on the application computer against those enabled on the instance of SQL Server 2000, the sequence of the comparison is specified using the Client Network Utility on the application computer. For example, assume an application computer has three client Net-Libraries enabled and specifies that the comparison sequence is TCP/IP Sockets first, NWLink IPX/SPX second, and named pipes third. If the application computer attempts a connection to an instance of SQL Server 2000 that has enabled only the NWLink IPX/SPX, named pipes and Multiprotocol server Net-Libraries, the connection is made using NWLink IPX/SPX. For more information about configuring the comparison sequence, see Configuring Client Net-Libraries.

You cannot assign UDP port 1434 to an application other than SQL Server on computers running instances of SQL Server 2000. Network administrators managing network filters must allow communications on UDP port 1434 to enable SQL Server 2000 connections to pass through the filter.

When running an application on the same computer as a default instance of SQL Server, you can use these names to reference the default instance.

Windows NT and Windows 2000 | Windows Me and Windows 98
Computer name | Computer name
(local)* | (local)*
.* |

*Where "(local)" is the word local in parentheses and "." is a period, or dot. "." is valid only in SQL Server utilities, such as SQL Query Analyzer and osql; it cannot be specified in API connection requests.

Do not use either (local) or . to connect to a virtual server implemented using failover clustering.

Using the computer name is recommended. These connections will be made with the Shared Memory Net-Library. DB-Library does not support using (local).

Connecting to Earlier Instances of SQL Server

When applications using the SQL Server 2000 client components connect to instances of SQL Server version 7.0 or earlier, the communications between the instance and the application function the same as they did in the earlier versions of SQL Server. Applications using SQL Server version 7.0 or earlier client components to connect to default instances of SQL Server 2000 also communicate as they did in earlier versions of SQL Server. In both of these cases you must administer the network addresses the way they were administered in earlier versions of SQL Server. For more information about configuring a client in earlier versions of SQL Server, see Managing Clients.

SQL Server version 6.5 and earlier supported Windows Authentication (called Integrated Security in those versions) only on the Named Pipes and Multiprotocol Net-Libraries. SQL Server 2000 and SQL Server version 7.0 support Windows Authentication on all Net-Libraries. Existing SQL Server version 6.5 or 7.0 applications that use the default Named Pipes Net-Library can be used to open Windows Authentication connections to instances of SQL Server version 6.5. However, if you upgrade the SQL Server client utilities on the application computer to SQL Server 2000, the default Net-Library changes to TCP/IP, and any attempt to open a Windows Authentication connection to instances of SQL Server version 6.5 fails. To resolve this, you can use the Client Network Utility to put the Named Pipes Net-Library at the top of the Net-Library list, thereby establishing it as the default Net-Library.

See Also

Managing Clients

Managing Servers


Tabular Data Stream Protocol

Microsoft® SQL Server™ 2000 uses an application-level protocol called Tabular Data Stream (TDS) for communication between client applications and SQL Server. The TDS packets are encapsulated in the packets built for the protocol stack used by the Net-Libraries. For example, if you are using the TCP/IP Sockets Net-Library, then the TDS packets are encapsulated in the TCP/IP packets of the underlying protocol.

The contents of the packets that send result sets back to the application depends on whether FOR XML is specified in the Transact-SQL statement transmitted to the database engine:

  • If FOR XML is not specified, the database engine sends a relational result set back to the application. The TDS packets contain the rows of the result set, with each row comprised of one or more columns, as specified in the select list of the SELECT statement.

  • If FOR XML is specified, the database engine streams an XML document back to the application. The XML document is formatting in the TDS packets as if it were a single, long Unicode value, with each packet being approximately 4 KB in size.

You can configure the SQL Server packet size, which is the size of the TDS packets. The size of the TDS packets defaults to 4 KB on most clients (DB-Library applications default to 512 bytes), which testing has shown to be the optimal TDS packet size in almost all scenarios. The size of the TDS packets can be larger than the size of the packets in the underlying protocol. If this is the case, the protocol stack on the sending computer disassembles the TDS packets automatically into units that fit into the protocol packets, and the protocol stack on the client computer reassembles the TDS packets on the receiving computer.


Net-Library Encryption

New Information - SQL Server 2000 SP3.

Microsoft® SQL Server™ 2000 can use the Secure Sockets Layer (SSL) to encrypt all data transmitted between an application computer and a SQL Server instance on a database computer. The SSL encryption is performed within the Super Socket Net-Library (Dbnetlib.dll and Ssnetlib.dll) and applies to all inter-computer protocols supported by SQL Server 2000. When SSL encryption is active, the Super Socket Net-Library performs the SSL encryption before calling:

  • The Windows Socket 2 API to transmit TCP/IP Sockets or NWLink IPX/SPX packets.

  • The Net-Library router to send a packet to the Named Pipe, Multiprotocol, AppleTalk, or Banyan VINES Net-Libraries.

SSL encryption works only with instances of SQL Server 2000 running on a computer that has been assigned a certificate from a public certification authority. The computer on which the application is running must also have a root CA certificate from the same authority.

The Net-Library encryption is implemented using the Secure Sockets Layer API. The level of encryption, 40-bit or 128-bit, depends on the version of the Microsoft Windows® operating system that is running on the application and database computers.

Enabling SSL encryption increases the security of data exchanged across networks between instances of SQL Server and applications. Data sent across the network is encrypted so that the clear text cannot be read by unauthorized people using tools such as network sniffers. Enabling encryption does, however, slightly slow the performance of the Net-Libraries. Encryption forces these actions in addition to all of the work for an unencrypted connection:

  • An extra network round trip is required at connect time.

  • All packets sent from the application to the instance of SQL Server must be encrypted by the client Net-Library and decrypted by the server Net-Library.

  • All packets sent from the SQL Server instance to the application must be encrypted by the server Net-Library and decrypted by the client Net-Library.

Shared memory Net-Library communications are inherently secure without the need for encryption. The shared memory Net-Library never participates in inter-computer communications. The area of memory shared between the application process and the database engine process cannot be accessed from any other Windows process.

For compatibility with earlier versions of SQL Server, the Multiprotocol Net-Library continues to support its own encryption. This encryption is specified independently of the SSL encryption and is implemented by calling the Windows RPC encryption API. It does not require the use of certificates. The level of RPC encryption, 40-bit or 128-bit, depends on the version of the Windows operating system that is running on the application and database computers. The Multiprotocol Net-Library is not supported by named instances.


Server Components

In addition to the server Net-Libraries, Microsoft® SQL Server™ 2000 incorporates these main server components:

  • SQL Server database engine (MSSQLServer service)

  • SQL Server Agent (SQLServerAgent service)

  • Microsoft Search service

  • Microsoft Distributed Transaction Coordinator (MS DTC service)

The server components are supported on computers running the Microsoft Windows NT®, Windows® 2000, Windows Me, and Windows 98 operating systems. The server components are not supported on computers running Microsoft Windows 95. When SQL Server is running on Windows NT or Windows 2000, the SQL Server database engine, SQL Server Agent, and MS DTC are implemented as Windows NT or Windows 2000 services. On Windows Me and Windows 98, the server components are not implemented as services because the operating system does not support services. The Microsoft Search service is not available on Windows 95, Windows Me, or Windows 98.

The server components can be stopped and started several ways:

  • Windows NT and Windows 2000 can start each service automatically when the operating system is starting.

  • Use SQL Server Service Manager to start or stop the service.

  • Use SQL Server Enterprise Manager to start or stop the service.

  • On Windows NT or Windows 2000, use the net start and net stop command prompt commands to stop or start each service (except for a virtual server in a failover cluster).

SQL Server 2000 supports multiple instances of SQL Server on computers running Windows NT or Windows 2000. Each instance has its own copy of the SQL Server service and the SQL Server Agent Service. There are only single copies of the Microsoft Search service or the MS DTC service, whose services are shared among the multiple instances of SQL Server running on the computer.


SQL Server Service

The Microsoft® SQL Server™ 2000 database engine runs as a service on the Microsoft Windows NT® or Microsoft Windows® 2000 operating systems. It does not run as a service on Microsoft Windows Me or Windows 98 because these operating systems do not support services. SQL Server can also run as an executable file on Windows NT and Windows 2000, although it is usually run as a service.

When multiple instances of SQL Server are run on the same computer, each instance has its own SQL Server service. The service name for the default instance is named MSSQLServer, the service name for named instances is MSSQL$InstanceName. For more information, see Multiple Instances of SQL Server.

The SQL Server service manages all of the files that comprise the databases owned by an instance of SQL Server. It is the component that processes all Transact-SQL statements sent from SQL Server client applications. SQL Server also supports distributed queries that retrieve data from multiple sources, not only SQL Server.

The SQL Server service allocates computer resources effectively between multiple concurrent users. It also enforces business rules defined in stored procedures and triggers, ensures the consistency of the data, and prevents logical problems such as having two people trying to update the same data at the same time.


SQL Server Agent Service

SQL Server Agent supports features allowing the scheduling of periodic activities on Microsoft® SQL Server™ 2000, or the notification to system administrators of problems that have occurred with the server. The SQL Server Agent components that implement this capability are:

  • Jobs

    Defined objects consisting of one or more steps to be performed. The steps are Transact-SQL statements that can be executed. Jobs can be scheduled, for example, to execute at specific times or recurring intervals.

  • Alerts

    Actions to be taken when specific events occur, such as a specific error, errors of certain severities, or a database reaching a defined limit of free space available. The alert can be defined to take such actions as sending an e-mail, paging an operator, or running a job to address the problem.

  • Operators

    People identified through their network account or e-mail identifier (ID) who can address problems with the server. They can be the targets of alerts, either through e-mail, a pager, or a net send network command.

The service name of SQLServerAgent applies only to the Agent service associated with a default instance. SQL Server Agent services associated with named instances are named SQLAgent$InstanceName.

Managing Scheduled Operations

The illustration shows the primary components that are used in the definition and operation of jobs, alerts, and operators.

  • Jobs, alerts, and operators are specified using:
    • SQL Server Enterprise Manager.

    • Applications that use SQL Distributed Management Objects (SQL-DMO).

    • Applications that use Transact-SQL and a standard database API.
  • The definitions are stored by SQL Server in the msdb system database.

  • When the SQLServerAgent service is started, it queries the system tables in the msdb database to determine what jobs and alerts to enable.

  • SQL Server Agent executes jobs at their scheduled time.

  • SQL Server passes any events that occur to the SQL Server Agent.

  • SQL Server Agent executes any alerts, or sends SQL Mail requests to SQL Server, or sends net send commands to Windows.

SQL Server 2000 is more highly automated than SQL Server version 6.5 and earlier, and more efficiently tunes itself to meet processing demands. These features lower the potential for exception conditions that would trigger alerts. Scheduled jobs remain a good feature for implementing recurring tasks such as backup procedures.

See Also

Automating Administrative Tasks


Microsoft Search Service

The Microsoft Search service is a full-text indexing and search engine.

The SQL-92 standard defines only basic character-search capabilities:

  • For a character value equal to, less than, or greater than a character constant.

  • For a character value containing a string pattern.

Using the Microsoft Search service allows Microsoft® SQL Server™ 2000 and SQL Server version 7.0 to support more sophisticated searches on character string columns.

The Microsoft Search service has two roles:

  • Indexing support

    Implements the full-text catalogs and indexes defined for a database. Accepts definitions of full-text catalogs, and the tables and columns comprising the indexes in each catalog. Implements requests to populate the full-text indexes.

  • Querying support

    Processes full-text search queries. Determines which entries in the index meet the full-text selection criteria. For each entry that meets the selection criteria, it returns the identity of the row plus a ranking value to the SQL Server service, where this information is used to construct the query result set. The types of queries supported include searching for:

    • Words or phrases.

    • Words in close proximity to each other.

    • Inflectional forms of verbs and nouns.

The full-text engine runs as a service named Microsoft Search on Microsoft Windows NT® or Microsoft Windows® 2000. It is installed when the Full-Text Search feature is selected during custom installation. The Microsoft Search service itself is not installed on Microsoft Windows Me, Windows 98 or Microsoft Windows 95, although clients using these operating systems can make use of the service when connected to a SQL Server installation running on Windows NT or Windows 2000.

The Microsoft Search service runs in the context of the local system account. During setup, SQL Server adds itself as an administrator of the Microsoft Search service. To ensure this relationship is maintained correctly, all changes to the SQL Server service account information must be made using the Properties tab of the SQL Server Properties dialog box in SQL Server Enterprise Manager.

The full-text catalogs and indexes are not stored in a SQL Server database. They are stored in separate files managed by the Microsoft Search service. The full-text catalog files are accessible only to the Microsoft Search service and the Windows NT or Windows 2000 system administrator.

See Also

Full-Text Catalogs and Indexes

Full-Text Query Architecture


MSSQLServerADHelper Service

The MSSQLServerADHelper service performs two functions:

  • It adds and removes the objects used to register instances of Microsoft® SQL Server™ 2000 relational database engine or Analysis server in the Microsoft Windows® 2000 Active Directory™.

  • It ensures that the Windows account under which a SQL Server service is running has permissions to update all of the Active Directory objects for the instance, as well as any replication publications and databases for that instance.

The service is dynamically started by an instance of SQL Server or the Analysis Manager when needed. The service is stopped as soon as it has completed its work.

Active Directory objects in a computer container can be created or removed only by programs that have been assigned either domain administration rights or that are running under the localsystem Windows account. Few sites run their SQL Server service under either of these types of accounts. A service application that does not perform network administration, such as SQL Server, is rarely granted full domain administration rights. The localsystem account cannot be given any privileges on remote computers; therefore, running SQL Server under this account would prevent much of the SQL Server distributed functionality from working. The MSSQLServerADHelper service is run under the localsystem account so that it can add and remove objects registering SQL Server entities in the Active Directory.

There is only one MSSQLServerADHelper service on a computer. The single service handles the Active Directory objects for all instances of the SQL Server relational database engine and all Analysis Manager applications running on the computer.

Registering SQL Server Analysis Servers

Analysis servers are registered from the Analysis Manager, which is a Microsoft Management Console (MMC) application. When users of Analysis Manager request that an Analysis server be registered in the Active Directory, the application dynamically starts the MSSQLServerADHelper service and requests that it create an MS-SQL-OLAPServer object in the Active Directory. The helper service is stopped after the object has been completed, and the Analysis Manager finishes filling in the information for the object. For more information, see Using Active Directory with Analysis Services.

Registering SQL Server Relational Components

All management of the registrations of instances of SQL Server, and the databases and replication publications in each instance, are made using system stored procedures on the instance of SQL Server. SQL Server Enterprise Manager calls the system stored procedures when users specify Active Directory actions in the user interface. The procedures used are:

  • sp_ActiveDirectory_SCP. Manages the registration of an instance of the relational database engine.

  • sp_addpublication, sp_addmergepublication, sp_changepublication, or sp_changemergepublication. Manage the registration of replication publications.

  • sp_ActiveDirectory_Obj. Manages the registration of a database.

Each of these system stored procedures internally call an internal component that use the Active Directory Services Interface (ADSI) to manage the objects. When an MS-SQL-SQLServer object must be added or removed from the Active Directory, or permissions granted, the SQL Server ADSI component calls the MSSQLServerADHelper service to perform the task. The SQL Server service uses the SQL Server ADSI component to dynamically start the MSSQLServerADHelper service as needed.

The SQL Server service dynamically calls the MSSQLServerADHelper service at these times:

  • When an MS-SQL-SQLServer object must be created in the Active Directory to register an instance of SQL Server, the SQL Server service calls MSSQLServerADHelper to create the object. MSSQLServerADHelper creates the object and gives update permissions to the Windows account under which the SQL Server service is running, and then MSSQLServerADHelper stops. The SQL Server service now has the permissions needed to maintain the object until it is removed. These permissions include creating MS-SQL-SQLPublication and MS-SQL-SQLDatabase objects as children of the MS-SQL-SQLServer object.

  • If an administrator changes the Windows account under which the SQL Server service runs, the SQL Server service detects this the next time it attempts to update any information in objects that existed in the Active Directory before the account change. The SQL Server service automatically starts MSSQLServerADHelper. That service reassigns update permissions on the all the objects related to the current instance of SQL Server to the new Windows account.

  • When a request is made to delete an MS-SQL-SQLServer object, the SQL Server ADSI component calls the MSSQLServerADHelper service to delete the object and any children that are still present.

The SQL Server service must be run under a Windows account that has permissions to start the MSSQLServerADHelper service. By default, members of the local Power Users and local Administrator's groups have this permission.


MS DTC Service

The Microsoft Distributed Transaction Coordinator (MS DTC) is a transaction manager that allows client applications to include several different sources of data in one transaction. MS DTC coordinates committing the distributed transaction across all the servers enlisted in the transaction.

An installation of Microsoft® SQL Server™ can participate in a distributed transaction by:

  • Calling stored procedures on remote servers running SQL Server.

  • Automatically or explicitly promoting the local transaction to a distributed transaction and enlist remote servers in the transaction.

  • Making distributed updates that update data on multiple OLE DB data sources.

    If these OLE DB data sources support the OLE DB distributed transaction interface, SQL Server can also enlist them in the distributed transaction.

The MS DTC service coordinates the proper completion of the distributed transaction to ensure that either all of the updates on all the servers are made permanent, or, in the case of errors, all erased.

SQL Server applications can also call MS DTC directly to start a distributed transaction explicitly. One or more servers running SQL Server can then be instructed to enlist in the distributed transaction and coordinate the proper completion of the transaction with MS DTC.

See Also

Distributed Transactions


Multiple Instances of SQL Server

Microsoft® SQL Server™ 2000 supports multiple instances of the SQL Server database engine running concurrently on the same computer. Each instance of the SQL Server database engine has its own set of system and user databases that are not shared between instances. Applications can connect to each SQL Server database engine instance on a computer in much the same way they connect to SQL Server database engines running on different computers.

There are two types of instances of SQL Server:

Default Instances

The default instance of the SQL Server 2000 database engine operates the same way as the database engines in earlier versions of SQL Server. The default instance is identified solely by the name of the computer on which the instance is running, it does not have a separate instance name. When applications specify only the computer name in their requests to connect to SQL Server, the SQL Server client components attempt to connect to the default instance of the database engine on that computer. This preserves compatibility with existing SQL Server applications.

There can only be one default instance on any computer, the default instance can be any version of SQL Server.

Named Instances

All instances of the database engine other than the default instance are identified by an instance name specified during installation of the instance. Applications must provide both the computer name and the instance name of any named instance to which they are attempting to connect. The computer name and instance name are specified in the format computer_name\instance_name.

There can be multiple named instances running on a computer, but only the SQL Server 2000 database engine can operate as a named instance. The database engines from earlier versions of SQL Server cannot operate as a named instance.

Instances apply primarily to the database engine and its supporting components, not to the client tools. When you install multiple instances, each instance gets a unique set of:

  • System and user databases.

  • The SQL Server and SQL Server Agent services. For default instances, the names of the services remain MSSQLServer and SQLServerAgent. For named instances, the names of the services are changed to MSSQL$instancename and SQLAgent$instancename, allowing them to be started and stopped independently of the other instances on the server. The database engines for the different instances are started and stopped using the associated SQL Server service. The SQL Server Agent services manage scheduled events for the associated instances of the database engine.

  • The registry keys associated with the database engine and the SQL Server and SQL Server Agent services.

  • Network connection addresses so that applications can connect to specific instances.
Shared Components

The following components are shared between all of the instances running on the same computer:

  • There is only one SQL Server 2000 program group (Microsoft SQL Server) on the computer, and only one copy of the utility represented by each icon in the program group. There is only one copy of SQL Server Books Online.

    The versions of the utilities in the program group are from the first version of SQL Server 2000 installed on the computer. For example, if you install the French version of SQL Server 2000 as a default instance and then the U.S. English version of SQL Server 2000 as a named instance, there is one SQL Server 2000 program group. All of the utility icons and the SQL Server Books Online icon in the program group start the French versions of the tools.

    All of the SQL Server 2000 utilities work with multiple instances. You can start and stop each of the instances from a single copy of the SQL Server 2000 Service Manager. You can use a single copy of the SQL Server 2000 SQL Server Enterprise Manager to control objects in all instances on the computer, and use a single copy of the SQL Server 2000 Server Network Manager to manage the network addresses with which all of the instances on the computer communicate.

  • There is only one copy of the MSSearchService that manages full-text searches against all of the instances of SQL Server on the computer.

  • There is only one copy each of the English Query and Microsoft SQL Server 2000 Analysis Services servers.

  • The registry keys associated with the client software are not duplicated between instances.

  • There is only one copy of the SQL Server development libraries (include and .lib files) and sample applications.
Default Instances

Configurations that can operate as a default instance include:

  • A default instance of SQL Server 2000.

  • An installation of SQL Server version 7.0 operates as a default instance.

  • An installation of SQL Server version 6.5 operates as a default instance.

  • A default instance of SQL Server 2000 that can be version switched with an installation of SQL Server version 6.5 using the SQL Server 2000 vswitch utility.

  • An installation of SQL Server version 7.0 that can be version switched with an installation of SQL Server version 6.5 using the SQL Server version 7.0 vswitch utility.

    Note You must apply SQL Server 6.5 Service Pack 5 to any instance of SQL Server 6.5 before installing instances of SQL Server 2000 on the same computer.

Switching Between Versions of SQL Server

You cannot version switch between an installation of SQL Server version 7.0 and a default instance of SQL Server 2000.

You can have any number of named instances of SQL Server 2000 in addition to the default instance. You are not required to run a default instance on a computer before you can run named instances. You can run named instances on a computer that has no default instance. SQL Server version 6.5 and SQL Server 7.0 cannot operate as named instances, only as default instances.

Microsoft does not support more than 16 instances on a single computer or failover cluster.

If you run SQL Server version 6.5 as a default instance and run one or more named instances of SQL Server 2000 on a single computer, the computer has two SQL Server program groups instead of one SQL Server program group:

  • A SQL Server 2000 program group executes the SQL Server 2000 tools.

  • A SQL Server version 6.5 program group runs the SQL Server 6.5 tools.

If you are running SQL Server version 7.0 with SQL Server 2000, the icons in the SQL Server 7.0 program group will execute the SQL Server 2000 tools.

Note You must apply SQL Server 6.5 Service Pack 5 to any instance of SQL Server 6.5 before installing instances of SQL Server 2000 on the same computer.

Multiple Instances of SQL Server on a Failover Cluster

You can run only one instance of SQL Server on each virtual server of a SQL Server failover cluster, although you can install up to 16 virtual servers on a failover cluster. The instance can be either a default instance or a named instance. The virtual server looks like a single computer to applications connecting to that instance of SQL Server. When applications connect to the virtual server, they use the same convention as when connecting to any instance of SQL Server; they specify the virtual server name of the cluster and the optional instance name (only needed for named instances): virtualservername\instancename. For more information about clustering, see Failover Clustering Architecture.


Communicating with Multiple Instances

Each instance of Microsoft® SQL Server™ 2000 listens on a unique set of network address so that applications can connect to different instances. SQL Server 2000 clients do not have to be configured to connect to an instance of SQL Server 2000. The SQL Server 2000 client components query a computer running instances of SQL Server 2000 to determine the Net-Libraries and network addresses for each instance. The client components then transparently choose a supported Net-Library and address for the connection without having to be configured on the client. The only information the application must supply is the computer name and instance name. For more information, see Controlling Net-Libraries and Communications Addresses.

A default instance of SQL Server 2000 listens on the same network addresses as earlier versions of SQL Server; therefore, applications using the client connectivity components of SQL Server version 7.0 or earlier can continue to connect to the default instance with no change. Named instances listen on alternative network addresses, and client computers using the client connectivity components of SQL Server version 7.0 or earlier must be set up to connect to the alternative addresses.


Using Multiple Instances

Although running multiple instances of Microsoft® SQL Server™ 2000 on a single computer expands the capabilities of SQL Server, the recommended configuration for most production databases servers is to use a single instance of SQL Server with multiple databases.

Using a single instance of SQL Server on a production server offers these benefits:

  • Only one instance needs to be administered.

  • There is no duplication of components or processing overhead, such as having to run multiple database engines on the same computer. This means that the overall performance of a server with a single instance may be higher than a server running multiple instances.

  • A single instance of SQL Server 2000 is capable of handling the processing growth requirements of the largest Web sites and enterprise data-processing systems, especially when it is part of a federation of database servers. For more information, see Federated SQL Server 2000 Database Servers.

Running multiple instances of SQL Server on a single computer is best:

  • When you must support different systems that have to be securely isolated from each other, such as when a service bureau has a large server and must create a separate instance of SQL Server for each customer.

  • When you need to support multiple test and development databases, and the most economical configuration is to run these as separate instances of SQL Server on a single large server.

  • When you need to run multiple applications on a desktop, and each application installs a separate instance of SQL Server 2000 Desktop Engine.


Working with Multiple Instances

Although multiple instances of Microsoft® SQL Server™ 2000 can run on a single computer, there is no direct connection between instances. Each instance operates in many ways as if it is on a separate server. An application connected to one instance cannot access objects in databases created in another instance, except through distributed queries. Databases and database files cannot be shared between instances.

Named instances of SQL Server 2000 database engines have almost the same behaviors as default instances. The main difference is that you must supply both the computer name and instance name to identify a named instance. When you specify only computername, you work with the default instance. When you specify computername\instancename you work with the named instance.

  • Service Manager.

    When you specify only computername in Service Manager, you can stop and start the default instance. When you specify computername\instancename you can stop and start the named instance. When a specific instance is started, any database created in that instance is available to any application that connects to the instance using an authorization ID that has permissions to access the database.

  • SQL Server Enterprise Manager.

    Using SQL Server Enterprise Manager you can register each instance for which you have permissions. After an instance is registered, you can create, edit, and drop objects in the databases associated with that instance, subject to the permissions granted to you. You can also create, edit, and drop Data Transformation Services, Replication, and SQL Server Agent objects for that instance.

  • Applications.

    In an application, when you specify computername as the server name parameter in a connection request, you are connected to the default instance on the computer. You can access any databases in the default instance that you have permissions to access. If you specify computername\instancename as the server name parameter, you are connected to the named instance. You can access any databases in that named instance that you have permissions to access. When you are connected to a specific instance, objects in databases in other instances can be accessed only through distributed queries, just as objects in databases on other servers can be accessed only through distributed queries. Applications specify the instance name in different ways:

    • ADO applications specify "Server=computername\instancename" in the provider string. For more information, see Connecting to Multiple Instances of SQL Server.

    • OLE DB applications specify "Server=computername\instancename" in the provider string. They can alternatively set DBPROP_INIT_DATASOURCE to computername\\instancename (the backslash must be escaped with a second backslash). For more information, see Establishing a Connection to a Data Source.

    • ODBC applications specify "Server=computername\instancename" in the connection string specified on SQLDriverConnect. They can alternatively specify computername\\instancename for the ServerName parameter on SQLConnect, or connect through a data source that has computername\instancename specified for the server name. For more information, see Support for SQLDriverConnect and SQLConfigDataSource.

    • SQL DMO applications can manage instances of SQL Server 2000 using the SQLServer2 object. For more information, see SQLServer2 Object.

    • DB-Library and Embedded SQL for C do not support multiple instances.
  • Distributed queries and linked servers.

    Distributed queries and linked server definitions use computername\instancename to identify named instances and computername to identify default instances. For more information, see Distributed Queries on Multiple Instances of SQL Server.

  • Command prompt utilities.

    When you use the command prompt utilities, you can use the Server switch to specify an instance by using computername\instancename, for example:

    osql -E -Scomputer1\instance1
sqlservr /Sinstance1

    The isql utility does not support named instances.

  • SQL Server 2000 client components.

    Applications using SQL Server 2000 client components can enumerate the instances available for connections:

    • The OLE DB Provider for SQL Server 2000 returns instance names using ISourcesRowset::GetSourcesRowset. The names of named instances are returned as the data source name in the format computername\instancename, where computername can be either the name of a single computer or the virtual server name of a failover cluster. The names of default instances are returned as the data source name in the format computername, with no instance name.

    • The SQL Server 2000 ODBC driver supports extensions to SQLBrowseConnect and SQLSetConnectAttr that allow applications to enumerate instances on a server. ODBC applications can also determine whether the computername is the name of a single computer or a virtual server name for a failover cluster. For more information, see SQLBrowseConnect.

    • SQL-DMO applications can enumerate instances using the SQLServer2 object. The SQLServer2 object also presents information such as the names of the SQL Server and SQL Server Agent services for the instance, or whether the instance is running on a single computer or a failover cluster. For more information, see SQLServer2 Object.

    • DB-Library and Embedded SQL for C do not support named instances.
Identifying Instances

Performance Monitor counters, Profiler events, and Windows events in the Event Viewer Application Log all identify the instance of SQL Server with which they are associated.

The string returned by the @@SERVERNAME function identifies the name of the instance in the form servername\instancename if you are connected to a named instance. If connected to a default instance @@SERVERNAME returns only servername. For more information, see @@SERVERNAME.

The SERVERPROPERTY function INSTANCENAME property reports the instance name of the instance to which you are connected. INSTANCENAME returns NULL if connected to a default instance. In addition, the SERVERNAME property returns the same format string returned by @@SERVERNAME and will have the format servername\instancename when connected to a named instance. For more information, see SERVERPROPERTY.

Although the strings reported by @@SERVERNAME and SERVERNAME use the same format, the information they report can be different, for example:

  • The string returned by @@SERVERNAME is affected by the actions of sp_addserver and sp_dropserver, and the string reported by SERVERNAME is not.

  • SERVERNAME automatically reports changes in the network name of the computer, and @@SERVERNAME does not, unless sp_dropserver and sp_addserver are used to change the name it reports.


Federated SQL Server 2000 Servers

Microsoft® SQL Server™ 2000 databases can be spread across a group of autonomous database servers capable of supporting the processing growth requirements of the largest Web sites and enterprise data-processing systems built with Microsoft Windows® DNA.

Windows DNA divides the processing units of a data processing system into logical tiers:

  • User services tier

    Presents the interface seen by the users, and typically calls the second tier for business logic processing.

  • Business services tier

    Contains the business logic that controls the operation of the Web site, and uses the persistent data storage provided by the third tier.

  • Data services tier

    Stores the persistent data required to run the Web site.

Scaling refers to the process of adding resources to a tier so that it can handle increased workloads. Scaling can be done in one of two ways:

  • Scale up

    Increases the processing power of a server by using a more powerful computer.

  • Scale out

    Increases the processing power of a system designed in a modular fashion, such as becoming a cluster of computers, by adding one or more additional computers, or nodes, to the system.

The growth requirements of the largest Web sites generate processing loads that exceed the capacity of large individual servers. In these cases, scaling out may be the best option for increasing the processing capacity of the system.

Microsoft Windows 2000 COM+ components are designed to be used in clusters of Windows 2000 application servers to form a clustered business services tier. Each server has identical sets of COM+ components, and Windows 2000 balances the cluster processing load by sending new requests to the server that has the least processing load. This forms an easily administered cluster that can quickly scale out by simply adding a new server.

SQL Server 2000 does not support this type of clustering. However, SQL Server 2000 does support updatable distributed partitioned views used to transparently partition data horizontally across a group of servers. Although these servers cooperate in managing the partitioned data, they operate autonomously. Each server is managed independently, has separate operational rules, and can support independent processes and data. A group of autonomous servers that cooperate to process a workload is known as a federation. Although SQL Server 2000 delivers very impressive performance when scaled up on servers with eight or more processors, it can support huge processing loads when partitioned across a federation. A federation of servers running SQL Server 2000 is capable of supporting the growth requirements of any Web site, or of the largest enterprise systems.


Partitioning Data

The first step in building a set of federated database servers is to horizontally partition the data in a set of tables across multiple servers. Horizontally partitioning a table refers to dividing a table into multiple smaller tables, called member tables. Each member table has the same format as the original table, but only part of the rows. Each table is placed on a separate resource (files or servers) to spread the processing load across the resources. For example, a company assigns customer identifiers (IDs) from 1 through 9999999. The Customers table may be partitioned into three member tables, with each member table having an equal customer ID range.

If used without views, horizontal partitioning would require applications to have logic to determine which member tables have the data requested by the user and dynamically build SQL statements referencing the tables. The application would require complex queries joining the member tables. Changing the member tables would also involve recoding the application. Views solve the problem by making the member tables look like one table. The SQL UNION operator combines result sets with identical formats into one. Because all the member tables have the same format, the result of SELECT * statements for each table have the same format, and can be combined using the UNION clause to form a single result set that operates similarly to the original table. For example, the Customers table has been partitioned across three servers (Server1, Server2, and Server3). The distributed partitioned view defined on Server1 is:

CREATE VIEW Customers
AS
SELECT * FROM Customers_33
   UNION ALL
SELECT * FROM Server2.CustomerDB.dbo.Customers_66
   UNION ALL
SELECT * FROM Server3.CustomerDB.dbo.Customers_99

This view makes the actual location of the data transparent to an application. When a SQL statement is executed on Server1 that references the Customers partitioned view, the application has no visibility to where the data is located. If some of the rows required to complete the SQL statement reside on Server2 or Server3, the instance of SQL Server on Server1 automatically generates a distributed query that pulls in the required rows from the other servers. This transparency allows database administrators to repartition tables without recoding applications. If the Customers view is updatable, the behavior of the view is the same as a table named Customers.

Local partitioned views reference member tables on one server. Distributed partitioned views reference member tables on multiple servers. A server containing a member table is called a member server, and a database containing a member table is called a member database. Each member server contains one member table and a distributed partitioned view. An application that references the partitioned view on any of the servers gets the same results as if a complete copy of the original table were present on each server.

Microsoft SQL Server 2000 and Microsoft SQL Server version 7.0 support partitioned views; however, SQL Server 2000 introduces key features that allow the views to scale out and form federations of database servers:

  • SQL Server 2000 partitioned views are updatable. This is crucial for distributing data so that the location of the data is transparent to the application. Updatable views support the full behavior of the original table; nonupdatable views are like read-only copies.

  • The SQL Server 2000 query optimizer supports new optimizations that minimize the amount of distributed data that has to be transferred. The distributed execution plans generated by SQL Server 2000 result in good performance for a larger set of queries than the plans generated by SQL Server version 7.0.

SQL Server 2000 partitioned views are best suited for the types of SQL statements generated by Web sites and online transaction processing (OLTP) systems.

Partitioning a Database

To build an effective federation of database servers:

  • Create multiple databases, each on a different member server running an instance of SQL Server 2000.

  • Partition the individual tables in the original database so that most related data is placed together on a member server. This may require different methods of distributing the data in the various tables across all the member databases; partitioning some tables; making complete copies of other tables in each member database; and leaving some tables intact on the original server.

  • Devise data routing rules that can be incorporated in the business services tier, so that applications can send each SQL statement to the member server that stores most of the data required by the statement.

The most important goal is to minimize distributed processing in such a system. You must be able to collocate related data on the same member server, and then route each SQL statement to a member server that contains most, if not all, of the data required to process the statement. For example, you may find that all the sales, customer, sales personnel, and inventory tables in a database can be partitioned by sales region, and that most SQL statements only reference data in a single region. You can then create member servers where each server has the horizontally partitioned data for one or more regions. If applications can identify the region currently referenced in the user's input, the application can submit any generated SQL statement to the member server containing the data for that region. The only SQL statements that will generate distributed queries are those that reference data from multiple regions.


Failover Clustering Architecture

Microsoft® SQL Server™ 2000 failover clustering increases server availability by allowing a system to automatically switch the processing for an instance of SQL Server from a failed server to a working server. For example, an instance of SQL Server can quickly restore database services to a Web site or enterprise network even if the server running the instance fails. SQL Server 2000 implements failover clustering based on the failover clustering features of the Microsoft Clustering Service (MSCS) in Windows NT® 4.0 and Windows® 2000.

The type of MSCS failover cluster used by SQL Server 2000 consists of multiple server computers (two on Windows NT 4.0, up to four on Windows 2000 Datacenter Server) that share a common set of cluster resources, such as disk drives. Each server in the cluster is called a node. Each server, or node, is connected to the network, and each node can communicate with each other node. Each node runs the same version of MSCS.

The shared resources in the failover cluster are collected into cluster groups. For example, if a failover cluster has four clustered disk drives, two of the drives can be collected in one cluster group and the other two in a second cluster group. Each cluster group is owned by one of the nodes in the failover cluster, although the ownership can be transferred between nodes.

Applications can be installed on the nodes in the failover cluster. These applications are typically server applications or distributed COM objects that users access through network connections. The application executables and other resources are typically stored in one or more of the cluster groups owned by the node. Each node can have multiple applications installed on it.

The failover cluster nodes periodically send each other network messages called heartbeat messages. If the MSCS software detects the loss of a heartbeat signal from one of the nodes in the cluster, it treats the server as a failed server. MSCS then automatically transfers the cluster groups and application resources of that node to the other nodes in the network. The cluster administrator specifies the alternate nodes to which cluster groups are transferred when any given node fails. The other nodes then continue processing user network requests for the applications transferred from the failed server.

For more information about MSCS, see the Windows NT Server, Windows 2000 Server, Windows 2000 Advanced Server, or Windows 2000 Datacenter documentation.


SQL Server 2000 Failover Clusters

You can install up to 16 instances of Microsoft® SQL Server™ 2000 in a Microsoft Clustering Service (MSCS) failover cluster.

You install an instance of SQL Server 2000 by running SQL Server Setup on one of the nodes of the cluster. The Setup program installs the instance on the nodes of the failover cluster that you specify during setup. The SQL Server 2000 executable files are installed on the local disk drives of each node in the failover cluster. This means that each node must have a local hard drive that is assigned the same drive letter as on all the other nodes, and that drive letter must be in the path of the location you specify for the SQL Server executable files during setup. For example, if you specify C:\Program Files\Microsoft SQL Server as the location in which to install the SQL Server executables, each node in the cluster must have drive letter C mapped to a local drive. The registry information for the instance is also stored in the registry of each node in the failover cluster.

An MSCS cluster group is a collection of clustered resources, such as clustered disk drives, which are owned by one of the failover cluster nodes. The ownership of the group can be transferred from one node to another, but each group can only be owned by one node at a time. The database files for an instance of SQL Server 2000 are placed in a single MSCS cluster group owned by the node on which you install the instance. If a node running an instance of SQL Server fails, MSCS switches the cluster group containing the data files for that instance to another node. Since the new node already has the executable files and registry information for that instance of SQL Server on its local disk drive, it can start up the instance of SQL Server and start accepting connection requests for that instance.

Because the executable files and registry information for each instance of SQL Server 2000 is stored in each node, the SQL Server 2000 limit of 16 instances per computer also applies to each failover cluster. Each instance in the failover cluster must either have a unique instance name or be a default instance. There can only be one default instance per failover cluster.

The MSCS cluster group that holds the database files for an instance is associated with a SQL Server virtual server name during SQL Server setup. There can only be one instance per virtual server, which also means that there can only be one instance associated with any cluster group.

When an application attempts to connect to an instance of SQL Server 2000 running on a failover cluster, the application must specify both the virtual server name and the instance name. The application does not have to specify an instance name only if the instance associated with the virtual server is a default instance that does not have a name.

For example:

  • A Windows cluster administrator creates a failover cluster with two nodes: NodeA and NodeB. Each node maps the drive letter C to a local hard drive.

  • There is one shared disk in the cluster. The cluster administrator creates ClusterGroupA to hold the drive, and assigns it to NodeA.

  • The SQL Server system administrator runs the Setup program to install a default instance of SQL Server on NodeA. During setup, the administrator specifies a SQL Server virtual server name of VirtualServerX, and specifies that the database files be placed on the drive in ClusterGroupA. Setup installs the SQL Server executable files on the local drives of both NodeA and NodeB, and places the database files in ClusterGroupA.

  • Applications attempting to connect to the default instance only need to specify the virtual server name VirtualServerX. The default instance normally runs on NodeA. Should NodeA fail, however, the MSCS clustering will transfer ownership of ClusterGroupA to NodeB and will restart the default instance on NodeB. Applications will still connect to the default instance by specifying the virtual server name VirtualServerX.

See Also

Failover Clustering

Installing a Virtual Server Configuration


Active Directory Integration

The Microsoft® Windows® 2000 Active Directory™ operates as a secure central resource for storing information about the users, devices, and services available on a Windows 2000 network. Microsoft SQL Server™ 2000 supports registering instances of the SQL Server relational engine, databases, replication publications, and Analysis servers in the Active Directory. The SQL Server tools also provide a dialog box that supports browsing for replication publications registered in the Active Directory.

SQL Server Objects in the Active Directory Hierarchy

The Active Directory uses a hierarchy to represent the relationships between network entities such as users, services, and devices (such as computers, scanners, or printers). The hierarchy starts from a single root node at the top and branches down to leaf nodes representing individual entities in the network. The intermediate nodes in the hierarchy are containers that hold references to multiple entities. For example, several Windows users can be collected into a group for administrative purposes. Each node is implemented as an Active Directory object that represents the specific entity for that node.

When you register an instance of the SQL Server relational database engine in the Active Directory, an MS-SQL-SQLServer object is added as a Service Connection Point (SCP) object in the container for the computer on which the instance is running. An SCP is the type of Active Directory object that represents services available on the network. An SCP object records information about the service, such as connection information. An Analysis server is also registered as an SCP of the computer on which the Analysis server is running.

After registering an instance of the SQL Server relational database engine in the Active Directory, you can also register the replication publications that reside in the instance. The publications are registered as children of the instance. After registering replication publications in the Active Directory, the Create Pull Subscription Wizard supports a dialog box that allows users to search for registered publications in the Active Directory. For more information, see Active Directory Services.

After registering an instance of the relational database engine in the Active Directory, members of the sysadmin fixed server role can also register any databases in that instance. In SQL Server Enterprise Manager, right-click the database and select Properties. The Options tab has a check box at the bottom that controls whether the database is registered in the Active Directory. When you select the checkbox, the database is registered in the Active Directory when you close the Properties dialog box. After the check box is selected, the database object in the Active Directory is refreshed each time you close the Properties dialog box, provided the check box is selected when you open the Properties dialog box and remains checked when you click OK to close the dialog box. You can also use the sp_ActiveDirectory_Obj stored procedure to register databases from Transact-SQL scripts or applications.

You can register Analysis servers in the Active Directory. For more information, see Using Active Directory with Analysis Services. The SQL Server 2000 tools do not provide any facilities for browsing the Active Directory for instances of the relational database engine, Analysis servers, or relational databases. Applications can be coded to browse the Active Directory for the objects used to register these SQL Server entities.

The Active Directory class objects supported by SQL Server 2000 are defined in the Windows 2000 Active Directory schema:

Active Directory Object Name | SQL Server Entity
MS-SQL-SQLServer | An instance of SQL Server
MS-SQL-SQLPublication | A replication publication defined in an instance of SQL Server.
MS-SQL-SQLDatabase | A database in an instance of SQL Server.
MS-SQL-OLAPServer | An instance of the SQL Server Analysis server.

SQL Server 2000 makes no extensions to the definitions of these objects; SQL Server uses the objects as defined in the Windows 2000 Active Directory schema. Users can also code Active Directory Service Interfaces (ADSI) applications that browse the Active Directory for registered instances of SQL Server, Analysis servers, publications, and databases, For more information about ADSI and the structure of Active Directory schema objects, see the MSDN® Library at Microsoft Web site.

Note SQL Server 2000 does not use the MS-SQL-OLAPCube, MS-SQL-OLAPDatabase, or MS-SQL-SQLRepository class objects defined in the Windows 2000 Active Directory schema.

See Also

MSSQLServerADHelper Service

sp_ActiveDirectory_SCP


SQL Server and XML Support

Extensible Markup Language (XML) is a hypertext programming language used to describe the contents of a set of data and how the data should be output to a device or displayed in a Web page. Markup languages originated as ways for publishers to indicate to printers how the content of a newspaper, magazine, or book should be organized. Markup languages for electronic data perform the same function for electronic documents that can be displayed on different types of electronic gear.

Both XML and the Hypertext Markup Language (HTML) are derived from Standard Generalized Markup Language (SGML). SGML is a very large, complex language that is difficult to fully use for publishing data on the Web. HTML is a more simple, specialized markup language than SGML, but has a number of limitations when working with data on the Web. XML is smaller than SGML and more robust than HTML, so is becoming an increasingly important language in the exchange of electronic data through the Web or intracompany networks.

In a relational database such as Microsoft® SQL Server™ 2000, all operations on the tables in the database produce a result in the form of a table. The result set of a SELECT statement is in the form of a table. Traditional client/server applications that execute a SELECT statement process the results by fetching one row or block of rows from the tabular result set at a time and mapping the column values into program variables. Web application programmers, on the other hand, are more familiar with working with hierarchical representations of data in XML or HTML documents.

SQL Server 2000 introduces support for XML. These new features include:

  • The ability to access SQL Server through a URL.

  • Support for XML-Data schemas and the ability to specify XPath queries against these schemas.

  • The ability to retrieve and write XML data:
    • Retrieve XML data using the SELECT statement and the FOR XML clause.

    • Write XML data using the OpenXML rowset provider.
  • Enhancements to the Microsoft SQL Server 2000 OLE DB provider (SQLOLEDB) that allow XML documents to be set as command text and to return result sets as a stream.

See Also

XML and Internet Support Overview

Accessing SQL Server Using a URL

Creating XML Views Using Annotated Schemas

Using XPath Queries

Retrieving and Writing XML Data


Managing Clients

A client is a front-end application that uses the services provided by a server. The computer that hosts the application is referred to as the client computer. Client software enables computers to connect to an instance of Microsoft® SQL Server™ on a network.

SQL Server clients can include applications of various types, such as:

  • OLE DB consumers.

    These applications use the Microsoft OLE DB Provider for SQL Server or the Microsoft OLE DB Provider for ODBC to connect to and converse with instances of SQL Server. The OLE DB providers serve as intermediaries between an instance of SQL Server and client applications that consume SQL Server data as OLE DB rowsets.

  • ODBC applications.

    These include client utilities installed with SQL Server, such as SQL Server Enterprise Manager and SQL Query Analyzer, as well as other applications that use the SQL Server ODBC driver to connect to and converse with an instance of SQL Server.

  • DB-Library clients, including the SQL Server isql command prompt utility and clients written to DB-Library.

Regardless of the type of application, managing a client consists mainly of configuring its connection with the server components of SQL Server. Depending on the requirements of your site, client management can range from little more than entering the name of the server computer to building a library of custom configuration entries to accommodate a diverse multiserver environment.


How to start the Client Network Utility (Windows)

To start the Client Network Utility

  • On the Start menu, point to Programs/Microsoft SQL Server, and then click Client Network Utility.


How to display the network library version numbers (Client Network Utility)

To display the library version numbers

  • Click the Network Libraries tab.

    The network library, library file name, version, file date, and size are displayed.


How to set DB-Library conversion preferences (Client Network Utility)

Note This procedure applies to Microsoft® Windows® 32-bit operating system clients.

To set the DB-Library conversion preferences

  1. Click the DB-Library Options tab.

  2. Select or clear the Automatic ANSI to OEM conversion check box.

  3. Select or clear the Use international settings check box.


How to add a network library configuration (Client Network Utility)

To add a network library configuration

  1. Click the Alias tab, and then click Add.

  2. In the Add Network Library Configuration dialog box, under Network libraries, select one of the network libraries.

  3. Enter the server alias and any required parameter information for the network library selected.


How to edit a network library configuration (Client Network Utility)

To edit a network library configuration

  1. Click the Alias tab, and then click the network protocol configuration to edit.

  2. Click Edit.

  3. In the Edit Network Library Configuration dialog box, edit the information to change.


How to delete a network library configuration (Client Network Utility)

To delete a network library configuration

  1. Click the Alias tab, and then click the network library configuration to delete.

  2. Click Remove.


How to alias a client to an alternate pipe (Client Network Utility)

To alias a client to an alternate pipe

  1. Click the Alias tab, and then click Add.

  2. In the Add Network Library Configuration dialog box, click Named Pipes.

  3. In the Server alias box, enter the server alias.

  4. Under Connection parameters, in the Pipe name box, type the name of the alternate pipe name (for example, \\myserver\pipe\altpipe).


How to configure a client to use the Multiprotocol Net-Library (Client Network Utility)

Note Before creating a Multiprotocol client configuration, make sure your computer has at least one IPC protocol loaded under Multiprotocol on the server (Named Pipes, NWLink IPX/SPX, TCP/IP, or Windows Sockets).

To configure a client to use the Multiprotocol Net-Library

  1. Click the Alias tab, and then click Add.

  2. In the Add Network Library Configuration dialog box, click Multiprotocol.

  3. In the Server alias box, enter the name of the instance of Microsoft® SQL Server™ listening on the Multiprotocol Net-Library.

  4. Leave the Additional parameters box empty, unless the server requires specific parameters. Verify with your network administrator before entering parameters.


How to configure a client to use TCP/IP (Client Network Utility)

To configure a client to use TCP/IP

  1. Click the General tab, and then click Add.

  2. In the Add Network Library Configuration dialog box, click TCP/IP.

  3. In the Server alias box, enter the alias of the instance of Microsoft® SQL Server™ listening on the Windows Sockets Net-Library.

    With TCP/IP, you can also specify the server with its IP address instead of its name.

  4. Do one of the following:
    • Select the Dynamically determine port check box to automatically determine the port.

    • Clear the Dynamically determine port check box to set the port manually, and then in the Port number box, type the port number.

For more information about other TCP/IP protocols that support Windows Sockets, see the TCP/IP documentation.


How to configure a client to use the NWLink IPX/SPX network library (Client Network Utility)

To configure a client to use the NWLink IPX/SPX network library

  1. Click the Alias tab, and then click Add.

  2. In the Add Network Library Configuration dialog box, click NWLink IPX/SPX.

  3. In the Server alias box, enter the alias of the instance of Microsoft® SQL Server™ listening on the NWLink IPX/SPX Net-Library.

  4. Under Connection parameters, click either Service name or Network address, and then do one of the following:
    • If you clicked Service name, enter the service name.

      Service name is the Microsoft Windows NT® 4.0 or Windows® 2000 computer name under which an instance of SQL Server is running. This name is stored in the Bindery of the server computer.

    • If you clicked Network address, enter the address (the MAC address), port (socket number), and network (NetWare network number).


How to configure a client to use the AppleTalk network library (Client Network Utility)

To configure a client to use the AppleTalk network library

  1. Click the Alias tab, and then click Add.

  2. In the Add Network Library Configuration dialog box, click AppleTalk.

  3. In the Server alias box, enter the name of the instance of Microsoft® SQL Server™ listening on the AppleTalk Net-Library.

  4. Under Connection parameters, type the AppleTalk object name and optional zone identifiers.


How to configure a client to use the Banyan VINES network library (Client Network Utility)

To configure a client to use the Banyan VINES network library

  1. Click the Alias tab, and then click Add.

  2. In the Add Network Library Configuration dialog box, click Banyan VINES.

  3. In the Server alias box, enter the alias of the instance of Microsoft® SQL Server™ listening on the Banyan VINES Net-Library.

  4. Under Connection parameters, type the service and the VINES organization. You can use the default value of MSSQL for group.


How to configure a client to use the VIA network library (Client Network Utility)

To configure a client to use the Banyan VINES network library

  1. Click the Alias tab, and then click Add.

  2. In the Add Network Library Configuration dialog box, click VIA.

  3. In the Server alias box, enter the alias of the instance of Microsoft® SQL Server™ listening on the VIA Net-Library.

  4. Under Connection parameters, type the server name and server port number.


How to configure a client to use a nonstandard network library (Client Network Utility)

To configure a client to use a nonstandard network library

  1. Click the Alias tab, and then click Add.

  2. In the Add Network Library Configuration dialog box, click Other.

  3. In the Server alias box, enter the alias of the instance of Microsoft® SQL Server™ listening on the Net-Library you plan to install.

  4. Under Connection parameters, type the file name (file must be a DLL) of the installed Net-Library. Do not enter the DLL extension.

  5. If necessary, enter any additional information in the Parameters box (such as user name and password). Use comma separators between parameters.


How to verify that SQL Server is listening on AppleTalk and can accept a client connection (Client Network Utility)

To verify that SQL Server is listening on AppleTalk and can accept a client connection

  1. Copy the client AppleTalk Net-Library (Dbmsadsn.dll) from the \WINNT\system32 directory of the server to the same directory of a remote computer running Microsoft® Windows NT® or Microsoft Windows® 2000 Services for Macintosh.

  2. On the remote workstation, start SQL Server Client Configuration.

  3. If AppleTalk is listed in the Disabled protocols list, click AppleTalk, and then click Enable.

  4. In the Enabled protocols by order list, click AppleTalk, and then click the up button until AppleTalk is at the top of the list.

  5. Click OK.

  6. Attempt an ISQL connection with the AppleTalk service object name.

For example, at the command line, type:

isql -Usa -Psapassword -Sservicename

If you can connect with ISQL and execute queries, the server is configured properly and is accepting connections.

Note The Microsoft Win32® AppleTalk (ADSP) client side Net-Library (Dbmsadsn.dll) is included for testing ADSP connections and troubleshooting AppleTalk connections between Macintosh clients and Microsoft SQL Server™. This Net-Library is intended to be used only when testing a connection from a remote client to an instance of SQL Server. If you attempt to make local connections through the ADSP Net-Library to an instance of SQL Server listening on AppleTalk, you will receive the following network error: Net-Library error 11: getsockopt().


How to check the ODBC SQL Server driver version (Windows)

Note You can follow these steps only if you are running the Microsoft® Windows NT® 4.0 operating system.

To check the ODBC SQL Server driver version (32-bit ODBC)

  1. In Control Panel, double-click ODBC Data Sources.

  2. Click the Drivers tab.

    Information for the Microsoft SQL Server™ entry is displayed in the Version column.


Using the Copy Database Wizard

The Copy Database Wizard allows you to copy or move databases between servers. You can move and copy databases between different instances of Microsoft® SQL Server™ 2000, and you can upgrade databases from SQL Server version 7.0 to SQL Server 2000. For more information, see Database Upgrade from SQL Server 7.0 (Copy Database Wizard).

To upgrade databases online using the Copy Database Wizard

Wizard

Wizard

You also can simplify the administration and maintenance of your databases by integrating multiple instances of SQL Server 7.0 or SQL Server 2000 into a single instance of SQL Server 2000 or into several named instances on a single computer.

In addition to copying the actual databases, you also can copy associated meta data (for example, logins and objects from the master database required by the databases being copied).

Note It not possible to copy or move the model, msdb, or master databases using the Copy Database Wizard.

The Copy and Move Process

To use the Copy Database Wizard, you must be a system administrator or a member of the sysadmin role. If you are running Microsoft Windows NT® 4.0 or Microsoft Windows® 2000, your user account must have administrator privileges on both the source server and the destination server.

To use the Copy Database Wizard, you must specify:

  • The source server on which the databases to be copied reside.

  • The destination server to which the databases are to be copied or moved.

    On the destination server, databases keep the same name they had on the source server. Therefore, only databases with source names that do not exist on the destination server can be moved or copied. Databases cannot be renamed during a move or copy operation. Name conflicts must be resolved manually prior to moving or copying databases.

  • The databases to be moved or copied.

    To avoid data loss or inconsistency, you must be sure there are no active sessions attached to the database being moved or copied. If there are active sessions, the Copy Database Wizard will not run.

  • Other objects to be copied or moved (for example, logins, shared objects from the master database, jobs and maintenance plans, and user-defined error messages).

  • The schedule for the copy or move operation, if you want it to run at a later time.

When moving databases between different servers or disk drives, the Copy Database Wizard copies the database to the destination server and verifies that it is online. The wizard does not delete the database from the source server. You must delete the files from the source server manually after you have verified that the copy is fully operational. When moving databases between two instances on the same server, the file system move operation is performed.


Managing Security

A database must have a solid security system to control which activities can be performed and which information can be viewed and modified. A solid security system ensures the protection of data, regardless of how users gain access to the database.

This section describes the security tools built into Microsoft® SQL Server™ 2000 and includes information about:

  • Security Architecture

  • Planning Security

  • Creating Security Accounts

  • Managing Security Accounts

  • Managing Permissions

  • Advanced Security Topics

  • Auditing SQL Server Activity


Security Architecture

New Information - SQL Server 2000 SP3.

The architecture of a security system is based on users and groups of users. The following illustration shows how users and local and global groups in Microsoft® Windows NT® 4.0 and Windows® 2000 can map to security accounts in Microsoft SQL Server™, and how SQL Server can handle security accounts independently of the accounts in Windows NT 4.0 and Windows 2000.

Security Note When possible, use Windows Authentication.

The CORPUSERS local group contains two users and a global group, Mktg, which also contains two users. SQL Server allows Windows NT 4.0 and Windows 2000 local and global groups to be used directly to organize its user accounts. Additionally, the Windows NT 4.0 users Fred and Jerry, not part of a Windows NT 4.0 group, can be added to an instance of SQL Server either directly as a Windows NT 4.0 user (Fred for example), or as a SQL Server user (Jerry).

SQL Server extends this model further with the use of roles. Roles are groups of users organized for administrative purposes, like Windows NT 4.0 or Windows 2000 groups, but are created in SQL Server when an equivalent Windows NT 4.0 or Windows 2000 group does not exist. For example, the Managers role contains the Windows NT 4.0 Mktg global group and the Windows NT 4.0 users Frank and Fred.

SQL Server also provides security at the application level through the use of individual database application roles.

For more information, see the Windows NT 4.0 or Windows 2000 documentation.

See Also

Creating Security Accounts


Planning Security

A security plan identifies which users can see which data and perform which activities in the database. To develop a security plan:

  1. List all the items and activities in the database that must be controlled through security.

  2. Identify the individuals and groups in the company.

  3. Cross-reference the two lists to identify which users can see which sets of data and perform which activities in the database.

See Also

Single Person Security Example

Small Company Security Example

Corporate Environment Security Example


Single Person Security Example

New Information - SQL Server 2000 SP3.

In the simplest possible security system, a single person is responsible for all aspects of the database and will be its sole user. This hypothetical user (Tom Brown in London) must be able to:

  • Create the database and its tables.

  • Write programs that interface with the data.

  • Load and maintain data.

  • Produce reports.

The users-to-activity map for this example lists the single user and the activities he needs to perform.

User account | Activity
LONDON\tombrown | All database access

The first step in creating a security system is to grant login permission to the LONDON\tombrown Windows user account. Because the predefined sysadmin role contains all permissions necessary for this user, the LONDON\tombrown login account should be added as a member of the sysadmin role. When LONDON\tombrown connects to an instance of SQL Server, SQL Server calls back to Microsoft Windows NT® 4.0 or Windows® 2000 to authenticate the connection. If it is validated, the connection is accepted, and the login is allowed to perform activities based on the permissions associated with the sysadmin role.

If Tom Brown did not have a Windows NT 4.0 or Windows 2000 login, he could be given a SQL Server login. In this case, an instance of SQL Server would need to be running under Mixed Mode, which allows users to log in under Windows NT 4.0, Windows 2000, or SQL Server logins. A login named tombro could be added to SQL Server independent of the Windows NT 4.0 or Windows 2000 login, and tombro could then be added to the sysadmin role. When the user logs into Windows NT 4.0 or Windows 2000 and attempts to connect to an instance of SQL Server, he must specify the tombro login name and password that SQL Server knows.

Security Note When possible, use Windows Authentication.


Small Company Security Example

New Information - SQL Server 2000 SP3.

In a moderately complex security system, multiple people perform various tasks in the database. For example, a database administrator is responsible for the database environment: creating the database, tables, and security accounts, performing backups, and tuning the database. Two developers are responsible for writing client applications to provide an interface to the data. Managers prepare information reports from the database and so need access to all available data. The administrative staff performs customer and sales data entry and must be able to view all data.

The users-to-activity map for this example is slightly more complicated than a single user database.

User account | Activity
LONDON\joetuck | All database access.
LONDON\marysmith, LONDON\billb | Full access to data and the ability to create procedures.
LONDON\managers | Full access to all data.
LONDON\admins | Full access to customer data and sales. Read-only access for all other data.

The first step in installing the security for this example is to grant login permission to LONDON\joetuck. Then, because the LONDON\joetuck login requires full access, the next step is to add this user to the sysadmin role.

Login permissions must also be added for the developers, LONDON\marysmith and LONDON\billb. Since these developers are not system administrators, do not add them to the sysadmin server role. Instead, grant them access to the database, and then grant object and statement permissions in the database.

However, if you granted these permissions to each developer, the same time-consuming task would have to be performed each time another developer (or another 10 developers) joined the project. A better solution is to add a SQL Server database role named developers, granting object and statement permissions to the role. When developer accounts such as LONDON\marysmith and LONDON\billb are added to the developers role, they automatically obtain the permissions granted to the role.

Finally, login rights must be added to SQL Server for the LONDON\managers and LONDON\admins Windows groups. You then add database user accounts for the groups. You can assign permissions to the group user accounts or you can create database roles, to which you can add the group user accounts. When a member of the LONDON\managers group connects, the member is recognized as a member of the Windows group and is allowed to connect to SQL Server. The login is granted any database permissions granted to the group's user account and any roles to which the group belongs. The same is true for members of the LONDON\admins group.


Corporate Environment Security Example

In a large corporate security system, there is a complex web of users who perform specialized, exclusive tasks.

A single person is responsible for all aspects of the database application. A few people are responsible for creating databases and tables, but they must not be allowed to see sensitive personnel information about their coworkers (or even themselves). An evening team backs up data, but these workers need not see the data, nor create tables and databases. The Personnel department must have access to general employee information, and a few select individuals in this department are the only people in the company with access to confidential and sensitive employee information. Also, customer service employees need to see but not change product specifications in response to customer inquiries.

The users-to-activity map for this example is fairly complex.

User account | Activity
LONDON\annej | All database access
LONDON\dbadmins | Create databases
LONDON\dboperations | Perform evening backups
LONDON\personnel | Full access to general employee data
LONDON\mikebo, LONDON\marym, LONDON\billsm | Full access to confidential data
LONDON\custservice | Read-only access to product information

The LONDON\annej user account must be granted login rights to Microsoft® SQL Server™ and added to the sysadmin role because the sysadmin role has full permissions across the server. The LONDON\dbadmins Microsoft Windows NT® 4.0 and Windows® 2000 group user account must be added in SQL Server and granted permission to create databases. The LONDON\operations Windows NT 4.0 group should be added also and granted only the BACKUP DATABASE permissions to allow them to perform backups.

The LONDON\personnel Windows NT 4.0 and Windows 2000 group should be added and granted the permissions to see only the nonsensitive columns in the employees table, as well as the permissions to see other tables.

The users LONDON\mikebo, LONDON\marym, and LONDON\billsm are members of the LONDON\personnel Windows NT 4.0 group, so they already have the permissions necessary to do most of their work. However, they also need special access to the sensitive employee information columns. To meet this need, create a database role called PersonnelSecure in SQL Server and grant the permissions required to see the sensitive employee information. Individual users get the special permissions in SQL Server when added to the role. Or, add the special permissions to their user accounts directly.

The final step is to add an account for the LONDON\custservice Windows NT 4.0 group in SQL Server, and grant it permission to see product information.


Security Levels

A user passes through two stages of security when working in Microsoft® SQL Server™: authentication and authorization (permissions validation). The authentication stage identifies the user using a login account and verifies only the ability to connect to an instance of SQL Server. If authentication is successful, the user connects to an instance of SQL Server. The user then needs permissions to access databases on the server, which is done by granting access to an account in each database, mapped to the user login. The permissions validation stage controls the activities the user is allowed to perform in the SQL Server database.


Authentication Modes

New Information - SQL Server 2000 SP3.

Microsoft® SQL Server™ can operate in one of two security (authentication) modes:

  • Windows Authentication Mode (Windows Authentication)

    Windows Authentication mode allows a user to connect through a Microsoft Windows NT® 4.0 or Windows® 2000 user account.

  • Mixed Mode (Windows Authentication and SQL Server Authentication)

    Mixed Mode allows users to connect to an instance of SQL Server using either Windows Authentication or SQL Server Authentication. Users who connect through a Windows NT 4.0 or Windows 2000 user account can make use of trusted connections in either Windows Authentication Mode or Mixed Mode.

    SQL Server Authentication is provided for backward compatibility. For example, if you create a single Windows 2000 group and add all necessary users to that group you will need to grant the Windows 2000 group login rights to SQL Server and access to any necessary databases.

    Security Note When possible, use Windows Authentication.

Windows Authentication

When a user connects through a Windows NT 4.0 or Windows 2000 user account, SQL Server revalidates the account name and password by calling back to Windows NT 4.0 or Windows 2000 for the information.

SQL Server achieves login security integration with Windows NT 4.0 or Windows 2000 by using the security attributes of a network user to control login access. A user's network security attributes are established at network login time and are validated by a Windows domain controller. When a network user tries to connect, SQL Server uses Windows-based facilities to determine the validated network user name. SQL Server then verifies that the person is who they say they are, and then permits or denies login access based on that network user name alone, without requiring a separate login name and password.

Login security integration operates over any supported network protocol in SQL Server.

Note If a user attempts to connect to an instance of SQL Server providing a blank login name, SQL Server uses Windows Authentication. Additionally, if a user attempts to connect to an instance of SQL Server configured for Windows Authentication Mode by using a specific login, the login is ignored and Windows Authentication is used.

Windows Authentication has certain benefits over SQL Server Authentication, primarily due to its integration with the Windows NT 4.0 and Windows 2000 security system. Windows NT 4.0 and Windows 2000 security provides more features, such as secure validation and encryption of passwords, auditing, password expiration, minimum password length, and account lockout after multiple invalid login requests.

Because Windows NT 4.0 and Windows 2000 users and groups are maintained only by Windows NT 4.0 or Windows 2000, SQL Server reads information about a user's membership in groups when the user connects. If changes are made to the accessibility rights of a connected user, the changes become effective the next time the user connects to an instance of SQL Server or logs on to Windows NT 4.0 or Windows 2000 (depending on the type of change).

Note Windows Authentication Mode is not available when an instance of SQL Server is running on Windows 98 or Microsoft Windows Millennium Edition.

SQL Server Authentication

When a user connects with a specified login name and password from a nontrusted connection, SQL Server performs the authentication itself by checking to see if a SQL Server login account has been set up and if the specified password matches the one previously recorded. If SQL Server does not have a login account set, authentication fails and the user receives an error message.

SQL Server Authentication is provided for backward compatibility because applications written for SQL Server version 7.0 or earlier may require the use of SQL Server logins and passwords. Additionally, SQL Server Authentication is required when an instance of SQL Server is running on Windows 98 because Windows Authentication Mode is not supported on Windows 98. Therefore, SQL Server uses Mixed Mode when running on Windows 98 (but supports only SQL Server Authentication).

Even though Windows Authentication is recommended, SQL Server Authentication may be required for connections with clients other than Windows NT 4.0 and Windows 2000 clients; it may also be necessary for legacy applications.

Note When connecting to an instance of SQL Server running on Windows NT 4.0 or Windows 2000 using Named Pipes, the user must have permission to connect to the Windows NT Named Pipes IPC, \\<computername>\IPC$. If the user does not have permission to connect, it is not possible to connect to an instance of SQL Server using Named Pipes unless either the Windows NT 4.0 or Windows 2000 guest account on the computer is enabled (disabled by default), or the permission "access this computer from the network" is granted to their user account.

To set up Windows Authentication Mode security

Enterprise Manager

Enterprise Manager

SQL-DMO

To set up Mixed Mode security

Enterprise Manager

Enterprise Manager

SQL-DMO

See Also

Backward Compatibility


Security Account Delegation

New Information - SQL Server 2000 SP3.

Security account delegation is the ability to connect to multiple servers, and with each server change, to retain the authentication credentials of the original client. For example, if a user (LONDON\joetuck) connects to ServerA, which then connects to ServerB, ServerB knows that the connection security identity is LONDON\joetuck.

To use delegation, all servers that you are connecting to must be running Microsoft® Windows® 2000, with Kerberos support enabled, and you must be using Microsoft Active Directory™, the directory service for Windows 2000. The following options in Active Directory must be specified as follows in order for delegation to work:

  • The Account is sensitive and cannot be delegated check box must not be selected for the user requesting delegation.

  • The Account is trusted for delegation check box must be selected for the service account of SQL Server.

  • The Computer is trusted for delegation check box must be selected for the server running an instance of Microsoft SQL Server™.

To use security account delegation, SQL Server must have:

  • A Service Principal Name (SPN) assigned by the Windows 2000 account domain administrator.

    The SPN must be assigned to the service account of the SQL Server service on that particular computer. Delegation enforces mutual authentication. The SPN proves that SQL Server is verified on the particular server, at the particular socket address, by the Windows 2000 account domain administrator. You can have your domain administrator establish an SPN for SQL Server with the setspn utility through the Windows 2000 Resource Kit.

    To create an SPN for SQL Server, enter the following code at a command prompt:

    setspn -A MSSQLSvc/Host:port serviceaccount

    For example:

    setspn -A MSSQLSvc/server1.redmond.microsoft.com sqlaccount

    For more information about the setspn utility, see the Windows 2000 documentation.

Before enabling delegation, consider the following:

  • You must be using TCP/IP. You cannot use Named Pipes, because the SPN targets a particular TCP/IP socket. If you are using multiple ports, you must have a SPN for each port.

  • You can also enable delegation by running under the LocalSystem account. SQL Server will self-register at service startup and register the SPN. When SQL Server shuts down, the SPNs will be unregistered for the LocalSystem account.

    Security Note The LocalSystem account has elevated local privileges. Enable delegation using a domain user account whenever possible.

    Note If you change service accounts in SQL Server, you need to delete any previous SPNs and create new ones.

Adding an SPN to SQL Server

To add an SPN on an instance of SQL Server named "myserver.microsoft.com", for an instance listening on port 1433, using service account MYDOMAIN\sqlsvc, run the following at a command prompt:

setspn -A MSSQLSvc/myserver.microsoft.com:1433 sqlsvc

You cannot use the NetBIOS name. You must use the fully qualified DNS name. If the NetBIOS name of the SQL server computer is the same as the domain name, do not specify the domain qualifier for the service account. You must use only the account name.

If the NetBIOS name of the SQL Server computer is not the same as the domain name, you must specify the domain qualifier for the service account, as in the following example:

setspn -A MSSQLSvc/myserver.microsoft.com:1433 MYDOMAIN\sqlsvc

To change and use the LocalSystem account, enter the following code at a command prompt to delete the previously registered SPN :

setspn -D MSSQLSvc/myserver.microsoft.com:1433 sqlsvc

Security Note The LocalSystem account has elevated local privileges. Enable delegation using a domain user account whenever possible.

For more information about security account delegation, see the Windows 2000 documentation.


Permissions Validation

New Information - SQL Server 2000 SP3.

After a user has been authenticated and allowed to log in to an instance of Microsoft® SQL Server™, a separate user account is required in each database the user must access. Requiring a user account in each database prevents users from connecting to an instance of SQL Server and accessing all the databases on a server. For example, if a server contains a personnel database and a recruiting database, users who should be able to access the recruiting database but not the personnel database would have a user account created only in the recruiting database.

The user account in each database is used to apply security permissions for the objects (for example, tables, views, and stored procedures) in that database. This user account can be mapped from Microsoft Windows NT® 4.0 and Windows® 2000 user accounts, Windows NT 4.0 and Windows 2000 groups in which the user is a member, or SQL Server login accounts. If there is no account mapped directly, the user may be allowed to work in a database under the guest account, if one exists. The activities a user is allowed to perform are controlled by the permissions applied to the user account from which they gained access to a database.

Security Note When possible, use Windows Authentication. Also, avoid using the guest account; all logins without their own database permissions obtain the database permissions granted to this account. If you must use the guest account, grant it minimum permissions.

SQL Server accepts commands after a user gains access to a database. All activities a user performs in a database are communicated to SQL Server through Transact-SQL statements. When an instance of SQL Server receives a Transact-SQL statement, it ensures the user has permission to execute the statement in the database. If the user does not have permission to execute a statement or access an object used by the statement, SQL Server returns a permissions error.


Hierarchical Security

The security environment in Microsoft® SQL Server™ is stored, managed, and enforced through a hierarchical system of users. To simplify the administration of many users, SQL Server uses groups and roles:

  • A group is an administrative unit within Microsoft Windows NT® 4.0 and Windows® 2000 that contains Windows NT 4.0 and Windows 2000 users or other groups.

  • A role is an administrative unit within SQL Server that contains SQL Server logins, Windows NT 4.0 and Windows 2000 logins, groups, or other roles.

Arranging users into groups and roles makes it easier to grant or deny permissions to many users at once. The security settings defined for a group are applied to all members of that group. When a group is a member of a higher-level group, all members of the group inherit the security settings of the higher-level group, in addition to the security settings defined for the group itself or user accounts.

The organizational chart of the security system often corresponds to the organizational chart of a company.

These two organizational charts are largely compatible, but there is one common rule for a company's organizational hierarchy that does not apply to the security model: an individual reports only to one manager. This rule implies that an employee can fall into only a single branch of the hierarchical model, as shown in the diagram.

The requirements of a database security system go beyond this one-manager limitation; employees belong to security groups that do not fall within the strict organizational plan of the company. For example, administrative staff exists in every branch of the company and require security permissions regardless of their organizational branch. To support this broader model, the security system in Windows NT 4.0, Windows 2000, and SQL Server allows groups to be defined across a hierarchy. An Administrative group can be created to contain administrative employees for every branch of the company from the Corporate group to the Payroll group.

This hierarchical system of security groups simplifies management of security settings. It allows security settings to be applied collectively to all group members, without having to be defined redundantly for each person. The hierarchical model also accommodates security settings applied only to a single user.


Creating Security Accounts

New Information - SQL Server 2000 SP3.

Each user must gain access to an instance of Microsoft® SQL Server™ through a login account that establishes the user's ability to connect (authentication). This login then has to be mapped to a SQL Server user account, which is used to control activities performed in the database (permissions validation). Therefore, a single login is mapped to one user account created in each database the login is accessing. If no user account exists in a database, the user cannot access the database even though the user may be able to connect to an instance of SQL Server.

Security Note Avoid using the guest account; all logins without their own database permissions obtain the database permissions granted to this account. If you must use the guest account, grant it minimum permissions.

The accounts used to log in to SQL Server are either created in SQL Server (and use SQL Server Authentication) or are created in Microsoft Windows NT® 4.0 or Windows® 2000 and granted login rights (using Windows Authentication).

Security Note When possible, use Windows Authentication.


Security Rules

New Information - SQL Server 2000 SP3.

Microsoft® SQL Server™ logins, users, roles, and passwords can contain from 1 through 128 characters, including letters, symbols, and digits, (for example Andrew-Fuller, Margaret Peacock, or 13&#57abc). Therefore, Microsoft Windows NT® 4.0, Microsoft Windows® 2000, or Microsoft Windows 98 user names can be used as SQL Server logins.

However, because logins, user names, roles, and passwords are often used in Transact-SQL statements, certain symbols must be delimited with double quotation marks ("), or square brackets ([ ]). Use delimiters in Transact-SQL statements when the SQL Server login, user, role, or password:

  • Contains, or begins with, a space character.

  • Begins with the $ or @ character.

    Note It is not necessary to specify delimiters when entering logins, users, roles, and passwords into the text boxes of the SQL Server graphical client tools, such as SQL Server Enterprise Manager.

Additionally, a SQL Server login, user, or role cannot:

  • Contain a backslash (\) character, unless referring to an existing Windows NT 4.0 or Windows 2000 user or group. The backslash separates the Windows NT 4.0 or Windows 2000 computer or domain name from the user name.

  • Already exist in the current database (or master, for logins only).

  • Be NULL, or an empty string ("").

If used in an OLE DB or ODBC connection string, a login or password must not contain the following characters: []{}(),;?*! @. These characters are used to either initialize the connection or separate connection values.

Security Note Use strong passwords. A strong password makes it more difficult for unauthorized users to break into a system by cracking the password. A strong password is at least seven characters long; contains a combination of letters, numbers, and symbol characters within the password; and is not a dictionary word, command name, person's name, or system user name. A strong password also is updated regularly and is significantly different from previous passwords.

SQL Server user names and passwords must follow the rules above when used in Transact-SQL statements and connection strings.

See Also

Delimited Identifiers


Adding a Windows User or Group

Microsoft® Windows NT® 4.0 and Windows® 2000 accounts (users or groups) must be granted permissions to connect to an instance of Microsoft SQL Server™ before they can access a database. If all members of a Windows NT 4.0 or Windows 2000 group will be connecting to an instance of SQL Server, you can grant permission to the group as a whole. Managing group permissions is much easier than managing permissions for individual users. If the group should not be granted permission collectively, grant permission to connect to an instance of SQL Server for each individual Windows NT 4.0 or Windows 2000 user.

Users

When granting a Windows NT 4.0 or Windows 2000 user access to connect to an instance of SQL Server, specify the Windows NT 4.0 or Windows 2000 domain or computer name to which the user belongs, followed by a backslash, and then the user. For example, to grant access to the Windows NT 4.0 or Windows 2000 user Andrew, in the Windows NT 4.0 or Windows 2000 domain LONDON, specify LONDON\Andrew as the user name.

Local and Global Groups

There are several types of Windows NT 4.0 and Windows 2000 groups, including global and local:

  • Global groups contain user accounts from the Windows NT 4.0 or Windows 2000 domain in which they are created. Global groups cannot contain other groups or users from other domains and cannot be created on a computer running Microsoft Windows NT 4.0 Workstation or Microsoft Windows 2000 Professional.

  • Local groups can contain user accounts and global groups from the domain in which they are created and in any trusted domain. Local groups cannot contain other local groups.

Additionally, Windows NT 4.0 and Windows 2000 have predefined, built-in local groups (for example, Administrators, Users, and Guests).

When granting a Windows NT 4.0 or Windows 2000 local or global group access to connect to an instance of SQL Server, specify the domain or computer name the group is defined on, followed by a backslash, and then the group name. For example, to grant access to a global group called SQL_Users, in the LONDON domain, specify LONDON\SQL_Users as the group name.

To grant access to a Windows NT 4.0 or Windows 2000 built-in, local group, specify BUILTIN instead of the domain or computer name. To grant access to the built-in Windows NT 4.0 and Windows 2000 local group Administrators, specify BUILTIN\Administrators as the group name.

For more information about these accounts, see the Windows NT 4.0 and Windows 2000 documentation.

To grant a Windows user or group login access to SQL Server

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO


Granting a Windows User or Group Access to a Database

To obtain access to a Microsoft® SQL Server™ database, a Microsoft Windows NT® 4.0 and Windows® 2000 user or group must have a corresponding user account in each database they need to access. Additionally, permissions must be applied to this user account.

Although possible, it is not necessary to add an individual user account in a database for each Windows NT 4.0 and Windows 2000 user in a Windows NT 4.0 and Windows 2000 group whose members all perform the same activities. Accounts can be added for groups rather than for each individual member. When the group members need to work in a database, they are granted access through their membership in the Windows NT 4.0 and Windows 2000 group; there is not a specific account for individual users within the group. For example, a Windows NT 4.0 and Windows 2000 group London\Managers contains the Windows NT 4.0 and Windows 2000 user London\JoeB. The SQL Server system administrator grants login access only to London\Managers. The owner of database Accounts grants only London\Managers permission to access Accounts. Although London\JoeB does not have explicit permission granted to connect to an instance of SQL Server or to access Accounts, he can connect to the instance of SQL Server and access Accounts due to his membership in London\Managers.

Add individual Windows NT 4.0 and Windows 2000 users to a database only if the user performs activities different from other members of any Windows NT 4.0 or Windows 2000 group (for example, special database administrative duties).

Note Users who are granted access to an instance of SQL Server through their memberships in a Windows NT 4.0 or Windows 2000 group do not have entries for their individual Windows NT 4.0 or Windows 2000 user accounts in the system tables. However, an entry is created for their individual user accounts if they create objects, such as a table or a stored procedure, in a SQL Server database.

To grant a Windows user or group access to a database

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO


Adding a SQL Server Login

New Information - SQL Server 2000 SP3.

Security Note When possible, use Windows Authentication.

Add Microsoft® SQL Server™ login accounts that allow a connection by means of a specified login name and password, rather than through a Microsoft Windows NT® 4.0 or Windows® 2000 user or group account, if:

  • An instance of SQL Server is running on Microsoft Windows 98.

  • SQL Server is configured to operate in Mixed Mode and you must add SQL Server logins accounts for connections from clients that do not use supported versions of Windows or from legacy applications that use SQL Server Authentication.

Adding SQL Server logins is required:

  • For applications that connect to products from other vendors.

  • For applications designed to for users who do not have Windows NT 4.0 or Windows 2000 accounts.

  • To connect to an instance of SQL Server running on Windows 98.

To add a SQL Server login

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO


System Administrator (sa) Login

New Information - SQL Server 2000 SP3.

System administrator (sa) is a special login provided for backward compatibility. By default, it is assigned to the sysadmin fixed server role and cannot be changed. Although sa is a built-in administrator login, do not use it routinely. Instead, make system administrators members of the sysadmin fixed server role, and have them log on using their own logins. Use sa only when there is no other way to log in to an instance of Microsoft® SQL Server™ (for example, when other system administrators are unavailable or have forgotten their passwords).

During installation, SQL Server Setup prompts you to set an sa login password if you request Mixed Mode authentication. You should assign a password immediately to prevent unauthorized access to an instance of SQL Server using the sa login.

By contrast, if you select Windows Authentication during installation, assign a password to the sa login after installation to ensure that the sa login has a password in case you later change the mode to Mixed Mode authentication.

Security Note Do not use a blank password. Use a strong password. For more information, see Security Rules.

See Also

Assigning an sa Password


Granting a SQL Server Login Access to a Database

New Information - SQL Server 2000 SP3.

Security Note When possible, use Windows Authentication.

Add a Microsoft® SQL Server™ user account to each database for each SQL Server login that requires access to the database. If a user is not created in the database, the SQL Server login cannot access the database.

To grant a SQL Server login access to a database, the SQL Server login must already exist. Furthermore, SQL Server logins must be granted access to a database one at a time.

To grant a SQL Server login access to a database

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO


Database Owner (dbo)

The dbo is a user that has implied permissions to perform all activities in the database. Any member of the sysadmin fixed server role who uses a database is mapped to the special user inside each database called dbo. Also, any object created by any member of the sysadmin fixed server role belongs to dbo automatically.

For example, if user Andrew is a member of the sysadmin fixed server role and creates a table T1, T1 belongs to dbo and is qualified as dbo.T1, not as Andrew.T1. Conversely, if Andrew is not a member of the sysadmin fixed server role but is a member only of the db_owner fixed database role and creates a table T1, T1 belongs to Andrew and is qualified as Andrew.T1. The table belongs to Andrew because he did not qualify the table as dbo.T1.

The dbo user cannot be deleted and is always present in every database.

Only objects created by members of the sysadmin fixed server role (or by the dbo user) belong to dbo. Objects created by any other user who is not also a member of the sysadmin fixed server role (including members of the db_owner fixed database role):

  • Belong to the user creating the object, not dbo.

  • Are qualified with the name of the user who created the object.

See Also

Delimited Identifiers

sp_changedbowner


Database Object Owner

A user who creates a database object (a table, index, view, trigger, function, or stored procedure) is called a database object owner. Permission to create database objects must be given by the database owner or system administrator. However, after these permissions are granted, a database object owner can create an object and grant other users permission to use that object.

Database object owners have no special login IDs or passwords. The creator of a database object is granted all permissions implicitly but must give explicit permissions to other users before they can access the object.

Referencing database objects

When users access an object created by another user, the object should be qualified with the name of the object owner; otherwise, Microsoft® SQL Server™ may not know which object to use because there could be many objects of the same name owned by different users. If an object is not qualified with the object owner when it is referenced (for example, my_table instead of owner.my_table), SQL Server looks for an object in the database in the following order:

  1. Owned by the current user.

  2. Owned by dbo.

If the object is not found, an error is returned.

For example, user John is a member of the db_owner fixed database role, but not the sysadmin fixed server role, and creates table T1. All users, except John, who want to access T1 must qualify T1 with the user name John. If T1 is not qualified with the user name John, SQL Server first looks for a table named T1 owned by the current user and then owned by dbo. If the current user and dbo do not own a table named T1, an error is returned. If the current user or dbo owns another table named T1, the other table named T1, rather than John.T1, is used.

If a database object owner must be removed from a database, the owned objects must be dropped first or their ownership transferred to another user.

Note SQL Server allows a role or Microsoft Windows NT® 4.0 or Windows® 2000 group to be specified as the owner of an object. For example, to create the table group_table owned by the Windows NT 4.0 or Windows 2000 group LONDON\Users, specify [LONDON\Users].group_table as the qualified table name. All members of the LONDON\Users group have database object owner permissions on group_table.

See Also

Delimited Identifiers

sp_changeobjectowner


guest User

New Information - SQL Server 2000 SP3.

The guest user account allows a login without a user account to access a database. A login assumes the identity of the guest user when both of the following conditions are met:

  • The login has access to an instance of Microsoft® SQL Server™ but does not have access to the database through his or her own user account.

  • The database contains a guest user account.

Permissions can be applied to the guest user as if it were any other user account. The guest user can be deleted and added to all databases except master and tempdb, where it must always exist. By default, a guest user account does not exist in newly created databases.

Avoid using the guest account; all logins without their own database permissions obtain the database permissions granted to this account. If you must use the guest account, grant minimum permissions.

For example, to add a guest user account to a database named Accounts, run the following code in SQL Query Analyzer:

USE Accounts
GO
EXECUTE sp_grantdbaccess guest

To grant a SQL Server login access to a database

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO


Creating User-Defined SQL Server Database Roles

Create Microsoft® SQL Server™ database roles when a group of users needs to perform a specified set of activities in SQL Server and one of the following is true:

  • There is no applicable Microsoft Windows NT® 4.0 or Windows® 2000 group.

  • You do not have permissions to manage Windows NT 4.0 or Windows 2000 user accounts.

    Note Avoid deep levels of nested roles because this can affect performance.

For example, a company may form a Charity Event Committee involving employees from different departments and from several different levels in the organization. These employees need access to a special project table in the database. There is no existing Windows NT 4.0 or Windows 2000 group that includes just these employees, and there is no other reason to create one in Windows NT 4.0 or Windows 2000. A custom SQL Server database role, CharityEvent, can be created for this project and individual Windows NT 4.0 and Windows 2000 users added to the database role. When permissions are applied, the users in the database role gain table access. Permissions for other database activities are not affected, and the CharityEvent users are the only ones who can work with the project table.

SQL Server roles exist within a database and cannot span more than one database.

The advantages of using database roles include:

  • For any user, more than one database role can be active at any time.

  • SQL Server roles can contain Windows NT 4.0 or Windows 2000 groups and users and SQL Server users and other roles, provided that all users, groups, and roles exist in the current database.

  • A user can belong to more than one role in the same database.

  • A scalable model is provided for setting up the correct level of security within a database.

    Note A database role is owned by either the user explicitly specified as the owner when the role is created, or the user who created the role when no owner is specified. The owner of the role determines who can be added or removed from the role. However, because a role is not a database object, multiple roles of the same name in the same database owned by different users cannot be created.

To create a SQL Server database role

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

See Also

SQL Server Backward Compatibility Details


Adding a Member to a SQL Server Database Role

When you add a new user account in Microsoft® SQL Server™ or change the permissions of an existing user, you can add the user to a SQL Server database role rather than applying permissions directly to the account. Roles can simplify security administration in databases with a large number of users or with a complex security system.

SQL Server users, Microsoft Windows NT® 4.0 or Windows® 2000 users and groups, and other SQL Server database roles all can be added as a member of a role. Because a role is restricted to a single database and cannot be added from one database to another, you can add users, groups, and roles known only to that database.

Note When you add a Windows NT 4.0 or Windows 2000 login without a user account in the database to a SQL Server database role, SQL Server creates a user account in the database automatically, even if that Windows NT 4.0 or Windows 2000 login cannot otherwise access the database.

A user account can be a member of any number of roles within the same database and can hold permissions appropriate to each role. For example, a SQL Server user can be a member of the admin role and the users role for the same database, with each role granting different permissions. The permission on an object granted to a member of more than one role are the cumulative permissions of the roles. However, a denied permission in one role has precedence over the same permission granted in another role. For example, the admin role may grant access to a table, whereas the users role denies access to the same table. A member of both roles is denied access to the table because denied access is more restrictive and has precedence.

Users to be added to a user-defined database role must already have permission to access the database containing the user-defined role.

To add a member to a SQL Server database role

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO


Adding a Member to a Predefined Role

The security mechanism in Microsoft® SQL Server™ includes several predefined roles with implied permissions that cannot be granted to other user accounts. If you have users who require these permissions, you must add their accounts to these predefined roles. The two types of predefined roles are fixed server and fixed database.

Fixed Server Roles

Fixed server roles, which cannot be created, are defined at the server level and exist outside of individual databases. To add a user to a fixed server role, the user must have a SQL Server or Microsoft Windows NT® 4.0 or Windows® 2000 login account. Any member of a fixed server role can add other logins.

Important Windows NT 4.0 or Windows 2000 users who are members of the BUILTIN\Administrators group are members of the sysadmin fixed server role automatically.

The following table describes the fixed server roles.

Fixed server role | Description
sysadmin | Performs any activity in SQL Server. The permissions of this role span all of the other fixed server roles.
serveradmin | Configures server-wide settings.
setupadmin | Adds and removes linked servers, and executes some system stored procedures, such as sp_serveroption.
securityadmin | Manages server logins.
processadmin | Manages processes running in an instance of SQL Server.
dbcreator | Creates and alters databases.
diskadmin | Manages disk files.
bulkadmin | Executes the BULK INSERT statement.

The securityadmin has permission to execute the sp_password stored procedure for all users other than members of the sysadmin role.

The bulkadmin fixed server role has permission to execute BULK INSERT statements. Members of the bulkadmin role can add other logins to the role, as all members of any given fixed server role can do. However, due to the security implications associated with executing the BULK INSERT statement (the BULK INSERT statement requires read access to any data on the network and machine the server is running on), it may not be desirable for members of the bulkadmin role to grant permission to others. The bulkadmin role provides members of the sysadmin fixed server role with a method to delegate tasks requiring execution of the BULK INSERT statement, without granting users sysadmin rights. Members of the bulkadmin role are allowed to execute the BULK INSERT statement, but they still must have the INSERT permission on the table on which you wish to insert data.

To add a member to a fixed server role

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

Fixed Database Roles

Fixed database roles, which can be created, are defined at the database level and exist in each database. You can add any valid user account (a Windows NT 4.0 or Windows 2000 user or group, or a SQL Server user or role) as a member of a fixed database role. Each member gains the permissions applied to the fixed database role. Any member of a fixed database role can add other users to the role.

The following table describes the fixed database roles.

Fixed database role | Description
db_owner | Performs the activities of all database roles, as well as other maintenance and configuration activities in the database. The permissions of this role span all of the other fixed database roles.
db_accessadmin | Adds or removes Windows NT 4.0 or Windows 2000 groups and users, and SQL Server users in the database.
db_datareader | Sees all data from all user tables in the database.
db_datawriter | Adds, changes, or deletes data from all user tables in the database.
db_ddladmin | Adds, modifies, or drops objects in the database (runs all DDLs).
db_securityadmin | Manages roles and members of SQL Server 2000 database roles, and manages statement and object permissions in the database.
db_backupoperator | Has permission to back up the database.
db_denydatareader | Denies permission to select data in the database.
db_denydatawriter | Denies permission to change data in the database.

To add a member to a SQL Server (fixed) database role

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO


public Role

New Information - SQL Server 2000 SP3.

The public role is a special database role to which every database user belongs. The public role:

  • Captures all default permissions for users in a database.

  • Cannot have users, groups, or roles assigned to it because they belong to the role by default.

  • Is contained in every database, including master, msdb, tempdb, model, and all user databases.

  • Cannot be dropped.

To protect against unauthorized data access, minimize the permissions granted to the public role. Instead, grant permissions to other database roles and to user accounts associated with logins.


Using the Create Login Wizard

New Information - SQL Server 2000 SP3.

Although the steps required to grant login access to Microsoft® SQL Server™ and a database can be performed separately, the Create Login Wizard can simplify the process. The Create Login Wizard allows you to:

  • Choose which authentication mode to use to connect to an instance of SQL Server (Windows Authentication Mode or Mixed Mode).

  • Add a Microsoft Windows NT® 4.0, Windows® 2000 or SQL Server login.

    Security Note When possible, use Windows Authentication.

  • Add a Windows NT 4.0, Windows 2000 or SQL Server login to a fixed server role.

  • Add a Windows NT 4.0, Windows 2000 or SQL Server user to one or more databases, thereby granting the user access to those databases.

To grant SQL Server login access to a user by using the Create Login Wizard

Enterprise Manager


Managing Security Accounts

After security accounts have been added to Microsoft® SQL Server™, you can modify them as business needs change. This usually involves viewing, modifying, and removing the security accounts in the database to fit the needs of your business.


Viewing Logins

New Information - SQL Server 2000 SP3.

View Microsoft® SQL Server™ logins to determine if a user or Microsoft Windows NT® 4.0 or Windows® 2000 group has permission to connect to an instance of SQL Server, and to identify which databases the login can access. Also, view a login before removing it to see which database users must be removed; it is not possible to remove a login without first removing the associated users.

You can view:

  • Users in each database associated with the login.

  • Default database and language the login uses when the user first connects to an instance of SQL Server.

  • Windows NT 4.0 or Windows 2000 security identifier (SID).

    Note It is not possible to view the password of any login unless the password is NULL. Passwords are encrypted when stored in SQL Server.

    Security Note To protect against unauthorized access, do not assign a NULL password to a SQL Server login.

To view a SQL Server login or Windows user or group

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO


Modifying Logins

New Information - SQL Server 2000 SP3.

After a login has been created, it may be necessary to change the password (in the case of SQL Server logins), default database, or default language. For example, a user may forget her password, want to change the password for security reasons, need to use a different database on a regular basis, or need to see messages in a different language.

Note If a user forgets a password, a member of the sysadmin or securityadmin fixed server role can change the password without knowing the original password. A user cannot change a password if he has forgotten it. Members of the securityadmin role cannot change the password of members of the sysadmin role. Passwords for Windows accounts must be changed in Windows by the user or a Windows administrator.

To change the password of a SQL Server login

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To change the default database of a login

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To change the default language of a login

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO


Removing Logins and Users

New Information - SQL Server 2000 SP3.

The process of deactivating security accounts (for example, when an employee leaves a company) is similar to the process of adding a new user. First, the domain administrator should remove the user's Windows NT 4.0 or Windows 2000 account. If the user has Microsoft SQL Server™ database user accounts, remove them from the databases. Finally, remove the login account from SQL Server.

Removing a SQL Server user or Windows NT 4.0 or Windows 2000 user or group from a SQL Server database automatically removes the permissions defined for the user or group and prevents that user from using the database under the old security account. The permissions do not have to be removed separately. However, it is not possible to remove a user from SQL Server if that user currently owns objects (tables, procedures, or views) within a database. If the user owns objects, then either drop those objects before removing the user or transfer ownership to another existing user by using the sp_changeobjectowner system stored procedure.

Removing a user does not remove a login automatically, so it does not prevent the user from connecting to an instance of SQL Server. After being removed, the user can log in to the databases only through the guest account and perform activities under those permissions. To prevent a user from connecting to an instance of SQL Server, remove his or her login.

If a linked server login is set up but is no longer required, remove it to prevent unauthorized access to the linked server and to keep the security system as simple as possible.

To remove a user or group from a database

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To remove a SQL Server login

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To revoke a Windows user or group login access from SQL Server

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To remove a linked server login

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

See Also

sp_changeobjectowner


Denying Login Access to Windows Accounts

When a Microsoft® Windows NT® 4.0 or Windows® 2000 user belongs to a Windows NT 4.0 or Windows 2000 group that has a login account in Microsoft SQL Server™, the user is allowed to connect through the group login. However, there may be times when such users or groups need to be prevented from connecting to an instance of SQL Server. You can deny login access to any Windows NT 4.0 or Windows 2000 user or group. Users cannot connect to an instance of SQL Server if their user account, or any group in which they are a member, has been denied login access.

To deny login access to a Windows user or group

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO


Viewing Roles

When creating and using a database, you may need to find information about a Microsoft® SQL Server™ database role or a fixed server role. For example, you may need to see which roles exist in the current database, or list the fixed server roles.

To view the roles defined in the current database

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To view the fixed database roles defined in the current database

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To view the fixed server roles

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO


Viewing and Modifying Role Memberships

While using a database, you may need to list the members of a database role or fixed server role. Or, when a Microsoft® SQL Server™ user no longer needs the permissions from a user-defined, fixed database or server role of which she is a member, you may want to remove the user from the role to keep the security system as simple as possible.

To view the members of a database role

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To remove a user account from a database role

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To view the members of a fixed server role

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To remove a login from a fixed server role

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO


Removing a SQL Server Database Role

The changing security requirements of a database can render a Microsoft® SQL Server™ database role obsolete. Remove roles when you have removed all users and are certain that the role and its permissions will not be required in the future. Empty roles can be saved if the permissions may be required for a new user. However, from an administrative perspective, it is much easier to work with a security system that is not cluttered with unnecessary security roles. SQL Server operates faster with a simpler security system, although it is will not be a problem unless there are an extremely large number of roles.

Note It is not possible to remove fixed server roles or fixed database roles.

To remove a SQL Server role

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO


Viewing Database Users

New Information - SQL Server 2000 SP3.

Viewing a Microsoft® SQL Server™ user account in a database shows:

  • The roles of which the user is a member.

  • The login account associated with the user.

  • The default database.

Use this information to understand how the user fits into the security system of the database.

To view a database user

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To view the Windows groups that have access to the current database

Transact-SQL

SQL-DMO


Managing Permissions

When users connect to an instance of Microsoft® SQL Server™, the activities they can perform are determined by the permissions granted to:

  • Their security accounts.

  • The Microsoft Windows NT® 4.0 or Windows® 2000 groups or role hierarchies to which their security accounts belong.

The user must have the appropriate permissions to perform any activity that involves changing the database definition or accessing data.

Managing permissions includes granting or revoking user rights to:

  • Work with data and execute procedures (object permissions).

  • Create a database or an item in the database (statement permissions).

  • Utilize permissions granted to predefined roles (implied permissions).
Object Permissions

Working with data or executing a procedure requires a class of permissions known as object permissions:

  • SELECT, INSERT, UPDATE, and DELETE statement permissions, which can be applied to the entire table and view.

  • SELECT and UPDATE statement permissions, which can be selectively applied to individual columns of a table or view.

  • SELECT permissions, which may be applied to user-defined functions.

  • INSERT and DELETE statement permissions, which affect the entire row, and therefore can be applied only to the table and view and not to individual columns.

  • EXECUTE statement permissions, which affect stored procedures and functions.
Statement Permissions

Activities involved in creating a database or an item in a database, such as a table or stored procedure, require a different class of permissions called statement permissions. For example, if a user must be able to create a table within a database, then grant the CREATE TABLE statement permission to the user. Statement permissions, such as CREATE DATABASE, are applied to the statement itself, rather than to a specific object defined in the database.

Statement permissions are:

  • BACKUP DATABASE

  • BACKUP LOG

  • CREATE DATABASE

  • CREATE DEFAULT

  • CREATE FUNCTION

  • CREATE PROCEDURE

  • CREATE RULE

  • CREATE TABLE

  • CREATE VIEW
Implied Permissions

Implied permissions control those activities that can be performed only by members of predefined system roles or owners of database objects. For example, a member of the sysadmin fixed server role inherits automatically full permission to do or see anything in a SQL Server installation.

Database object owners also have implied permissions that allow them to perform all activities with the object they own. For example, a user who owns a table can view, add, or delete data, alter the table definition, or control permissions that allow other users to work with the table.

See Also

BACKUP DATABASE

BACKUP LOG

CREATE DATABASE

CREATE DEFAULT

CREATE FUNCTION

CREATE PROCEDURE

CREATE RULE

CREATE TABLE

CREATE VIEW


Granting Permissions

Grant statement and object permissions that allow a user account to:

  • Perform activities or work with data in the current database.

  • Restrict them from activities or information not part of their intended function.

    For example, you may be inclined to grant SELECT object permission on the payroll table to all members of the personnel role, allowing all members of personnel to view payroll. Months later, you may overhear members of personnel discussing management salaries, information not meant to be seen by all personnel members. In this situation, grant SELECT access to personnel for all columns in payroll except the salary column.

    Note It is possible to grant permissions only to user accounts in the current database, for objects in the current database. If a user needs permissions to objects in another database, create the user account in the other database, or grant the user account access to the other database, as well as the current database. System stored procedures are the exception because EXECUTE permissions are already granted to the public role, which allows everyone to execute them. However, after EXECUTE has been issued, the system stored procedures check the user's role membership. If the user is not a member of the appropriate fixed server or database role necessary to run the stored procedure, the stored procedure will not continue.

To allow access by granting permissions (on an object)

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To grant statement permissions to users within a database

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To grant permissions on multiple objects to a user, group, or role

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To grant, deny, or revoke permissions on multiple objects to a user-defined role

Enterprise Manager


Denying Permissions

Microsoft® SQL Server™ allows Microsoft Windows NT® 4.0 or Windows® 2000 users and groups, SQL Server users, and SQL Server database roles to be members of other roles. This results in a hierarchical security system that allows permissions to be applied through several levels of roles and members. But there may be times when you want to limit the permissions of a user or role. Denying permissions on a user account:

  • Removes permission granted previously to the user, group, or role.

  • Deactivates permission inherited from another role(s).

  • Ensures that a user, group, or role will not inherit permission from a higher level group or role in the future.

For example, you may need to provide all tenured employees in your company with access to several tables in a database, with the exception of a few new employees scattered throughout the organization who you want to prevent from seeing the CorporateSecrets table.

Create a role for each department in the company and add all employees to their department role. Then create a company-wide Corporate role, to which you add each of the individual department roles and grant permissions to view the tables. At this point, every employee in the company can see all the tables because each inherits permission from the Corporate role through his department roles.

To selectively prevent employees from seeing CorporateSecrets, create a Nonsecure role, and add the individual employees who should not see the table. When you deny permission to view CorporateSecrets to Nonsecure, this access is removed from all members of Nonsecure, while the rest of the employees in the company are not affected.

You also can deny permissions to an individual user. In the previous example, a nonemployee may have a Windows NT 4.0 or Windows 2000 account while working on a short-term project in the database. You can deny the permissions to see CorporateSecrets to his individual user account without creating a SQL Server database role for the purpose.

Note You can deny permissions to user accounts only in the current database, for objects in the current database.

To prevent access by denying permissions (on an object)

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To deny statement permissions from users within a database

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To deny permissions on multiple objects to a user, group, or role

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO


Revoking Permissions

You can revoke a permission that has been granted or denied previously. Revoking is similar to denying in that both remove a granted permission at the same level. However, although revoking a permission removes a granted permission, it does not prevent the user, group, or role from inheriting a granted permission from a higher level. Therefore, if you revoke permission for a user to view a table, you do not necessarily prevent the user from viewing the table because permission to view the table was granted to a role to which he belongs.

For example, removing SELECT access on the Employees table from the HumanResources role revokes permission so that HumanResources can no longer use the table. If HumanResources is a member of the Administration role. If you later grant SELECT permission on Employees to Administration, members of HumanResources can see the table through their membership in Administration. However, if you deny permission to HumanResources, the permission is not inherited if later granted to Administration because the deny permission cannot be undone by a permission at a different level.

Similarly, it is also possible to remove a previously denied permission by revoking the deny for the permission. However, if a user has other denied permissions at the group or role level, then the user still is denied access.

Note You can revoke permissions to user accounts only in the current database, for objects in the current database.

To revoke permissions on an object

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To revoke statement permissions from users in a database

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To revoke permissions on multiple objects from a user, group, or role

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO


Resolving Permission Conflicts

The permissions granted to a group or role are inherited by members of that group or role. Although a user may have permission granted or revoked at one level, conflicting permissions at a higher level (for example, due to role membership) can prevent or allow a user access to an object.

Deny

A denied permission always takes precedence. Denied permission at any level (user, group, or role) denies the permission on the object regardless of existing granted or revoked permissions for that user. For example, if user John, who as a member of the sales role is granted SELECT permissions on the customer table, is explicitly denied SELECT permissions on the customer table, he can no longer access it. Similarly, if the sales role is denied access to customer, but John is granted access, he is denied access.

Note Microsoft® SQL Server™ always processes denied permissions first. If you deny permissions to public, you prevent anyone from accessing an object, including the issuer of the DENY statement.

Revoke

A revoked permission removes only the granted or denied permission at the level revoked (user, group, or role). The same permission granted or denied at another level such as a group or role containing the user, group, or role still applies. For example, if the sales role is granted SELECT permissions on the customer table, and John (a member of sales) is explicitly revoked SELECT permissions on the customer table, he still can access the table because of his membership in the sales role. To prevent John from accessing the customer table, do one of the following:

  • Revoke permission (assuming no other permissions have been granted elsewhere).

  • Deny permission to the sales role (preventing all members of sales from accessing the table).

  • Explicitly deny John SELECT permissions on customer.
Grant

A granted permission removes the denied or revoked permission at the level granted (user, group, or role). The same permission denied at another level such as group or role containing the user still applies. However, although the same permission revoked at another level still applies, it does not prevent the user from accessing the object. For example, if John is already explicitly denied access to customer, has his access to sales, revoked, and then is explicitly granted access to customer, he now can access customer because the deny is removed. The revoke permission for sales joined with the granted permission for John gives John a granted permission overall.

Therefore, a user receives the union of all the permissions granted, denied, or revoked on an object, with any denied permissions taking precedence over the same permissions granted or revoked at another level.

The following diagram shows how the three permission management activities affect the state of a permission for a user account.

Database Access vs. Object Access

As an example of a permission conflict, a Microsoft Windows NT® 4.0 user LONDON\joe belongs to the LONDON\clerks and LONDON\secretaries Windows NT 4.0 groups. LONDON\joe can log in to an instance of SQL Server because the LONDON\clerks group has been granted permissions to connect to an instance of SQL Server. Additionally, LONDON\joe can access the secrets database because the LONDON\secretaries group has been granted permissions to access the database.

Note At this point there is no specific entry in the SQL Server system tables, sysusers and sysxlogins, for LONDON\joe. These system tables contain only entries for the LONDON\clerks and LONDON\secretaries groups.

LONDON\joe creates a table, joetable, in the secrets database. At this point, a new entry is created in the sysusers table for LONDON\joe specifying him as the object owner but not granting him database access. If LONDON\joe is dropped from the LONDON\secretaries group, he can no longer access the secrets database, although he owns an object, joetable, in the database.

See Also

Adding a Windows NT User or Group


Permissions for User-Defined Functions

Functions are subroutines made up of one or more Transact-SQL statements that can be used to encapsulate code for reuse. Microsoft® SQL Server™ 2000 allows users to create their own user-defined functions.

User-defined functions are managed through the following statements:

  • CREATE FUNCTION, which creates a user-defined function.

  • ALTER FUNCTION, which modifies user-defined functions.

  • DROP FUNCTION, which drops user-defined functions.

Each fully qualified user-defined function name (database_name.owner_name.function_name) must be unique.

You must have been granted CREATE FUNCTION permissions to create, alter, or drop user-defined functions. Users other than the owner must be granted EXECUTE permission on a function (if the function is scalar-valued) before they can use it in a Transact-SQL statement. If the function is table-valued, the user must have SELECT permissions on the function before referencing it. If a CREATE TABLE or ALTER TABLE statement references a user-defined function in a CHECK constraint, a DEFAULT clause, or a computed column, the table owner must also own the function. If the function is being schema-bound, you must have REFERENCE permission on tables, views, and functions referenced by the function.

REFERENCE permissions can be granted through the GRANT statement to views and user-defined functions in addition to tables.

See Also

User-Defined Functions


Using Ownership Chains

New Information - SQL Server 2000 SP3.

Views, stored procedures, and user-defined functions provide a secondary method of granting permissions to users. They provide users with access to underlying items in the database, possibly without permissions granted on specific objects and statements.

Views can depend on other views or tables. Procedures and user-defined functions can depend on other procedures, functions, views, or tables. These dependencies can be thought of as an ownership chain. Ownership chains apply only to object permissions (SELECT, INSERT, UPDATE, DELETE, and EXECUTE).

Often, the owner of a source object (the view, stored procedure, or user-defined function) also owns all target objects (the objects it depends on). When one user owns the source object and all target objects, the ownership chain is said to be unbroken. If different users own the target objects, the ownership chain is broken. SQL Server relies on the state of the ownership chain to determine when to check permissions.

When an ownership chain is unbroken, SQL Server checks permission on the source object only. This enables a user to grant permissions on views, stored procedures, and user-defined functions instead of on each database object. This can greatly simplify permissions management.

If the ownership chain is broken, SQL Server checks permissions on each branch of the chain owned by a different user. Only those statements where the user has the necessary permissions will be executed, and the remaining statements will get an "Insufficient Permissions" error. In this way, SQL Server allows object owners to retain control over permissions.

Note When temporary objects are created within a stored procedure, they are owned by the procedure owner and not by the user currently executing the procedure.

Examples

If one user owns the source object and all target objects, the user can grant permissions on the source object. For example, Mary has created a view called auview1 that depends on the authors table, which she also owns. If Mary grants Sue permission to use auview1, Sue can see data in the view that is from the authors table, event without permissions on the table.

If a user creates a view or stored procedure that depends on objects owned by another user, SQL Server checks permissions on objects owned by other users. For example, Joe creates a procedure called procedure1, which depends on procedure2 (also owned by Joe), and procedure3 (owned by Sue). These procedures in turn depend on other tables and views owned by Joe and Sue. The following graphic shows the ownership chains.

Joe grants Mary permission to use procedure1. SQL Server checks the permissions on procedure1, procedure3, view2, table2, and table3 to check that Mary is allowed to use them.

Cross-Database Ownership Chaining

Cross-database ownership chaining occurs when a source object depends on objects in other databases.

Cross-database ownership chaining works in the same way as ownership chaining within a database. The only distinction is that an unbroken ownership chain is based on all objects being owned by the same login account, not the same database user name. This is because one login account can have different user names in different databases.

In a cross-database ownership chain, if the source object in the source database and the target objects in the target databases are owned by the same login account, SQL Server does not check permissions on the target objects.

For example, if two databases are owned by the same login account, the dbo users in these databases are mapped to the same login account. If cross-database ownership chaining is enabled for these databases, source objects in the dbo schema can access target objects in the dbo schema of both databases.

Security Considerations for Cross-Database Ownership Chaining

Ownership chaining within a database is a useful application design technique; however, Microsoft does not recommend cross-database ownership chaining because of possible security risks. These risks are due to the actions that highly-privileged users can perform:

  • Database owners and members of the db_ddladmin or db_owners database roles can create objects owned by other users. These objects can potentially target objects in other databases. This means that if you enable cross-database ownership chaining, you must fully trust your highly-privileged users with data in other databases.

  • Users with the CREATE DATABASE permission can create new databases and attach existing databases. If cross-database ownership chaining is enabled, these users can access objects in other databases from newly created or attached databases.

Even though cross-database ownership chaining is not recommended, some applications might require cross-database ownership chaining. Additionally, there are some environments where you can fully trust your highly-privileged users. For this reason, cross-database ownership chaining is configurable.

Configuring Cross-Database Ownership Chaining

Because of the security implications of cross-database ownership chaining, SQL Server 2000 SP3 allows you to turn cross-database ownership chaining on or off for each database. For more information, see Setting Configuration Options.

See Also

Using Views as Security Mechanisms

Using Stored Procedures as Security Mechanisms

sp_configure

sp_dboption


Using Views as Security Mechanisms

Views can serve as security mechanisms by restricting the data available to users. Some data can be accessible to users for query and modification, while the rest of the table or database is invisible and inaccessible. Permission to access the subset of data in a view must be granted, denied, or revoked, regardless of the set of permissions in force on the underlying table(s).

For example, the salary column in a table contains confidential employee information, but the rest of the columns contain information that should be available to all users. You can define a view that includes all of the columns in the table with the exception of the sensitive salary column. As long as table and view have the same owner, granting SELECT permissions on the view allows the user to see nonconfidential columns in the view without having any permissions on the table itself.

By defining different views and granting permissions selectively on them, users, groups, or roles can be restricted to different subsets of data. For example:

  • Access can be restricted to a subset of the rows of a base table. For example, define a view that contains only rows for business and psychology books and keep information about other types of books hidden from users.

  • Access can be restricted to a subset of the columns of a base table. For example, define a view that contains all the rows of the titles table but omits the royalty and advance columns because this information is sensitive.

  • Access can be restricted to a row-and-column subset of a base table.

  • Access can be restricted to the rows that qualify for a join of more than one base table. For example, define a view that joins the titles, authors, and titleauthor tables to display the names of authors and books they have written. This view hides personal data about the authors, and financial information about the books.

  • Access can be restricted to a statistical summary of data in a base table. For example, define a view that contains only the average price of each type of book.

  • Access can be restricted to a subset of another view or of some combination of views and base tables.
Permissions and ALTER VIEW

Use the ALTER VIEW Transact-SQL statement to change the definition of a view without having to drop the view and reapply permissions. Any permissions applied to a column in the view are based on the column name defined in the view, rather than the underlying column in the table. Therefore, changing the definition of the view with ALTER VIEW by using the same column name but a different underlying column in a table results in the same permissions for the new column. This example assumes the user Fred exists in the pubs database:

USE pubs
GO
CREATE VIEW v1 AS SELECT title_id, title FROM titles
GO
GRANT SELECT(title_id) ON v1 TO Fred
GO
ALTER VIEW v1 AS SELECT qty AS 'title_id' FROM sales
GO

Although the view is altered so that the title_id column name refers to the qty column in the sales table, rather than the title_id column in the titles table, the SELECT permissions granted to Fred on the title_id column name still apply.

See Also

ALTER VIEW

CREATE VIEW


Using Stored Procedures as Security Mechanisms

New Information - SQL Server 2000 SP3.

Stored procedures, commonly used as an interface to perform complex activities, can be used to restrict statement permissions.

For example, in an archiving scenario, you may need to copy data older than a specified date into an archive table, and then delete the data from the primary table. If you grant users permission to run the INSERT and DELETE statements, they can perform the required actions and much more. For example, users could delete or incorrectly update data.

Instead of granting broad permissions, you can create a stored procedure that performs the required actions, and then grant users permission to execute the stored procedure. This protects data in the underlying tables from user error.

You also can call stored procedures from external applications, instead of using dynamic SQL embedded in the source code. This provides security benefits such as hiding the database structure from anyone with access to the source code.

See Also

Granting Permissions

CREATE PROCEDURE


Advanced Security Topics

The security topics presented here go beyond the basic use of security in Microsoft® SQL Server™ and provide more detail for specialized applications.


Establishing Application Security and Application Roles

New Information - SQL Server 2000 SP3.

The security system in Microsoft® SQL Server™ is implemented at the lowest level: the database itself. This is the best method for controlling user activities regardless of the application used to communicate with SQL Server. However, sometimes security controls must be customized to accommodate the special requirements of an individual application, especially when dealing with complex databases and databases with large tables.

Additionally, you may want users to be restricted to accessing data only through a specific application (for example using SQL Query Analyzer or Microsoft Excel) or to be prevented from accessing data directly. Restricting user access in this way prohibits users from connecting to an instance of SQL Server using an application such as SQL Query Analyzer and executing a poorly written query, which can negatively affect the performance of the whole server.

SQL Server accommodates these needs through the use of application roles. Application roles are different than standard roles in that:

  • Application roles contain no members.

    Microsoft Windows NT® 4.0 or Windows® 2000 groups, users, and roles cannot be added to application roles; the permissions of the application role are gained when the application role is activated for the user's connection through a specific application or applications. A user's association with an application role is due to his ability to run an application that activates the role, rather than his being a member of the role.

  • Application roles are inactive by default and require a password to be activated.

  • Application roles bypass standard permissions.

    When an application role is activated for a connection by the application, the connection permanently loses all permissions applied to the login, user account, or other groups or database roles in all databases for the duration of the connection. The connection gains the permissions associated with the application role for the database in which the application role exists. Because application roles are applicable only to the database in which they exist, the connection can gain access to another database only through permissions granted to the guest user account in the other database. Therefore, if the guest user account does not exist in a database, the connection cannot gain access to that database. If the guest user account does exist in the database but permissions to access an object are not explicitly granted to guest, the connection cannot access that object, regardless of who created the object. The permissions the user gained from the application role remain in effect until the connection logs out of an instance of SQL Server.

    To ensure that all the functions of the application can be performed, a connection must lose default permissions applied to the login and user account or other groups or database roles in all databases for the duration of the connection and gain the permissions associated with the application role. For example, if a user is usually denied access to a table that the application must access, then the denied access should be revoked so the user can use the application successfully. Application roles overcome any conflicts with user's default permissions by temporarily suspending the user's default permissions and assigning them only the permissions of the application role.

Application roles allow the application, rather than SQL Server, to take over the responsibility of user authentication. However, because SQL Server still must authenticate the application when it accesses databases, the application must provide a password because there is no other way to authenticate an application.

If ad hoc access to a database is not required, users and Windows NT 4.0 or Windows 2000 groups do not need to be granted any permissions because all permissions can be assigned by the applications they use to access the database. In such an environment, standardizing on one system-wide password assigned to an application role is possible, assuming access to the applications is secure.

Security Note When using application roles, you cannot audit individual user activity. You can audit only the activity of the application role.

There are several options for managing application-role passwords other than hard coding them into applications (which is not recommended). For example, an encrypted key stored in the registry (or a SQL Server database), for which only the application has the decryption code, can be used. The application reads the key, decrypts it, and uses the value to set the application role. Using the Multiprotocol Net-Library, the network packet containing the password can also be encrypted. Additionally, the password can be encrypted, before being sent to an instance of SQL Server, when the role is activated.

When an application user connects to an instance of SQL Server using Windows Authentication Mode, an application role can be used to set the permissions the Windows NT 4.0 or Windows 2000 user has in a database when using the application. This method allows Windows NT 4.0 or Windows 2000 auditing of the user account and control over user permissions, while she uses the application, to be easily maintained.

If SQL Server Authentication is used and auditing user access in the database is not required, it can be easier for the application to connect to an instance of SQL Server using a predefined SQL Server login. For example, an order entry application authenticates users running the application itself, and then connects to an instance of SQL Server using the same OrderEntry login. All connections use the same login, and relevant permissions are granted to this login.

Security Note Application roles work with both authentication modes. When possible, use Windows Authentication.

Example

As an example of application role usage, a user Sue runs a sales application that requires SELECT, UPDATE, and INSERT permissions on the Products and Orders tables in database Sales to work, but she should not have any SELECT, INSERT, or UPDATE permissions when accessing the Products or Orders tables using SQL Query Analyzer or any other tool. To ensure this, create one user-database role that denies SELECT, INSERT, or UPDATE permissions on the Products and Orders tables, and add Sue as a member of that database role. Then create an application role in the Sales database with SELECT, INSERT, and UPDATE permissions on the Products and Orders tables. When the application runs, it provides the password to activate the application role by using sp_setapprole, and gains the permissions to access the Products and Orders tables. If Sue tries to log in to an instance of SQL Server using any tool except the application, she will not be able to access the Products or Orders tables.

To create an application role

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO

To set an application role

Transact-SQL

To change the password of an application role

Transact-SQL

SQL-DMO

To remove an application role

Transact-SQL

Enterprise Manager

Enterprise Manager

SQL-DMO


Allowing Other Accounts to Grant Object Permissions

When you grant an object permission to a user account in a database, you can optionally specify the WITH GRANT OPTION clause, which allows the user account to grant that object permission to others. A user account can be a Microsoft® Windows NT® 4.0 or Windows® 2000 user or group or a Microsoft SQL Server™ user or role.

For example, if you use the WITH GRANT OPTION clause when you grant permissions on the salaries table to the user user_a, user_a is able to grant the same permissions on the table to any other user account in the database. For groups and roles, if you grant permissions on the salaries table to role role_a specifying the WITH GRANT OPTION clause, each member of role_a can grant the object permission to any other user account, provided that the AS clause of the GRANT statement is specified. For more information, see GRANT.

Important When you use the WITH GRANT OPTION clause, you have no future control over which security accounts will receive that permission.

When you revoke a permission granted using the WITH GRANT OPTION clause, specify the CASCADE clause to have the permissions revoked from the user account as well as any other accounts that received the permission from the initial account.

For example, you have granted a permission specifying WITH GRANT OPTION to the user user_a. User_a granted the permission specifying WITH GRANT OPTION to the user user_b, and user_b granted the permission to the user user_c. User_a has left the company, but SQL Server does not allow you to remove a user account if it has granted a permission specifying the WITH GRANT OPTION clause to another account. Specifying the WITH GRANT OPTION clause has created a chain from user_a through user_b to user_c. You cannot remove the account for user_a until the permissions are revoked for user_b and user_c. When you revoke the permission from user_a and specify the CASCADE option, the permission is removed from the user_a, user_b, and user_c accounts. You then may remove the user_a account.


Creating SQL Server File Permissions

Microsoft® SQL Server™ must create and access files in order to store databases, database backups, error logs, and so on. This SQL Server process must run in the context of a security account with the necessary permissions to create and access these files, whether these files exist on the local computer or a network drive on a remote computer. The security account SQL Server uses depends on the method used to start the instance of SQL Server. If an instance of SQL Server is started:

  • As a service on Microsoft Windows NT® 4.0 or Windows® 2000 using the Service Control Manager, SQL Server uses the security account assigned to the SQL Server service.

  • At the command prompt, independent of the Service Control Manager, SQL Server uses the security account of the logged on user.

  • In Microsoft Windows 98 and Microsoft Windows Millennium Edition, SQL Server uses the security account of the logged on user.

The security account used by SQL Server requires full access permissions to the file system to create, read, write, delete, and execute files. For example, using the NTFS file system, the security account used by SQL Server requires authority to create files with NTFS Full Control permission.

To prevent unauthorized access to the files used by SQL Server, adjust the permissions on the files directly to allow only the security account used by SQL Server access to the files.

Note If SQL Server uses the Windows NT 4.0 and Windows 2000 LocalSystem built-in security account, file permissions must be granted to the SYSTEM account of the local computer running an instance of SQL Server.

Securing the Windows NT Registry

SQL Server Setup removes write permissions from the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Providers key in the Windows 2000 registry for users who are not SQL Server system administrators. This prevents nonadministrator users from setting the provider options for linked server definitions when using SQL Server Enterprise Manager.

See Also

Setting up Windows Services Accounts

Starting SQL Server


Using Encryption Methods

New Information - SQL Server 2000 SP3.

Encryption is a method for keeping sensitive information confidential by changing data into an unreadable form. Encryption ensures that data remains secure by keeping the information hidden from everyone, even if the encrypted data is viewed directly. Decryption is the process of changing encrypted data back into its original form so it can be viewed by authorized users.

Microsoft® SQL Server™ encrypts or can encrypt:

  • Login and application role passwords stored in SQL Server.

  • Any data sent between the client and the server as network packets.

  • Stored procedure definitions.

  • User-defined function definitions.

  • View definitions.

  • Trigger definitions.

  • Default definitions.

  • Rule definitions.

    Note If you are running Microsoft Windows® 2000 and want to use the Windows 2000 Encrypted File System to encrypt any SQL Server files, you must unencrypt the files before you can change the SQL Server service accounts. If you do not unencrypt the files and then reset the SQL Server service accounts, you cannot unencrypt the files.

Login and Application Role Passwords

Login and application role passwords stored in the SQL Server system tables are always encrypted. This prevents users, including system administrators, from viewing any passwords, including their own. Additionally, application role passwords can be encrypted when the application role is activated before they are sent over the network.

Note Using the sp_addlogin system stored procedure, SQL Server logins can be added without encrypting the password, if required. However, this is not recommended unless the passwords are already encrypted because they are being imported from another instance of SQL Server.

Data in Network Packets

SQL Server allows data sent between the client and the server to be encrypted. This ensures that any application or user intercepting the data packets on the network cannot view confidential or sensitive data (for example, passwords sent across the network as a user logs into an instance of SQL Server). SQL Server can use the Secure Sockets Layer (SSL) to encrypt all data transmitted between an application computer and an instance of SQL Server. The SSL encryption is performed within the Super Socket Net-Library (Dbnetlib.dll and Ssnetlib.dll) and applies to all inter-computer protocols supported by SQL Server 2000. Enabling encryption marginally slows the performance of the Net-Libraries because encryption requires the following additional actions:

  • An extra network round trip is required at connect time.

  • All packets sent from the application to the instance of SQL Server must be encrypted by the client Net-Library and decrypted by the server Net-Library.

  • All packets sent from the instance of SQL Server to the application must be encrypted by the server Net-Library and decrypted by the client Net-Library.

Shared memory Net-Library communications are inherently secure without the need for encryption. The shared memory Net-Library does not participates in inter-computer communications. The area of memory shared between the application process and the database engine process cannot be accessed from any other Windows process.

For compatibility with earlier versions of SQL Server, the Multiprotocol Net-Library continues to support its own encryption. This encryption is specified independently of the SSL encryption and is implemented by calling the Windows RPC encryption API. It does not require the use of certificates. The level of RPC encryption, 40-bit or 128-bit, depends on the version of the Windows operating system that is running on the application and database computers. The Multiprotocol Net-Library is not supported by named instances. For more information about SSL, see Net-Library Encryption.

Configuring a Multiprotocol Alias

When you configure a multiprotocol alias, enable encryption. This encryption feature applies only to the Multiprotocol Net-Library. This encryption feature is offered only for compatibility with existing applications. SQL Server clients should use the SSL encryption specified on the General tab in the Enable protocol encryption check box of the Client Network Utility. For more information on the Client Network Utility, see Configuring Client Net-Libraries.

To start the Client Network Utility

Client Network Utility

Client Network Utility

To configure a client to use the Multiprotocol Net-Library

Client Utility

Client Utility

Stored Procedure, Function, View, and Trigger Definitions

When the definition of a stored procedure, function, trigger, or view is saved in the syscomments system table, it can be encrypted (for example, if a SQL Server system contains proprietary stored procedures, functions, triggers, or views whose definitions should not be viewed by users and third parties).

See Also

Client and Server Net-Libraries

CREATE DEFAULT

CREATE FUNCTION

CREATE PROCEDURE

CREATE RULE

CREATE TRIGGER

CREATE VIEW

Multiprotocol Clients

Net-Library Encryption

sp_addlogin

sp_addrole

sp_approlepassword

sp_setapprole


Revealing SQL Server on a Network

When you install Microsoft® SQL Server™, SQL Server Setup makes an entry in the Microsoft Windows® 2000 registry that enables Named Pipes clients to see SQL Server in a server enumeration box in SQL Query Analyzer. SQL Server automatically announces itself as a service over Named Pipes to make it easier to locate servers running an instance of SQL Server. However, if you are using Active Directory™, the directory service included in Windows 2000, this functionality is no longer necessary.

Stop SQL Server from announcing itself over Named Pipes by running the NET CONFIG SERVER command with the switch as /HIDDEN:YES. You can reveal the server at any time.

To reveal or cancel the announcement of SQL Server on a network

Windows NT


Scripting Data Access Controls in Internet Explorer

New Information - SQL Server 2000 SP3.

Microsoft® SQL Server™ ships with several data access controls:

  • SQL Namespace (SQL-NS)

  • SQL Distribution control (replication)

  • SQL Merge control (replication)

These controls are signed and marked "safe for initialization and scripting" and can be used in Microsoft Internet Explorer 5 or later.

Before deploying controls that can connect to data sources, you should thoroughly understand the security implications. When you use any of the SQL Server controls, the primary security concern is the ability to run under the authorized user's account through a Windows Authentication login to an instance of SQL Server. A Web page with a scripted control runs with the network identity of the user browsing the page. If the data source connection is based on the connected user's network identity (using Windows Authentication login), the control can access any data that the user browsing the page can access. If a Web page using the control is sent to a user, the control has the permissions of the user browsing the Web page. The control can then perform, without the user's knowledge, any actions the user has permission to perform in the database. This is one reason why it is important to limit database and server permissions as much as possible.

To help prevent unauthorized access or changes to a database, all the data access controls that are marked as "safe for scripting" take into account security zones settings when being loaded in Internet Explorer version 4.0 or later. If a control is not marked safe for scripting, it can run a script inside of Internet Explorer only at the Low security mode of Internet Explorer, and even then only after the user responded to a message stating that a script will be run.

Internet Explorer 4.0 does not provide an explicit security option for data access. Therefore, all the controls marked safe for scripting allow, prompt, or disallow scripting based on the security zone being used. The following table shows the Internet Explorer 4.0 settings.

Security zone | Internet Explorer 4.0 notification
Local computer zone | Controls can be initialized or scripted regardless of data source or scripts.
Local intranet zone | User is warned of potential safety violation prior to loading the page. User can accept or reject initialization or scripting.
Trusted sites zone | Controls can be initialized or scripted regardless of data source or scripts.
Internet zone | User is warned of potential safety violation prior to loading the page. User can accept or reject initialization or scripting.
Restricted sites zone | Scripting errors occur if user attempts to view page and execute script.

In contrast to Internet Explorer 4.0, Internet Explorer 5 supports an explicit security option for data access called "Access data sources across domains." This option can be customized, and the setting of this action is used to determine how the controls behave when they are run in Internet Explorer 5. The default settings in Internet Explorer 5 are the same as the programmed settings in Internet Explorer 4.0.

As with all security concerns, you must take specific actions to safeguard your system. SQL Server is protected from security problems only if users with the ability to use Windows Authentication logins configure the security settings correctly, and answer all security prompts correctly, and if the administrator properly limits the permissions of all users. When you grant database permissions, you should never grant permissions that you do not want users to have. Properly granting permissions will mitigate most security concerns.

Security Note These general steps to safeguard your system apply to any scripting host, including Microsoft Excel spreadsheets or Microsoft Word documents. Users should always enable the macro warning feature or similar security setting of an application to detect and prevent any attacks on data.

See Also

Developing SQL-DMO Applications

Programming SQL-NS Applications


Auditing SQL Server Activity

Microsoft® SQL Server™ 2000 provides auditing as a way to trace and record activity that has happened on each instance of SQL Server (for example, successful and failed logins). SQL Server 2000 also provides an interface, SQL Profiler, for managing audit records. Auditing can only be enabled or modified by members of the sysadmin fixed security role, and every modification of an audit is an auditable event.

There are two type of auditing:

  • Auditing, which provides some level of auditing but does not require the same number of policies as C2 auditing.

  • C2 auditing, which requires that you follow very specific security policies. For more information about C2 auditing, see C2 Auditing.

Both types of auditing can be done by using SQL Profiler.

Using SQL Profiler

SQL Profiler provides the user interface for auditing events. There are several categories of events that can be audited using SQL Profiler, such as:

  • End user activity (all SQL commands, logout/login, enabling of application roles).

  • DBA activity (DDL, other than grant/revoke/deny and security events, Configuration (DB or server).

  • Security events (grant/revoke/deny, login user/role add/remove/configure).

  • Utility events (backup/restore/bulk insert/BCP/DBCC commands.

  • Server events (shutdown, pause, start).

  • Audit events (add audit, modify audit, stop audit).

For more information about what categories of events can be monitored, see Security Audit Event Category.

It is possible to audit the following aspects of SQL Server through SQL Profiler:

  • Date and time of event.

  • User who caused the event to occur.

  • Type of event.

  • Success or failure of the event.

  • The origin of the request (for example, the Microsoft Windows NT® 4.0 computer name).

  • The name of the object accessed.

  • Text of the SQL statement (passwords replaced with ****).

  • If you are a member of the sysadmin or securityadmin fixed server role and you reset your own password by using sp_password with all three arguments specified ('old_password', 'new_password', 'login'), the audit record will reflect that you are changing someone else's password.

Auditing can have a significant performance impact. If all audit counters are turned on for all objects, the performance impact could be high. It is necessary to evaluate how many events need to be audited compared to the resulting performance impact. Audit trail analysis can be costly, so it is recommended that audit activity be run on a server separate from the production server.

Note If SQL Server is started with the -f flag, auditing will not run.

See Also

Monitoring with SQL Profiler


Using Audit Logs

SQL Profiler system stored procedures support file rollover. The maximum file size for the audit log is fixed at 200 megabytes (MB). When the audit log file reaches 200 MB, a new file will be created and the old file handle will be closed. If the directory fills up (for example, if the disk quota for the user of the service account has filled up or the disk is full), then the instance of Microsoft® SQL Server™ is stopped. The system administrator needs to either free up disk space for the audit log before restarting the instance of SQL Server or restart the instance of SQL Server (if auditing is not configured to start automatically).

Use file rollover to prevent the audit trace from failing because the audit log filled up. However, SQL Server will not shut down unless the user specifically requested this feature when they created the trace. An audit failure produces an entry in the Microsoft Windows® event log and the SQL Server error log.

It is strongly recommended that during SQL Server Setup you create a new directory to contain your audit files. \mssql\audit is the suggested path. If you are running SQL Server on a named instance, the suggested path is MSSQL$Instance\audit.


C2 Auditing

C2 auditing is necessary if you are running a C2 certified system. A C2 certified system meets a government standard that defines the security level. To have a C2 certified Microsoft® SQL Server™, you must configure SQL Server in the evaluated C2 configuration. For more information about C2 certification, see the C2 Administrator's and User's Security Guide.


Managing Security

To ensure that data and objects stored in Microsoft® SQL Server™ are accessed only by authorized users, security must be set up correctly. Security elements that may have to be set up include authentication modes, logins, users, roles, granting, revoking, and denying permissions on Transact-SQL statements and objects, and data encryption.


How to set up Windows Authentication Mode security (Enterprise Manager)

New Information - SQL Server 2000 SP3.

To set up Windows Authentication Mode security

  1. Expand a server group.

  2. Right-click a server, and then click Properties.

  3. On the Security tab, under Authentication, click Windows only.

  4. Under Audit level, select the level at which user accesses to Microsoft® SQL Server™ are recorded in the SQL Server error log:
    • None causes no auditing to be performed.

    • Success causes only successful login attempts to be audited.

    • Failure causes only failed login attempts to be audited.

    • All causes successful and failed login attempts to be audited.

    Security Note Microsoft recommends auditing, at minimum, failed login attempts. Auditing failed login attempts helps determine if unauthorized users are attempting to access the system.

See Also

Authentication Modes


How to set up Mixed Mode security (Enterprise Manager)

New Information - SQL Server 2000 SP3.

Security Note When possible, use Windows Authentication.

To set up Mixed Mode security

  1. Expand a server group.

  2. Right-click a server, and then click Properties.

  3. Click the Security tab.

  4. Under Authentication, click SQL Server and Windows.

  5. Under Audit level, select the level at which user accesses to Microsoft® SQL Server™ are recorded in the SQL Server error log:
    • None causes no auditing to be performed.

    • Success causes only successful login attempts to be audited.

    • Failure causes only failed login attempts to be audited.

    • All causes successful and failed login attempts to be audited.

    Security Note Microsoft recommends auditing, at minimum, failed login attempts. Auditing failed login attempts helps determine if unauthorized users are attempting to access the system.

See Also

Authentication Modes


How to grant a Windows user or group login access to SQL Server (Enterprise Manager)

To grant a Windows NT 4.0 or Window 2000 user or group login access to SQL Server

  1. Expand a server group, and then expand a server.

  2. Expand Security, right-click Logins, and then click New Login.

  3. In the Name box, enter the Microsoft® Windows NT® 4.0 or Windows® 2000 account (in the form DOMAIN\User) to be granted access to Microsoft SQL Server™.

  4. Under Authentication, click Windows Authentication.

  5. Optionally:
    • In Database, click the default database to which the user is connected after logging into an instance of SQL Server.

    • In Language, click the default language in which messages are displayed to the user.

See Also

Adding a Windows NT User or Group


How to grant a Windows user or group access to a database (Enterprise Manager)

To grant a Windows NT 4.0 or Windows 2000 user or group access to a database

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database to which the user or group will be granted access.

  3. Right-click Users, and then click New Database User.

  4. In the Login name box, type or select the Microsoft® Windows NT® 4.0 or Windows® 2000 user or group name to which database access will be granted.

  5. Optionally, in User name, enter the user name that the login is known by in the database. By default, it is set to the login name.

  6. Optionally, select database role memberships to be granted to the user or group in addition to public, the default.

See Also

Granting a Windows NT User or Group Access to a Database


How to add a SQL Server login (Enterprise Manager)

New Information - SQL Server 2000 SP3.

Security Note When possible, use Windows Authentication.

To add a SQL Server login

  1. Expand a server group, and then expand a server.

  2. Expand Security, right-click Logins, and then click New Login.

  3. In Name, enter a name for the Microsoft® SQL Server™ login.

  4. Under Authentication, select SQL Server Authentication.

  5. Optionally, in Password, enter a password.

  6. Optionally:
    • In Database, click the default database to which the login is connected after logging into an instance of SQL Server.

    • In Language, click the default language in which messages are displayed to the user.

See Also

Adding a SQL Server Login


How to add a linked server login (Enterprise Manager)

To add a linked server login

  1. Expand a server group, and then expand a server.

  2. Expand Security, and then click Linked Servers.

  3. In the details pane, right-click the linked server to which the login will be added, and then click Properties.

  4. On the Security tab, click the local login to add.

  5. Optionally, select the Impersonate check box if the local login should connect to the linked server using its own user security credentials.

  6. Enter the remote user and remote password with which the local login should connect to the linked server when not using the user's security credentials (Impersonate not selected).

See Also

Establishing Security for Linked Servers

How to set up a linked server (Enterprise Manager)


How to grant a SQL Server login access to a database (Enterprise Manager)

To grant a SQL Server login access to a database

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database to which the login will be granted access.

  3. Right-click Users, and then click New Database User.

  4. In the Login name box, click the Microsoft® SQL Server™ login to which database access will be granted.

  5. Optionally, in User name, enter the user name that the login is known by in the database. By default, it is set to the login name.

  6. Optionally, select database role memberships in addition to public, the default.

See Also

Granting a SQL Server Login Access to a Database

guest User


How to create a SQL Server database role (Enterprise Manager)

To create a SQL Server database role

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database in which to create a role.

  3. Right-click Roles, and then click New Database Role.

  4. In the Name box, enter the name of the new role.

  5. Optionally, click Add to add members to the Standard role list, and then click a user or users to add.

    Only users in the selected database can be added to the role.

See Also

Creating User-Defined SQL Server Database Roles


How to add a member to a SQL Server database role (Enterprise Manager)

To add a member to a SQL Server database role

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database in which the role exists.

  3. Click Roles.

  4. In the details pane, right-click the role to which the user will be added, and then click Properties.

  5. Click Add, and then click a user or users to add.

    Only users in the selected database can be added to the role.

See Also

Adding a Member to a Predefined Role

Adding a Member to a SQL Server Database Role


How to add a member to a fixed server role (Enterprise Manager)

To add a member to a fixed server role

  1. Expand a server group, and then expand a server.

  2. Expand Security, and then click Server Roles.

  3. In the details pane, right-click the role, and then click Properties.

  4. On the General tab, click Add, and then click the logins to add.

See Also

Adding a Member to a Predefined Role


How to grant SQL Server login access to a user by using the Create Login Wizard (Enterprise Manager)

To grant SQL Server login access to a user by using the Create SQL Server Login Wizard

  1. On the Tools menu, click Wizards.

  2. In the Select Wizard dialog box, expand Database, and then double-click Create Login Wizard.

  3. Complete the steps in the wizard.

See Also

Using the Create Login Wizard


How to view a SQL Server login or Windows user or group (Enterprise Manager)

To view a SQL Server login or Windows NT 4.0 or Windows 2000 user or group

  1. Expand a server group, and then expand a server.

  2. Expand Security, and then click Logins.

  3. In the details pane, right-click the login to view, and then click Properties.

See Also

Viewing Logins


How to view a database user (Enterprise Manager)

To view a database user

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database to which the user belongs.

  3. Click Users.

  4. In the details pane, right-click the user to view, and then click Properties.

See Also

Viewing Database Users


How to change the password of a SQL Server login (Enterprise Manager)

To change the password of a SQL Server login

  1. Expand a server group, and then expand a server.

  2. Expand Security, and then click Logins.

  3. In the details pane, right-click the login to modify, and then click Properties.

  4. In the Password box, on the General tab, enter a new password.

  5. Confirm the password.

See Also

Modifying Logins


How to change the default database of a login (Enterprise Manager)

To change the default database of a login

  1. Expand a server group, and then expand a server.

  2. Expand Security, and then click Logins.

  3. In the details pane, right-click the login to modify, and then click Properties.

  4. In the Database list, on the General tab, click the new default database to which the login is connected after logging into an instance of Microsoft® SQL Server™.

See Also

Modifying Logins


How to change the default language of a login (Enterprise Manager)

To change the default language of a login

  1. Expand a server group, and then expand a server.

  2. Expand Security, and then click Logins.

  3. In the details pane, right-click the login to modify, and then click Properties.

  4. In the Language list, on the General tab, click the new default language in which messages are to be displayed to the user.

See Also

Modifying Logins


How to remove a user or group from a database (Enterprise Manager)

To remove a user or group from a database

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database to which the user or group belongs.

  3. Click Users.

  4. In the details pane, right-click the user or group to remove, and then click Delete.

  5. Confirm the deletion.

See Also

Removing Logins and Users


How to remove a SQL Server login (Enterprise Manager)

To remove a SQL Server login

  1. Expand a server group, and then expand a server.

  2. Expand Security, and then click Logins.

  3. In the details pane, right-click the login to remove, and then click Delete.

  4. Confirm the deletion.

See Also

Removing Logins and Users


How to revoke a Windows user or group login access from SQL Server (Enterprise Manager)

To revoke a Windows NT 4.0 or Windows 2000 user or group login access from SQL Server

  1. Expand a server group, and then expand a server.

  2. Expand Security, and then click Logins.

  3. In the details pane, right-click the Microsoft® Windows NT® 4.0 or Windows® 2000 user or group to revoke, and then click Delete.

  4. Confirm the deletion.

See Also

Removing Logins and Users


How to deny login access to a Windows user or group (Enterprise Manager)

To deny login access to a Windows NT 4.0 or Windows 2000 user or group

  1. Expand a server group, and then expand a server.

  2. Expand Security, and then click Logins.

  3. In the details pane, right-click the Microsoft® Windows NT® 4.0 or Windows® 2000 user or group to deny, and then click Properties.

  4. Under Authentication, click Deny access.

See Also

Denying Login Access to Windows NT Accounts

How to grant a Windows NT user or group login access to SQL Server (Enterprise Manager)


How to remove a linked server login (Enterprise Manager)

To remove a linked server login

  1. Expand a server group, and then expand a server.

  2. Expand Security, and then click Linked Servers.

  3. In the details pane, right-click the linked server to which the linked server login to be removed is mapped, and then click Properties.

  4. On the Security tab, under Local login, click the linked server login to remove, and then select the blank login at the top of the list.

See Also

Removing Logins and Users


How to view the roles defined in the current database (Enterprise Manager)

To view the roles defined in the current database

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database to view.

  3. Click Roles.

See Also

Viewing Roles


How to view the fixed server roles (Enterprise Manager)

To view the fixed server roles

  1. Expand a server group, and then expand a server.

  2. Expand Security, and then click Server Roles.

See Also

Viewing Roles


How to view the members of a database role (Enterprise Manager)

To view the members of a database role

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database to which the user belongs.

  3. Click Roles.

  4. In the details pane, right-click the role to view, and then click Properties to view members.

See Also

Viewing and Modifying Role Memberships


How to remove a user account from a database role (Enterprise Manager)

To remove a user account from a database role

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database in which the role exists.

  3. Click Roles.

  4. In the details pane, right-click the role to which the user account belongs, and then click Properties.

  5. Select the user to remove, and then click Remove.

See Also

Viewing and Modifying Role Memberships


How to view the members of a fixed server role (Enterprise Manager)

To view the members of a fixed server role

  1. Expand a server group, and then expand a server.

  2. Expand Security, and then click Server Roles.

  3. In the details pane, right-click the server role to view, and then click Properties.

See Also

Viewing and Modifying Role Memberships


How to remove a login from a fixed server role (Enterprise Manager)

To remove a login from a fixed server role

  1. Expand a server group, and then expand a server.

  2. Expand Security, and then click Server Roles.

  3. In the details pane, right-click the server role to modify, and then click Properties.

  4. On the General tab, select the login to remove, and then click Remove.

See Also

Viewing and Modifying Role Memberships


How to remove a SQL Server role (Enterprise Manager)

To remove a SQL Server role

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database in which the role exists.

  3. Click Roles.

  4. In the details pane, right-click the role, and then click Delete.

    Note You must drop all role members before you can delete the role. Fixed roles cannot be deleted.

  5. Confirm the deletion.

See Also

Removing a SQL Server Database Role


How to allow access by granting permissions (Enterprise Manager)

To allow access by granting permissions (on an object)

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database to which the object belongs.

  3. Depending on the type of object, click one of the following:
    • Tables

    • Views

    • Stored Procedures
  4. In the details pane, right-click the object on which to grant permissions, point to All Tasks, and then click Manage Permissions.

  5. Click List all users/user-defined database roles/public, and then select the permission to grant each user.

    A check indicates a granted permission. Only permissions applicable to the object are listed.

See Also

Granting Permissions


How to grant statement permissions to users within a database (Enterprise Manager)

To grant statement permissions to users within a database

  1. Expand a server group, and then expand a server.

  2. Expand Databases, right-click the database containing the users to whom statement permissions will be granted, and then click Properties.

  3. On the Permissions tab, select the statement permission to grant each user.

    A check indicates a granted permission.

See Also

Granting Permissions


How to grant permissions on multiple objects to a user, group, or role (Enterprise Manager)

To grant permissions on multiple objects to a user, group, or role

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database to which the user, group, or role belongs.

  3. Depending on the type of user, group, or role to which permissions will be granted, click either Users or Roles.

  4. In the details pane, right-click the user, group, or role to which permissions will be granted, point to All Tasks, and then click Manage Permissions.

  5. Click List all objects, and then select the permission to grant each object.

    A check indicates a granted permission. Only permissions applicable to the object are listed.

See Also

Granting Permissions


How to prevent access by denying permissions (Enterprise Manager)

To prevent access by denying permissions (on an object)

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database to which the object belongs.

  3. Depending on the type of object to which access will be denied, click one of the following:
    • Tables

    • Views

    • Stored Procedures
  4. In the details pane, right-click the object to which access will be denied, point to All Tasks, and then click Manage Permissions.

  5. Click List all users/user-defined database roles/public, and then select the permission to deny each user.

    An 'X' indicates a denied permission. Only permissions applicable to the object are listed.

See Also

Denying Permissions


How to deny statement permissions from users within a database (Enterprise Manager)

To deny statement permissions from users within a database

  1. Expand a server group, and then expand a server.

  2. Expand Databases, right-click the database containing the users to whom statement permissions will be denied, and then click Properties.

  3. On the Permissions tab, select the statement permission to deny each user.

    An 'X' indicates a denied permission.

See Also

Denying Permissions


How to deny permissions on multiple objects to a user, group, or role (Enterprise Manager)

To deny permissions on multiple objects to a user, group, or role

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database to which the user, group, or role belongs.

  3. Depending on the type of user, group, or role to which permissions will be denied, click either Users or Roles.

  4. In the details pane, right-click the user or group to which permissions will be denied, point to All Tasks, and then click Manage Permissions. If you are denying permission to a role, right-click the role to which permissions will be denied, click Properties, and then click Permissions.

  5. Click List all objects, and then select the permission to deny for each object.

    An 'X' indicates a denied permission. Only permissions applicable to the object are listed.

See Also

Denying Permissions


How to revoke permissions on an object (Enterprise Manager)

To revoke permissions on an object

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database to which the object belongs.

  3. Depending on the type of object to which access will be revoked, click one of the following:
    • Tables

    • Views

    • Stored Procedures
  4. In the details pane, right-click the object to which access will be revoked, point to All Tasks, and then click Manage Permissions.

  5. Click List all users/user-defined database roles/public, and then select the permission to revoke from each user.

    An empty box indicates a revoked permission. Only permissions applicable to the object are listed.

See Also

Revoking Permissions


How to revoke statement permissions from users in a database (Enterprise Manager)

To revoke statement permissions from users in a database

  1. Expand a server group, and then expand a server.

  2. Expand Databases, right-click the database containing the users from whom statement permissions will be revoked, and then click Properties.

  3. On the Permissions tab, select the statement permission to revoke from each user.

    An empty box indicates a revoked permission.

See Also

Revoking Permissions


How to revoke permissions on multiple objects from a user, group, or role (Enterprise Manager)

To revoke permissions on multiple objects from a user, group, or role

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database to which the user, group, or role belongs.

  3. Depending on the type of user, group, or role from which permissions will be revoked, click either Users or Roles.

  4. In the details pane, right-click the user or group from which permissions will be revoked, point to All Tasks, and then click Manage Permissions. If you are revoking permission from a role, right-click the role to which permissions will be denied, click Properties, and then click Permissions.

  5. Click List all objects, and then select the permission to revoke for each object.

    An empty box indicates a revoked permission. Only permissions applicable to the object are listed.

See Also

Revoking Permissions


How to create an application role (Enterprise Manager)

To create an application role

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database in which to create a role.

  3. Right-click Roles, and then click New Database Role.

  4. In the Name box, enter the name of the new application role.

  5. Under Database role type, click Application role, and then enter a password.

See Also

Establishing Application Security and Application Roles


How to remove an application role (Enterprise Manager)

To remove an application role

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database in which the application role exists.

  3. Click Roles.

  4. In the details pane, right-click the application role to remove, and then click Delete.

  5. Confirm the deletion.

See Also

Establishing Application Security and Application Roles


How to reveal or cancel announcement of SQL Server on a network (Windows)

To reveal or cancel announcement of SQL Server on a network

  1. In Control Panel, double-click Network.

  2. Click the Services tab.

  3. In the Network Services list, click Server, and then click Properties.

  4. Select Make Browser Broadcasts to LAN Manager 2.x Clients to reveal the server, or clear the check box to hide the server.

See Also

Revealing SQL Server on a Network


How to grant, deny, or revoke permissions on multiple objects to a user-defined role (Enterprise Manager)

To grant, deny, or revoke permissions on multiple objects to a user-defined role

  1. Expand a server group, and then expand a server.

  2. Expand Databases, and then expand the database to which the role belongs.

  3. Click Roles.

  4. In the details pane, right-click the user-defined role to which permissions will be granted, denied, or revoked, and then click Properties.

  5. Under Names, click Permissions.

  6. Click List all objects, and then select the permission to grant, deny, or revoke on each object.

    A checkmark indicates a granted permission; an 'X' indicates a denied permission; and an empty box indicates a revoked permission. Only permissions applicable to the object are listed.


How to start the default instance of SQL Server (Service Manager)

To start the default instance of SQL Server

  1. In the Services box, click SQL Server.

    If the service is a remote service, type the name of the remote server in the Server box.

  2. Click Start/Continue.

See Also

Starting SQL Server Manually


How to start a clustered instance of SQL Server (Service Manager)

To start a clustered instance of SQL Server

  1. Type the name of the virtual SQL Server in the Server box. If it is a default instance, you only need to specify the virtual server name. If it is a named instance, you must enter VIRTUALSERVER\Instance.

  2. In the Services box, click SQL Server.

  3. Click Start/Continue.

See Also

Starting SQL Server Manually


How to start a named instance of SQL Server (Service Manager)

To start a named instance of SQL Server

  1. In the Server box, select the name of the server and the named instance of Microsoft® SQL Server™ 2000, or type the name of the remote server.

  2. In the Services box, click SQL Server, and then click Start/Continue.


How to start the default instance of SQL Server (Windows)

To start the default instance of SQL Server

  1. In Control Panel, double-click Services.

  2. In the Services dialog box, click MSSQLSERVER, and then click Start.


How to start a named instance of SQL Server (Windows)

To start a named instance of SQL Server

  1. In Control Panel, double-click Services.

  2. In the Services dialog box, click the named instance of Microsoft® SQL Server™ 2000 you want to start, and then click Start.


How to start the default instance of SQL Server (Command Prompt)

To start the default instance of SQL Server from a command prompt

  • From a command prompt, enter:

    sqlservr.exe -c

    Note You must switch to the appropriate directory (for the instance of Microsoft® SQL Server™ you want to start) in the command window before starting sqlservr.exe.

See Also

Starting SQL Server Manually


How to start a named instance of SQL Server (Command Prompt)

To start a named instance of SQL Server from a command prompt

  • From a command prompt, enter this command:

sqlservr.exe -c -s {instancename}

Note You must switch to the appropriate directory (for the instance of Microsoft® SQL Server™ 2000 you want to start) in the command window before starting sqlservr.exe. For example, if Instance1 uses \mssql$Instance1 to store its binaries, you must be in the \mssql$Instance1\binn directory to start sqlservr.exe.


How to start the default instance of SQL Server in single-user mode (Command Prompt)

To start the default instance of SQL Server in single-user mode from a command prompt

  • From a command prompt, enter:

    sqlservr.exe -c -m

    Note You must switch to the appropriate directory (for the instance of Microsoft® SQL Server™ you want to start) in the command window before starting sqlservr.exe.

See Also

Starting SQL Server in Single-User Mode

Using Startup Options


How to start a named instance of SQL Server in single-user mode (Command Prompt)

To start a named instance of SQL Server in single-user mode from a command prompt

  • From a command prompt, enter:

    sqlservr.exe -c - m -s {instancename}

    Note You must switch to the appropriate directory (for the instance of Microsoft® SQL Server™ 2000 you want to start) in the command window before starting sqlservr.exe.


How to start the default instance of SQL Server with minimal configuration (Command Prompt)

To start the default instance of SQL Server with minimal configuration

  • From a command prompt, enter the following command to start the default instance of Microsoft® SQL Server™ as a service:

    sqlservr -c -f

    Note You must switch to the appropriate directory (for the instance of SQL Server you want to start) in the command window before starting sqlservr.exe.

See Also

Starting SQL Server Manually


How to start a named instance of SQL Server with minimal configuration (Command Prompt)

To start a named instance of SQL Server with minimal configuration

  • From a command prompt, enter the following command to start a named instance of Microsoft® SQL Server™ 2000 as a service:

    sqlservr -c -f -s {instancename}

    Note You must switch to the appropriate directory (for the instance of SQL Server you want to start) in the command window before starting sqlservr.exe.


How to pause and resume the default instance of SQL Server (Service Manager)

To pause and resume the default instance of SQL Server

  1. In the Services box, click SQL Server.

    If the service is a remote service, type the name of the remote server.

  2. Click Pause, and then click Start/Continue.

See Also

Pausing and Resuming SQL Server


How to stop a clustered instance of SQL Server (Service Manager)

To stop a clustered instance of SQL Server

  1. Type the name of the virtual Microsoft® SQL Server™ in the Server box. If it is a default instance, you only need to specify the virtual server name. If it is a named instance, you must enter VIRTUALSERVER\Instance.

  2. In the Services box, click SQL Server.

  3. Click Stop. This pauses the cluster resource, and then stops the SQL Server service, which does not cause a failover of SQL Server.

See Also

Stopping SQL Server


How to pause and resume a named instance of SQL Server (Service Manager)

To pause and resume a named instance of SQL Server

  1. In the Server box, select the name of the server and the named instance of Microsoft® SQL Server™ 2000, or type the name of the remote server.

  2. In the Services box, click SQL Server.

  3. Click Pause, and then click Start/Continue.


How to pause and resume the default instance of SQL Server (Windows)

To pause and resume the default instance of SQL Server

  1. In Control Panel, double-click Services.

  2. In the Services dialog box, click MSSQLSERVER.

  3. Click Pause or Continue.


How to pause and resume a named instance of SQL Server (Windows)

To pause and resume a named instance of SQL Server

  1. In Control Panel, double-click Services.

  2. In the Services dialog box, click the named instance of Microsoft® SQL Server™ 2000 you want to pause.

  3. Click Pause or Continue.


How to pause and resume the default instance of SQL Server (Command Prompt)

To pause and resume the default instance of SQL Server

  • From a command prompt, enter either:

    net pause mssqlserver

    -or-

    net continue mssqlserver

    An instance of Microsoft® SQL Server™ can be paused or resumed only if it was started as a Microsoft Windows NT® 4.0 or Windows® 2000 service.

See Also

Pausing and Resuming SQL Server


How to pause and resume a named instance of SQL Server (Command Prompt)

To pause and resume a named instance of SQL Server

  • From a command prompt, enter either:

    net pause mssql$instancename

    -or-

    net continue mssql$instancename


How to broadcast a shutdown message (Command Prompt)

To broadcast a shutdown message

  • From a command prompt, enter:

    net send /users "message"

    For example:

    net send /users "SQL Server is going down in 20 minutes.
Disconnect within 15 minutes."

    Note The shutdown message can be broadcast only if an instance of Microsoft® SQL Server™ is running on Microsoft Windows NT® 4.0 or Windows® 2000. The users option specifies that the message be sent to all users connected to the server. For information about other net send options, see the Windows NT 4.0 and Windows 2000 documentation.

See Also

Stopping SQL Server


How to stop the default instance of SQL Server (Windows)

To stop the default instance of SQL Server

  1. In Control Panel, double-click Services.

  2. In the Services dialog box, click MSSQLSERVER, and then click Stop.


How to stop a named instance of SQL Server (Windows)

To stop a named instance of SQL Server

  1. In Control Panel, double-click Services.

  2. In the Services dialog box, click the named instance of Microsoft® SQL Server™ 2000 you want to stop, and then click Stop.


How to stop the default instance of SQL Server (Command Prompt)

To stop the default instance of SQL Server

  • From a command prompt, enter:

    net stop mssqlserver

Note Stopping a default instance of Microsoft® SQL Server™ using SQL Server Enterprise Manager or the net stop mssqlserver command causes SQL Server to perform a checkpoint in all databases. Then a SHUTDOWN WITH NOWAIT is done to flush all committed data from the data cache and to stop the server immediately. Stopping a default instance of SQL Server from the command prompt works only if you are running Microsoft Windows NT® 4.0 or Windows® 2000.

See Also

Stopping SQL Server


How to stop a named instance of SQL Server (Command Prompt)

To stop a named instance of SQL Server

  • From a command prompt, enter:

    net stop mssql$instancename

Note Stopping a named instance of Microsoft® SQL Server™ 2000 using SQL Server Enterprise Manager or the net stop mssql$instancename command causes SQL Server to perform a checkpoint in all databases. Then a SHUTDOWN WITH NOWAIT is done to flush all committed data from the data cache and to stop the server immediately. Stopping a named instance of SQL Server 2000 from the command prompt works only if you are running Microsoft Windows NT® 4.0 or Windows® 2000.


How to log in to the default instance of SQL Server (Command Prompt)

To log in to the default instance of SQL Server

  • From a command prompt, enter either:

    osql /U [login_id] /P [password] /S [servername]

    -or-

    isql/U [login_id]/P [password] /S [servername]

See Also

osql Utility


How to log in to a named instance of SQL Server (Command Prompt)

To log in to a named instance of SQL Server

  • From a command prompt, enter either:

    osql / U login_id /P password /S servername\instancename

    -or-

    isql/U login_id/P password /S servername\instancename


How to change the default service (Service Manager)

To change the default service

  1. Right-click SQL Server Service Manager, and then click Options.

  2. In the Default Service box, select the new default service to view through SQL Server Service Manager. When you restart the computer, the service that appears is the new default. For example, if you change the default service to SQLServerAgent service and then shut down the computer, the next time you start it, SQLServerAgent service will be displayed in Service Control Manager. You can only change the default service for the local machine.


Installing Analysis Services

This section contains information about installing Microsoft® SQL Server™ 2000 Analysis Services only. It does not contain information about installing other components of SQL Server 2000. For more information about installing other components, such as English Query, see Getting Started with SQL Server Books Online.

This section contains the following topics.

Topic | Description
Hardware and Software Requirements for Installing Analysis Services | Provides the hardware and software requirements for installing and running Analysis Services.
Running Setup | Provides step-by-step instructions to install Analysis Services.
Setup Parameters and Silent Installation | Describes the parameters for the Analysis Services Setup program (Setup.exe).
Reinstalling Analysis Services | Describes how to reinstall Analysis Services.
Removing Analysis Services | Describes how to remove Analysis Services.
Upgrading from SQL Server 7.0 OLAP Services | Describes how to upgrade from SQL Server 7.0 OLAP Services.
Backward Compatibility | Provides information about compatibility with OLAP Services (the previous name for the current Analysis Services).

Related Documents

The Readme.html file in the root directory of the SQL Server 2000 CD-ROM contains information about Analysis Services. You can also view the release notes by clicking Read the Release Notes on the SQL Server 2000 Setup program (Autorun.exe) menu.


Hardware and Software Requirements for Installing Analysis Services

Before you can install Microsoft® SQL Server 2000™ Analysis Services, your computer must meet the following requirements.

Hardware/software | Requirements
Computer | Intel® or compatible (Pentium 133 MHz or higher, Pentium PRO, Pentium II, or Pentium III)
Memory (RAM) | 32 megabytes (MB) minimum (64 MB recommended)(4)
Disk drive | CD-ROM drive
Hard disk space (1) | 50 – 90 MB (130 MB for all components including common files and samples), 12 MB for the client only
Operating system | Microsoft Windows® 2000 Server (3) -or- Microsoft Windows NT® Server 4.0 with Service Pack 5 or later (3) For client components on client computers only, the following systems also qualify: Windows 2000 Professional Windows NT Workstation 4.0 with Service Pack 5 Windows 98 Windows 95 + DCOM95 Windows 95 OSR2 + DCOM95
Network software | Windows 2000, Windows NT 4.0, Windows 98, or Windows 95 built-in network software; and TCP/IP (included with Windows).
Online product documentation viewer | Microsoft Internet Explorer version 5.0 or later (2). You must install Windows NT 4.0 Service Pack 5 or later before you install Internet Explorer version 5.0.
Access permissions | To install the services for Analysis server, you must be logged on to the server with Administrator permissions.

1 Setup installs a number of components that can be shared by other applications and may already exist on the computer.
2 Internet Explorer is required for Microsoft Management Console (MMC) and HTML Help. A minimal installation is sufficient, and Internet Explorer does not need to be your default browser. Internet Explorer is not required for the client-only installation.
3 Analysis Services should not be installed on a domain controller; this installation configuration is not supported.
4 Analysis Services does not support Address Windowing Extensions (AWE).

For more information about supported hardware, see the Microsoft Windows Hardware Compatibility List at the Microsoft Web site. For more information about Windows 2000-compatible hardware, use the Microsoft Windows 2000 compatible hardware devices search tool at the Microsoft Web site.


Running Setup

This topic describes how to install Microsoft® SQL Server™ 2000 Analysis Services.

If you are upgrading from SQL Server 7.0 OLAP Services, you should take certain steps before performing the following procedure. For more information, see Upgrading from SQL Server 7.0 OLAP Services.

If you are reinstalling Analysis Services, you should take certain steps before and after performing the following procedure. For more information, see Reinstalling Analysis Services.

Although Analysis Services can connect to multiple instances of SQL Server running on a single computer, you cannot install multiple instances of Analysis Services on a single computer.

To install Analysis Services, use the Analysis Services Setup program or the SQL Server 2000 Setup program.

To install Analysis Services

  1. Exit all Microsoft Windows® applications.

  2. Insert the SQL Server 2000 CD into the CD-ROM drive. This starts the SQL Server 2000 Setup program. If the Setup program does not start automatically, run the Autorun.exe program in the root directory of the CD-ROM.

  3. Click Install SQL Server 2000 Components.

  4. Click Analysis Services to start the Analysis Services Setup program.

  5. In the Welcome step, click Next.

  6. In the Software License Agreement step, read the license agreement, and then do one of the following:
    • To accept the license agreement, click Yes. You must select this option to install Analysis Services.

    • To reject the license agreement, click No. If you select this option, the program will ask you to confirm exiting. If you select Exit Setup, the program closes and the installation is canceled. To continue Setup, click Resume.
  7. The Setup program prompts you to enter the CD key. Type the 10-digit CD key for the product, and then click OK.

  8. The Setup program displays the complete product ID, which you can record for future reference. After you record the product ID, click OK.

  9. In the Select Components step, select the components you want to install. All of the options are selected by default. You cannot clear the check box of any component on which another selected component depends.

    Unless you are installing the client components on a client computer, installing all components is recommended. The following components are available for installation.

    Component | Description
    Analysis server | Binary executables and other server-related files required for an installation of an Analysis server. Includes the FoodMart 2000 sample database used by the tutorial. Requires the client components.
    Analysis Manager | Binary executables and other files that support the user interface for administering the Analysis server. Includes the MDXSample executable file. Requires Decision Support Objects (DSO) and the client components.
    Decision Support Objects | The object model for administering the Analysis server and managing meta data. Requires the client components.
    Client components | Binary executables and related files for the Analysis Services client. Client components include PivotTable® Service.
    Sample applications | Sample applications include the MDXSample source files, the FoodMart 2000 database, and programming samples. Requires the client components.
    Books Online | The entire documentation set for SQL Server 2000, including Analysis Services. This file is approximately 30 megabytes (MB). If space is at a premium, you can choose not to install Books Online. However, product documentation will not be available in the user interface until it is reinstalled.

    To change the destination drive or folder, click Browse. Although remote network drives are listed in these dialog boxes, installation to locations on remote network drives is not supported.

    Space Required and Space Available indicate disk drive space and help you determine what components to install. If your current disk drive does not have enough space available, you can click Disk Space to determine which disks on your computer have enough space to install Analysis Services.

    After you select the components to install, click Next. The steps that follow may change depending on which components you selected to install.

  10. In the Data Folder Location step, you can change the location of the Data folder, which is the data storage location of the Analysis server.

    The default location for the Data folder is C:\Program Files\Microsoft Analysis Services\Data (unless you specified another location for Analysis Services in the previous step). You can specify a different location by clicking Browse. If you change the default folder or drive, be sure to enter a fully qualified path. To specify a data storage location other than the computer on which the server is installed, you must have full control access permissions on that computer.

    Important The Data folder stores security files that control end users' access to objects on the Analysis server. For this reason, the Data folder must be secured against unauthorized access.

    After you select the location of the Data folder, click Next.

  11. In the Select Program Folder step, accept the default program folder name or enter a new one. This determines the location of the Analysis Services menu items on the Start menu. Click Next.

  12. Analysis Services installation begins. After Setup notifies you that the installation is complete, click Finish.

  13. If you are prompted to restart your computer, do one of the following:
    • Click Yes, I want to restart my computer now, and then click Finish.

    • Click No, I will restart my computer later, and then click Finish. If you select this option, the installation is not complete until after you restart the computer.
  14. If you are finished installing SQL Server 2000 components, click Exit in the SQL Server 2000 Setup program.

If in Step 10 you specified a data storage location other than the computer on which the server is installed, you must configure your Analysis server service (MSSQLServerOLAPService) to log on as your user account, instead of the default, which is to log on as the system account. To do this, use the Services application, which is in Control Panel in Windows NT® 4.0 or the Administrative Tools folder in Control Panel in Windows 2000.


Setup Parameters and Silent Installation

You can start the Analysis Services Setup program (\Msolap\Install\Setup.exe on the SQL Server CD-ROM) with the following optional command line parameters:

-r

This option causes Setup.exe to automatically generate a silent response file (.iss), which is a record of the installation input, in the systemroot folder (typically C:\WinNT).

-s

This option performs a silent (unattended) installation.

-f1<path\ResponseFile>

This option allows you to specify the alternate location and name of the response file (.iss file). If the -f1 switch is not used when you run silent installation, Setup searches for the response file Setup.iss in the same folder as Setup.exe.

-f2<path\LogFile>

This option allows you to specify an alternate location and name of the log file. By default, the Setup.log log file is created and stored in the systemroot folder (typically C:\Winnt).

If you use the -r option you can create a record of any installation scenario. You can use this record to perform a silent (unattended) installation. For example, the following command initiates a silent installation of the components specified in the Setup.iss response file previously recorded when you used the -r option:

Setup.exe -s -f1C:\temp\setup.iss

-z

Prevents Setup.exe from checking the available memory during initialization. This switch is necessary when running Setup on a computer with more than 256 megabytes (MB) of memory. If it is not used, Setup.exe reports insufficient memory and exits.


Reinstalling Analysis Services

To reinstall Microsoft® SQL Server™ 2000 Analysis Services, follow these steps:

  1. If you have made changes to the FoodMart 2000 sample database and want to preserve changes, back up FoodMart2000.mdb, which is installed by default to: C:\Program Files\Microsoft Analysis Services\Samples. Otherwise, this file is overwritten during the installation process.

  2. Install Analysis Services. For more information, see Running Setup.

Note Reinstalling Analysis Services does not delete the Analysis Services repository (Msmdrep.mdb), which contains Analysis Services meta data. However, you must process all cubes in the repository after reinstallation. If you have backed up the FoodMart 2000 sample database before reinstallation, restore FoodMart2000.mdb to recover your changes to the file.


Stopping or Removing Analysis Services

To stop Microsoft® SQL Server™ 2000 Analysis Services, follow these steps:

  1. Open Control Panel.

  2. If your computer's operating system is Windows® 2000, open the Administrative Tools folder, and then double-click Services.

    If your computer's operating system is Windows NT® 4.0, double-click Services.

  3. Select MSSQLServerOLAPService, and then on the Action menu click Stop.

  4. Wait until the application notifies you that the service has stopped.

To remove Analysis Services, use the Add/Remove Programs application in Control Panel. Removing Analysis Services does not delete the Analysis Services repository (Msmdrep.mdb), which contains Analysis Services meta data, or the query log (Msmdqlog.mdb). If you want to fully remove Analysis Services, you must delete these files manually.


Upgrading from SQL Server 7.0 OLAP Services

To upgrade from Microsoft® SQL Server™ 7.0 OLAP Services, perform the following actions:

  • Back up the Analysis Services repository and query log.

  • Before you install Analysis Services, as a precaution against data loss, back up the Analysis Services repository (Msmdrep.mdb), which contains Analysis Services meta data, and the query log (Msmdqlog.mdb). These files are located in the Bin folder in the Analysis Services folder.Run Setup.

    Install Analysis Services by running the Analysis Services Setup program. For more information, see Running Setup.

When you upgrade, Setup does not delete or replace the Analysis Services repository or the query log.

Note The default location for Analysis Services has changed from C:\Program Files\OLAP Services in SQL Server 7.0 OLAP Services to C:\Program Files\Microsoft Analysis Services in SQL Server 2000 Analysis Services.


Backward Compatibility

Microsoft® SQL Server™ 2000 Analysis Services is compatible with SQL Server version 7.0 OLAP Services. Cubes that were created in SQL Server 7.0 OLAP Services need to be migrated to the updated meta data repository format and reprocessed. Otherwise, the existing structures for cubes, roles, shared dimensions, and so on do not need to be changed. For more information about migrating the SQL Server 7.0 OLAP Services repository to SQL Server 2000 Meta Data Services, see Migrating Analysis Services Repositories.

The following sections concern backward compatibility with SQL Server 7.0 OLAP Services.

Administration of Analysis Services

Analysis Manager is backward compatible with SQL Server 7.0 OLAP Services. It is capable of administering both OLAP servers (the server that ships with SQL Server 7.0 OLAP Services), and Analysis servers (the server that ships with SQL Server 2000 Analysis Services) concurrently. When administering an OLAP server, the OLAP Services portion of SQL Server 7.0 Service Pack 2 code is used to assure complete backward compatibility. The add-in programs in Service Pack 2 are now integrated with Analysis Manager and do not need to be installed to administer OLAP servers.

Client and Local Cube Support

Some features in SQL Server 2000 Analysis Services are not supported by the SQL Server 7.0 OLAP Services client components or in a local cube. For more information, including a list of features, see 7.0 Analysis Services Client and Local Cube Support.

Decision Support Objects

Analysis Services now includes an updated version of Decision Support Objects (DSO), which is automatically installed during Setup. Programs must use this updated version of DSO when administering an Analysis server (the server that ships with SQL Server 2000 Analysis Services). No other change to these programs is necessary. Programs that use the updated version of DSO are compatible with and can administer OLAP servers (the server that ships with SQL Server 7.0 OLAP Services); however, new features will not be available on the OLAP server.

PivotTable Service

SQL Server 2000 Analysis Services includes an updated version of PivotTable® Service. Client applications that use PivotTable Service do not need to use this new version when connecting to an Analysis server unless you need access to objects that include new features. The objects that use these new features (such as data mining models and cubes that include parent-child dimensions) are not seen by the client applications that use the earlier version of PivotTable Service. Client applications that use the updated version of PivotTable Service can connect to any server, regardless of its version. Client applications that use the updated version of PivotTable Service can configure their compatibility settings using the following properties:

  • MDX Compatibility property

  • MDX Unique Name Style property

  • Secured Cell Value property

  • Visual Mode property
Custom Add-in Programs

Custom add-in programs that were developed for use with SQL Server 7.0 OLAP Services will continue to work with SQL Server 2000 Analysis Services. No changes are necessary to use them.

Archiving, Restoring, and Migrating Data

Analysis Services supports some but not all permutations of archiving and restoring databases and migrating repositories between versions of the product. For information about supported migration paths, see Supported Migration Paths for Analysis Services Repositories. For information about archiving and restoring data between versions of the product, see Archiving and Restoring Databases Between Versions of Analysis Services.


7.0 Analysis Services Client and Local Cube Support

This table shows support for new server features by the Microsoft® SQL Server™ 7.0 OLAP Services client components and in a SQL Server 2000 Analysis Services local cube. When a feature may cause data to be translated incorrectly by a 7.0 client application, the server prevents the cube from being visible and prevents the client connection to the cube. If the absence of a feature in a local cube might change data values presented to the user, then a local cube using the feature cannot be created.

For each feature listed here, the table shows whether a cube containing a feature is visible on a 7.0 client application and if the cube is visible whether the feature itself is available on the 7.0 client application. For each feature, the table also shows whether a local cube can be created using the feature and whether the feature itself is supported in a local cube.

Feature | Cube is visible on 7.0 client | Feature available on 7.0 client | Can create local cube using feature | Supported in a local cube
Actions | Yes | No | Yes | No
Additional authentication methods | Yes | Yes | Yes | (2)
Calculated cells | No | No | No | No
Changing dimensions | Yes | No | Yes | No
Custom member formulas | No | No | No | No
Custom rollup formulas | No | No | No | No
Default members | No | No | Yes | Yes
Dimension security | No | No | No | No
DistinctCount | No | No | No | No
Drillthrough | Yes | No | Yes | No
Enhanced cell Security | Yes | Yes | Yes | No
Enhanced virtual dimensions (1) | Yes | Yes | Yes | Not applicable
Exceeding 7.0 Limits(3) | No | No | Yes | Yes
Linked cubes | Yes | Not applicable | Yes | No
Member groups | Yes | Yes | Yes | Yes
Members with data | Yes | Yes | Yes | Yes
New MDX functions | Yes | No | Yes | (4)
Parent-child dimensions | No | No | Yes | Yes
Ragged dimensions | Yes | Yes | Yes | Yes
ROLAP dimensions | Yes | Not applicable | Yes | No
Siblings with same names | No | No | Yes | Yes
Write-enabled dimensions | Yes | No | Yes | No

1 The earlier limit of 760 members in a virtual dimension does not apply.
2 Cell security is not supported on local cubes.
3 Exceeding 127 measures in a cube, 63 dimensions in a cube, or 128 levels in a cube. For information about SQL Server 2000 Analysis Services limits, see Specifications and Limits.
4 For the SQL Server 7.0 OLAP Services client, new Multidimensional Expressions (MDX) functions are not supported. For local cubes, new MDX functions are available, except for LookUpCube. Calculated members using LookUpCube in local cubes are not created.


Supported Migration Paths for Analysis Services Repositories

New Information - SQL Server 2000 SP3.

You can migrate a Microsoft® SQL Server™ 2000 Analysis Services repository from the default Microsoft Access (Microsoft Jet 3.5 or 4.0) database to a SQL Server database on the same or a different computer. You cannot migrate a SQL Server repository to a Microsoft Access repository. You can change the format from Analysis Services native format to SQL Server 2000 Meta Data Services format when you migrate a database. To migrate a SQL Server database repository between Analysis Services native format and Meta Data Services format, you must migrate it from one SQL Server database to another. The following table shows supported migration paths for repository databases.

 |  | To native |  | To MDS
 |  | Jet 3.5/4.0 | SQL Server 7.0/2000 | SQL Server 2000
From native | Jet 3.5/4.0 | No | Yes | Yes
 | SQL Server 7.0/2000 | No | Yes(2) | Yes(2)
From MDS(1) | SQL Server 2000 | No | Yes(2) | Yes(2)

1 MDS represents the Meta Data Services (previously named Microsoft Repository) format supported by SQL Server 2000.
2 Source and destination must be different databases.

Analysis Services native format is recommended. If the SQL Server 2000 database engine is available to the Analysis server, either on the same computer or another computer, migrating the repository to a SQL Server 2000 database provides enterprise-level scalability, support, and security for the Analysis Services repository.

See Also

Migrating Analysis Services Repositories

OLE DB Provider for Jet


Archiving and Restoring Databases Between Versions of Analysis Services

On an Analysis server (the server that ships with Microsoft® SQL Server™ 2000 Analysis Services), you can restore databases that were archived using an OLAP server (the server that ships with SQL Server 7.0 OLAP Services) or an Analysis server. The following table shows all the restoration paths supported for databases archived while in SQL Server 7.0 OLAP Services or SQL Server 2000 Analysis Services using native or SQL Server 2000 Meta Data Services formats with SQL Server or the Microsoft Jet 3.5 or 4.0 OLE DB provider.

 |  |  | To native |  |  |  | To MDS
 |  |  | Jet 3.5/4.0 |  | SQL Server |  | SQL Server
 |  |  | 7.0 | 2000 | 7.0 | 2000 | 2000
From native(1) | Jet 3.5/4.0 | 7.0 | Yes | Yes | Yes | Yes | Yes
 |  | 2000 | No(3) | Yes | No(3) | Yes | Yes
 | SQL Server | 7.0 | Yes | Yes | Yes | Yes | Yes
 |  | 2000 | No(3) | Yes | No(3) | Yes | Yes
From MDS(2) | SQL Server | 2000 | No(3) | Yes | No(3) | Yes | Yes

1 From specifies the repository format, database engine, and version of OLAP Services or Analysis Services that archives a database; To specifies the repository format, database engine, and version of OLAP Services or Analysis Services that restores a database.
2 MDS represents the Meta Data Services (previously named Microsoft Repository) format supported by SQL Server 2000.
3 OLAP servers do not support restoration of Analysis Services databases.

See Also

Archiving and Restoring Databases

OLE DB Provider for Jet


Microsoft SQL Server 2000 Copyright and Disclaimer

This document, including sample applications herein, is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document, including samples, URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results of the use of this document remains with the user.

The primary purpose of a sample is to illustrate a concept, or a reasonable use of a particular statement or clause. Most samples do not include all of the code that would normally be found in a full production system, as a lot of the usual data validation and error handling is removed to focus the sample on a particular concept or statement. Technical support is not available for these samples or for the provided source code.

Unless otherwise noted, the example companies, organizations, products, people, and events depicted herein are fictitious and no association with any real company, organization, product, person, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

©1988-2002 Microsoft Corporation. All rights reserved.

Active Directory, ActiveX, BackOffice, CodeView, Developer Studio, FoxPro, JScript, Microsoft, Microsoft Press, Microsoft SQL Server, MSDN, MS-DOS, Outlook, PivotChart, PivotTable, PowerPoint, Visual Basic, Visual C++, Visual Studio, Win32, Windows 2000, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Version: 8.00.002


Additional SQL Server Resources

New Information - SQL Server 2000 SP3.

This table provides Internet resources for information about Microsoft® SQL Server™ and related products and technologies.

Resource | Address
Microsoft Product Support Services Web | http://support.microsoft.com/directory
Microsoft Security and Privacy Web site | http://www.microsoft.com/security
Microsoft Usenet | news://msnews.microsoft.com/
Microsoft Windows® Hardware Compatibility List | http://www.microsoft.com/hcl
MSDN® | http://msdn.microsoft.com
Meta Data Services (formerly known as Microsoft Repository) | http://msdn.microsoft.com
Professional Association for SQL Server | http://www.sqlpass.org/
Microsoft SQL Server Developer Center | http://msdn.microsoft.com
SQL Server Magazine | http://www.sqlmag.com/
Microsoft SQL Server Support | http://support.microsoft.com/support/sql
TechNet Site | www.Microsoft.com/technet
Microsoft Accessibility Web site | http://www.microsoft.com/enable
Microsoft SQL Server Web site | http://www.microsoft.com/sql
Microsoft SQL Server Web site, Security page | http://www.microsoft.com/sql
Microsoft SQL Server Web site, English Query page | http://www.microsoft.com/sql
Microsoft SQL Server Web site, Analysis Services page | http://www.microsoft.com/sql
XML Developer Center | http://www.msdn.microsoft.com/xml/default.asp


...

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z


Using Accessibility Features in SQL Server Books Online

The following topics describe the accessibility features that can be used for navigating SQL Server Books Online.

For more information about accessibility features and services, see the Accessibility page at Microsoft Web site.

Changing the Appearance of the Text

The formatting, font, and color of the text in SQL Server Books Online can be changed.

To change formatting or styles for accessibility

  1. On the Options menu, click Internet Options, and then click Accessibility.

  2. In the Accessibility dialog box, select the options you want, and then click OK.

These changes do not apply to the Navigation pane or toolbar of SQL Server Books Online. This procedure also changes your accessibility settings for Microsoft® Internet Explorer.

To change the font size of a topic

  • On the Options menu, click Internet Options, and then click Fonts.

These changes do not apply to the Navigation pane or toolbar of SQL Server Books Online. This procedure also changes your font settings for Internet Explorer.

To change colors in the Topic pane of SQL Server Books Online

  1. In Microsoft Internet Explorer 5.0, on the Tools menu, click Internet Options.

  2. On the General tab, click Colors.

  3. In the Colors dialog box, select the options you want, and then click OK.

  4. To apply the new color settings, in the Internet Options dialog box, click OK.

These changes do not apply to the Navigation pane or toolbar of SQL Server Books Online. This procedure also changes your color settings for Internet Explorer.

Using Keyboard Shortcuts

The following tables show the keyboard shortcuts that can be used for navigating SQL Server Books Online.

SQL Server Books Online
To | Press
Close SQL Server Books Online. | ALT+F4
Switch between SQL Server Books Online and other open windows. | ALT+TAB
Display the Options menu. | ALT+O
Change Microsoft® Internet Explorer settings. The Internet Options dialog box contains accessibility settings. To change these settings, click the General tab, and then click Accessibility. | ALT+O, and then press I
Hide or show the Navigation pane. | ALT+O, and then press T
Print a topic. | ALT+O, and then press P
Move back to the previous topic. | ALT+LEFT ARROW, or ALT+O, and then press B
Move forward to the next topic (provided you have just previously viewed it). | ALT+RIGHT ARROW, or ALT+O, and then press F
Turn on or off search highlighting. | ALT+O, and then press O
Switch between the Navigation pane and the Topic pane. | F6
Scroll through the table of contents, displaying each topic as you scroll. | ALT+UP ARROW, or ALT+DOWN ARROW
Scroll through a topic. | UP ARROW and DOWN ARROW, or PAGE UP and PAGE DOWN
Scroll through all the links in a topic or through all the options on a Navigation pane tab. | TAB
Display the Documentation Feedback form. | SHIFT+CTRL+F
Display the topic containing keyboard shortcuts. | SHIFT+CTRL+K
Display the See Also topics for a particular topic. | SHIFT+CTRL+S

Contents Tab
To | Press
Display the Contents tab. | ALT+C
Open and close a book or folder. | PLUS SIGN and MINUS SIGN, or LEFT ARROW and RIGHT ARROW
Select a topic. | DOWN ARROW and UP ARROW
Display the selected topic. | ENTER

Index Tab
To | Press
Display the Index tab. | ALT+N
Type a keyword to search for. | ALT+W, and then type the word
Select a keyword in the list. | UP ARROW and DOWN ARROW
Display the associated topic. | ALT+D

Search Tab
To | Press
Display the Search tab. | ALT+S
Type a keyword to search for. | ALT+W, and then type the word
Start a search. | ALT+L
Select a topic in the results list. | ALT+T, and then UP ARROW and DOWN ARROW
Display the selected topic. | ALT+D
Search for a word or phrase in a topic. | CTRL+F
Search for a keyword in the result list of a prior search. | ALT+U
Search for words similar to the keyword. For example, to find words such as "running" and "runs" for the keyword "run." | ALT+M
Search only through topic titles. | ALT+R

Favorites Tab
To | Press
Display the Favorites tab. | ALT+I
Add the currently displayed topic to the Favorites list. | ALT+A
Select a topic in the Favorites list. | ALT+P, and then UP ARROW and DOWN ARROW
Display the selected topic. | ALT+D
Remove the selected topic from the list. | ALT+R


Using the Search Tab

SQL Server Books Online includes a Search tab that allows you to search through every word in SQL Server Books Online to find a match. For example, if you perform a full-text search on the word "index", every topic that contains the word "index" is listed. You can precisely define a search by using wildcard expressions, nested expressions, and Boolean operators. You can request similar word matches, search only the topic titles, or search the results of an earlier search.

All instances of search terms that are found in the topic files can appear highlighted. To specify highlighting, click the Options button, and then click Search Highlight On. If you are viewing a long topic, only the first 500 instances of a search word or phrase are highlighted. This feature works only with Microsoft® Internet Explorer 4.0 or later.

Searching for Topics

A search consists of the word or phrase you want to find. You can use wildcard expressions, nested expressions, Boolean operators, similar word matches, a previous results list, or topic titles to further define your search.

The basic rules for formulating queries are:

  • Searches are not case-sensitive, so you can type your search in uppercase or lowercase characters.

  • You can search for any combination of letters (a-z) and numbers (0-9).

  • Punctuation marks such as the period, colon, semicolon, comma, and hyphen are ignored during a search.

  • Group the elements of your search using double quotation marks or parentheses to set apart each element. You cannot search for quotation marks.

If you are searching for a file name with an extension, you should group the entire string in double quotation marks ("filename.ext"). Otherwise, the period breaks the file name into two separate terms. The default operation between terms is AND, which is the logical equivalent to "filename AND ext".

To find information with full-text search

  1. Click the Search tab, and then type the word or phrase you want to find.

  2. Click the arrow button to add Boolean operators to your search.

  3. Click List Topics, select the topic you want, and then click Display.

  4. To sort the topic list, click the Title, Location, or Rank column heading.

Note The ranking of topics under the Rank column is not determined by any standard (for example, alphabetical order or most hits). Do not use the ranking to determine which topics to view.

Searching for Words or Phrases

You can search for words or phrases and use wildcard expressions. Wildcard expressions allow you to search for one or more characters using a question mark or asterisk. The table describes the results of these different kinds of searches.

Search for | Example | Results
A single word | select | Topics that contain the word "select". (You will also find its grammatical variations, such as "selector" and "selection".)
A phrase | "new operator" or new operator | Topics that contain the literal phrase "new operator" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying "new AND operator", which will find topics containing both of the individual words, instead of the phrase.
Wildcard expressions | esc* or 80?86 | Topics that contain the terms "ESC", "escape", "escalation", and so on. The asterisk cannot be the only character in the term. Topics that contain the terms "80186", "80286", "80386", and so on. The question mark cannot be the only character in the term.

Select the Match similar words check box at the bottom of the Search tab to include minor grammatical variations for the phrase you search.

Defining Search Terms

The AND, OR, NOT, and NEAR operators enable you to precisely define your search by creating a relationship between search terms. The following table shows how you can use each of these operators. If an operator is not specified, AND is used. For example, the query "spacing border printing" is equivalent to "spacing AND border AND printing".

Search for | Example | Results
Both terms in the same topic. | dib AND palette | Topics containing both the words "dib" and "palette".
Either term in a topic. | raster OR vector | Topics containing either the word "raster" or the word "vector" or both.
The first term without the second term. | ole NOT dde | Topics containing the word "OLE", but not the word "DDE".
Both terms in the same topic, close together. | user NEAR kernel | Topics containing the word "user" within eight words of the word "kernel".

The characters |, &, and ! do not work as Boolean operators (you must use OR, AND, and NOT).

Note You must define a search phrase that begins with AND, OR, NOT, or NEAR with double quotation marks; otherwise, these words are interpreted as operators, and the search cannot be performed. For example, a search for the phrase NOT FOR REPLICATION returns an error message, and a search for the phrase "NOT FOR REPLICATION" succeeds.

Using Nested Expressions When Searching

Nested expressions allow you to create complex searches for information. For example, "control AND ((active OR dde) NEAR window)" finds topics containing the word "control" along with the words "active" and "window" close together, or containing "control" along with the words "dde" and "window" close together.

The basic rules for searching Help topics using nested expressions are:

  • You can use parentheses to nest expressions within a query. The expressions in parentheses are evaluated before the rest of the query.

  • If a query does not contain a nested expression, it is evaluated from left to right. For example: "Control NOT active OR dde" finds topics containing the word "control" without the word "active", or topics containing the word "dde". On the other hand, "control NOT (active OR dde)" finds topics containing the word "control" without either of the words "active" or "dde".

  • You cannot nest expressions more than five levels deep.

To search only the last group of topics from a previous search

This feature enables you to narrow a search that results in too many topics found. You can search through your results list from a previous search by using this option.

  1. On the Search tab, select the Search previous results check box.

  2. Click List Topics, select the topic you want, and then click Display.

If you want to search through all of the files in SQL Server Books Online, this check box must be cleared. If you have previously used this feature, when you click the Search tab, this check box will be selected.

To find words similar to your search term

This feature enables you to include minor grammatical variations for the phrase you search. For example, a search on the word "add" finds "add", "adds", and "added".

  1. Click the Search tab, type the word or phrase you want to find, and then select the Match similar words check box.

  2. Click List Topics, select the topic you want, and then click Display.

This feature locates only variations of the word with common suffixes. For example, a search on the word "add" finds "added", but it does not find "additive".

To search for words in the titles of SQL Server Books Online topics

  1. Click the Search tab, type the word or phrase you want to find, and then select the Search titles only check box.

  2. Click List Topics, select the topic you want, and then click Display.


Using Subsets to Find a Topic

The SQL Server Books Online documentation is divided into a set of default subsets. The subsets are targeted at specific audiences, and each subset covers multiple topics. Subsets make it easier to search for information related to your activities by minimizing the number of search hits. For example, an ADO programmer can use the ADO programmer subset to find information relevant to writing ADO applications, without getting topics with similar information in DB-Library and Embedded SQL. You can define your own subsets against which to perform a search.

To define your own subsets

  1. On the View menu, click Define Subset.

  2. In the Select subset to display box, select New.

  3. In the Available Items list, click the items you want in the subset, and then click Add.

  4. In the Save new subset as box, type a name for the subset, and then click Save.

To use a default subset

  • Select the subset you want using the Active Subset drop-down list box in the Navigation pane of SQL Server Books Online.

To delete a subset

Note If you delete a subset, there is no way to restore it automatically; you must redefine the subset.

  1. On the View menu, click Define Subset.

  2. In the Select subset to display box, select the subset you want to delete, and then click Delete.


Changing the Way Topics Appear

The size and position of the SQL Server Books Online window and the Navigation and Topic panes can be easily changed:

  • To resize the Navigation or Topic pane, point to the divider between the two panes. When the pointer changes to a double-headed arrow, drag the divider right or left.

  • To shrink or enlarge SQL Server Books Online, point to any corner of the SQL Server Books Online window. When the pointer changes to a double-headed arrow, drag the corner.

  • To change the height or width of SQL Server Books Online, point to the top, bottom, left, or right edge of the SQL Server Books Online window. When the pointer changes to a double-headed arrow, drag the edge.

  • To reposition SQL Server Books Online on your screen, click the title bar and drag the SQL Server Books Online window to a new position.

Note When you open SQL Server Books Online, it appears with the size and position settings that were last specified.


Finding a Topic

To find a topic in SQL Server Books Online, use the tabs in the Navigation pane:

  • Click the Contents tab to browse the table of contents, which is an expandable, hierarchical list of topics.

  • Click the Index tab to see a list of index entries, and then type a term that you want to search for or scroll through the list of terms. Topics are often indexed under more than one entry.

  • Click the Search tab and then type the word to locate every occurrence of a word or phrase that may be contained in SQL Server Books Online. For more information, see Using the Search Tab.

    Note The results of a search are displayed in three columns: Title, Location, and Rank. The ranking of topics under the Rank column is not determined by any standard (for example, alphabetical order or most number of hits). Do not use the ranking to determine which topics to view.

  • Click the navigation buttons on the toolbar. For more information, see Using SQL Server Books Online.
Creating and Using the Favorites List

The Favorites list provides a convenient way to access topics that you frequently refer to.

  • To create a list of favorite topics, locate the topic you want to make a favorite topic, click the Favorites tab, and then click Add.

  • To return to a favorite topic, click the Favorites tab, select the topic, and then click Display.

  • If you want to rename a topic, on the Favorites tab, select the topic, and then type a new name in the Current topic box.

  • To remove a favorite topic, on the Favorites tab, select the topic, and then click Remove.
Accessing a Topic Using a URL

You can use a URL to direct someone to a topic in SQL Server Books Online.

To direct someone to a topic in SQL Server Books Online

  1. On the page to which you want to direct someone, in the Navigation pane, right-click the topic, and then click Jump to URL.

  2. Copy the URL that appears in the Current URL box, and then paste it into an e-mail or other document.

  3. Instruct the person receiving the URL on how to paste the URL into the Jump to this URL dialog box.

    The URL can also be pasted in the Address box in Microsoft Internet Explorer. However, this will not bring up SQL Server Books Online; only the topic that you selected will be displayed.


Using SQL Server Books Online

SQL Server Books Online is the online documentation provided with Microsoft® SQL Server™ 2000. You can find information in SQL Server Books Online by:

  • Navigating through the contents pane.

  • Typing a keyword in the index.

  • Typing a word or phrase and performing a search.

SQL Server Books Online appears in a window that contains these panes:

Navigation pane

This pane is located on the left and contains the Contents, Index, Search, and Favorites tabs. The topics on the Contents tab are organized hierarchically by task or subject.

Topic pane

This pane is located on the right and displays the selected topic or the default topic.

Toolbar pane

This pane is located below the SQL Server Books Online title bar and contains the navigation and command buttons.

Using the Toolbar Buttons

You can find topics in SQL Server Books Online by using these navigational buttons on the toolbar:

Previous

Displays the previous topic listed in the table of contents.

Next

Displays the next topic listed in the table of contents.

Back

Displays the last topic you viewed.

Forward

Displays the next topic in a previously displayed sequence of topics.

Home

Displays the SQL Server Books Online Home Page.

Note The toolbar in your Help Viewer may not contain all of these navigational buttons.

Other buttons on the toolbar are:

Hide

Hides the Navigation pane. When the Navigation pane is hidden, click Show to show the Navigation pane. If you close SQL Server Books Online with the Navigation pane hidden, the pane is hidden the next time you open SQL Server Books Online.

Locate

Displays the location of a topic in the Navigation pane.

Font

Changes the font size in the Topics pane.

Print

Prints the selected topic, with the option to print all subtopics.

Navigating SQL Server Books Online

Here are some tips for navigating SQL Server Books Online:

  • To return to the SQL Server Home page, click Home on the toolbar.

  • Colored, underlined text indicates links to other topics. To link to another topic, including Web pages, click the colored, underlined text.

  • Many topics contain lists of related topics, called See Also. To jump to a related topic, click the title of the topic you want to view.

  • If you use a particular topic often, you can add it to your Favorites list. For more information, see Finding a Topic.

  • For shortcut menu commands, right-click the Contents tab or Topic pane. For more information, see Using Accessibility Features in SQL Server Books Online.
Copying and Printing a Topic

To copy or print a topic, use these procedures.

To copy a topic

  1. In the Topic pane, right-click the topic you want to copy, and then click Select All.

  2. Right-click again, and then click Copy. This copies the topic to the Clipboard.

  3. Open the document to which you want to copy the topic.

  4. Position your cursor where you want the information to appear.

  5. On the Edit menu, click Paste.

Note If you want to copy only part of a topic, select the text you want to copy, right-click, and then click Copy.

To print a topic

There are several ways to print a topic:

  • Right-click the Topic pane, and then click Print.

  • Click the Print icon on the toolbar.

  • On the File menu, click Print.

  • On the Contents tab in the Navigation pane, right-click the topic name, and then click Print.

SQL Server Books Online displays two dialog boxes for printing:

  • If you are using the Contents tab in the Navigation pane, and the Navigation pane is the active pane, SQL Server Books Online displays the Print Topics dialog box. If you are using Microsoft Internet Explorer version 5.5, do not click Print the Selected headings and all subtopics, as the subtopics may not print.

  • In all other cases, SQL Server Books Online displays the Print dialog box. If you are using Internet Explorer version 5.5 or Internet Explorer 5 and you click Print all linked topics in the Options tab, linked topics may not always print.
Using the Shortcut Menu Commands

This table shows the shortcut menu commands you can use to display and customize information.

Command | Description
Right-click in the table of contents, and then click Close All. | Closes all books or folders. This command only works if the Contents tab is displayed.
Right-click, and then click Print. | Prints the topic.

These commands can be accessed using the keyboard. Press SHIFT+F10 to display the shortcut menu, and then click the appropriate shortcut keys. Or, enable MouseKeys. Use a MouseKey combination to display the shortcut menu, and then click the appropriate shortcut keys.


Open Data Services (Level 3)

The Open Data Services gateway functions, macros, and events listed in the table are no longer supported.

Function/macro name
srv_ackattention
srv_config
srv_config_alloc
srv_errhandle
srv_event
srv_eventdata
srv_getconfig
srv_handle
srv_init
srv_langcpy
srv_langlen
srv_langptr
srv_log
srv_post_handle
srv_pre_handle
srv_run
srv_setevent
srv_terminatethread


DBCC (Level 3)
SQL Server 6.x | SQL Server 2000
DBCC NEWALLOC checked data and index pages against corresponding extent structures. | DBCC NEWALLOC is supported for backward compatibility only and is identical to DBCC CHECKALLOC. Consider removing all references of DBCC NEWALLOC and replacing with references to DBCC CHECKALLOC.
DBCC ROWLOCK dynamically enabled Insert Row Locking (IRL) operation on tables. | Row-level locking is automatic. DBCC ROWLOCK available for backward compatibility only. Consider removing all references of DBCC ROWLOCK.
DBCC TEXTALL selected tables in the database that had text or image columns and ran DBCC TEXTALLOC on them. | DBCC CHECKDB checks the consistency of text, ntext, and image columns in a database. DBCC TEXTALL is available for backward compatibility only. Consider removing all references of DBCC TEXTALL and replacing with references to DBCC CHECKDB.
DBCC TEXTALLOC checked the allocation of text or image columns for a table. | DBCC CHECKTABLE checks the integrity of the data, index, text, ntext, and image pages for the specified table. DBCC TEXTALLOC is available for backward compatibility only. Consider removing all references of DBCC TEXTALLOC and replacing with references to DBCC CHECKTABLE.
DBCC DBREPAIR dropped the specified, and usually damaged, database. | Use DROP DATABASE to drop or remove a SQL Server database. DBCC DBREPAIR is available for backward compatibility only. Consider removing all references of DBCC DBREPAIR and replacing with references to DROP DATABASE.


Triggers and System Stored Procedures (System) (Level 4)
SQL Server 6.x | SQL Server 2000
Returned values were not always correct for text or image columns in either the inserted or deleted tables when either table was used in a CREATE TRIGGER statement. | NULL values are returned for text or image column references in the inserted or deleted tables in CREATE TRIGGER. Expect different results as compared to earlier versions of SQL Server. Remove all references to either the text or image columns of the inserted or deleted tables when used in CREATE TRIGGER statements.
Direct recursion of triggers (the ability of a trigger to call itself) was not supported, but indirect recursion was allowed. | Direct trigger recursion is enabled with the RECURSIVE_TRIGGERS option of ALTER DATABASE. Indirect recursion is enabled with the nested triggers configuration option. Expect different results as compared to earlier versions of SQL Server.
Server-to-server communication existed between version 4.x and version 6.x servers when initialized by either side. | Version 4.x or 6.x servers can communicate with SQL Server 2000 servers. However, server-to-server communication is not supported from SQL Server 2000 servers to 4.x servers. Expect different results as compared to earlier versions of SQL Server. Upgrade the 4.x server to either SQL Server 6.x or SQL Server 2000
sp_tableoption set option values for user-defined tables, including the use of Insert Row Locking (IRL). | The Insert Row Locking (IRL) parameters in sp_tableoption are not supported but have been replaced with complete row-level locking. Expect different results as compared to earlier versions of SQL Server. Remove all references to IRL actions implemented using sp_tableoption and use the built-in row-level locking of SQL Server 2000 instead. Applications calling sp_tableoption should continue to work properly; the IRL parameters will be ignored.
The @message parameter of xp_readmail was varchar(255). The @message and @query parameters of xp_sendmail were varchar(255). | The @message and @query parameters are now varchar(8000). Expect differences in behavior as compared to earlier versions of SQL Server when using the @message parameter of xp_readmail and the @message and @query parameters of xp_sendmail.


Utilities (Level 4)
SQL Server 6.x | SQL Server 2000
isql/w used DB-Library. The SQL-92 settings, like ANSI_WARNINGS, were set off, by default. | SQL Query Analyzer uses the SQL Server ODBC driver, which, by default, sets these SQL-92 options on: SET ANSI_WARNINGS, SET ANSI_PADDING, and SET ANSI_NULLS. Any errors returned are formatted as ODBC errors rather than DB-Library errors. Expect different results as compared to earlier versions of Microsoft® SQL Server™. Expect different results with SQL Query Analyzer, compared to the isql utility or the SQL Server 6.5 version of isql/w.
isql/w used the ANSI-ISO code pages. When connected to a server using OEM code page 850 or 437, ANSI to OEM character translation had to be explicitly enabled. Otherwise, data with extended characters appeared garbled. | The SQL Server 2000 ODBC driver automatically detects the need for and sets up automatic ANSI to OEM conversion. In addition, when SQL Query Analyzer connects, automatic detection is enabled. Expect a change in behavior when using SQL Query Analyzer with international or extended characters.

For additional information about changes to SQL Query Analyzer, see the discussion "Default Connection Option Settings in SQL Query Analyzer" in SQL Server 2000 and SQL Server version 7.0.


Configuration (Level 4)

Administration scripts may have used these configuration options. For more information about configuration options, see sp_configure and Setting Configuration Options.

SQL Server 6.x | SQL Server 2000
Administration scripts may have used the nonadvanced media retention option to set the number of days to retain each backup medium after it is used for a database or transaction log dump. | media retention is now an advanced option. Expect different results as compared to earlier versions of Microsoft® SQL Server™. Expect the media retention configuration option to appear only if you have enabled the advanced configuration options of sp_configure.


DATEPART and SET DATEFIRST (Level 4)
SQL Server 6.x SQL Server 2000
The SET DATEFIRST setting of the DATEPART function had no effect on the week datepart. The week datepart may give values different from earlier versions of Microsoft® SQL Server™. However, any difference will appear only if the SET DATEFIRST setting is not the default (the U.S. English default is 7).

If the year provided in the DATEPART function has 366 days, a week value of 54 can be returned if the first week of the year starts on a Saturday, and the year ends on the same day of the week with the first day of the week counted from Sunday.

When using the ISO 8601 standard, week values are always from 1 through 53, as the first week of the year is guaranteed to have a minimum of 4 days.

Expect different results as compared to earlier versions of SQL Server. Use the default value for SET DATEFIRST so that DATEPART returns the expected results for the week datepart. Otherwise, DATEPART values will be one less than expected.


Rebuilding the master Database (Level 4)
SQL Server 6.x | SQL Server 2000
Executing SQL Server Setup rebuilt the master database. | No longer supported. SQL Server includes the Rebuild Master (rebuildm) utility. Use the Rebuild Master (rebuildm) Utility located in the x:\Program Files\Microsoft SQL Server\80\Tools\Binn folder to rebuild the master database.


System Stored Procedures (Extended) (Level 3)
SQL Server 6.x | SQL Server 2000
xp_grantlogin and xp_revokelogin granted or revoked SQL Server access to a Windows NT-based group or user. | Use sp_grantlogin and sp_revokelogin even though xp_grantlogin and xp_revokelogin are supported for backward compatibility only. Consider removing all references of xp_grantlogin and xp_revokelogin and replacing with references to sp_grantlogin and sp_revokelogin, respectively.


Security (Level 4)
SQL Server 6.x | SQL Server 2000
The SYSTEM_USER niladic function returned nulls for any Microsoft Windows NT® login. | The appropriate domain and login names are returned if Windows Authentication is used with the SYSTEM_USER function. Expect a different result, as compared to earlier versions, when using SYSTEM_USER with Windows Authentication.


Database Options (Level 3)
SQL Server 6.x | SQL Server 2000
The publish option of sp_dboption enabled or disabled publishing in a database. | sp_replicationdboption should be used to enable or disable publishing in a database. Remove all references of sp_dboption publish and replace with references to sp_replicationdboption.


Query Performance (Level 3)
SQL Server 6.x | SQL Server 2000
Queries could include a server user ID (SUID) without performance implications, as shown in the following table. | Queries using SUIDs continue to run and produce the same results as in earlier versions of SQL Server. However, there is a severe performance penalty because SUIDs are no longer native to the new security design. Consider removing all references to SUIDs and replacing with references to security identification numbers (SIDs) (as shown in the following table) to avoid degradation in query performance.

SQL Server 6.x SUID | Replace with SQL Server 2000 SID
SUSER_ID | SUSER_SID, which returns a SID
SUSER_NAME | SUSER_SNAME, which accepts a SID as input
syslogins.suid | syslogins .sid
sysdatabases.suid | sysdatabases .sid
sysremotelogins.suid | sysremotelogins .sid
sysusers.suid | sysusers .sid
sysalternates.suid | sysusers .isaliased
sysalternates.altsuid | sysusers .isaliased

Examples

A. Use SIDs and SUIDs to display login names of users in sysusers

This example shows SQL Server 6.x queries that displayed the login names of all users in sysusers:

SELECT L.name
FROM master.dbo.syslogins L, sysusers U
WHERE L.suid = U.suid
-- Or
SELECT suser_name(suid) AS name
FROM sysusers

Here are the queries rewritten to use SIDs rather than SUIDs:

SELECT L.loginname
FROM master.dbo.syslogins L, sysusers U
WHERE L.sid = U.sid
-- Or
SELECT suser_sname(sid) AS name
FROM sysusers


SELECT (Level 3)
SQL Server 6.x | SQL Server 2000
The FASTFIRSTROW optimizer hint caused the optimizer to use the nonclustered index if one matches the ORDER BY clause. | The OPTION (FAST n) query hint replaces FASTFIRSTROW. However, FASTFIRSTROW is maintained for backward compatibility only. Consider removing all references to FASTFIRSTROW in SELECT statements and replacing with references to OPTION (FAST n).
The INDEX = syntax specified one or more indexes to use for a table hint. | Supported for backward compatibility only. Consider removing all references to INDEX = and replacing (when using multiple index hints) with references to INDEX(index, index...) as shown in SELECT.


UPDATE (Level 4)
SQL Server 6.x SQL Server 2000
In Microsoft® SQL Server™ version 6.0, the following UPDATE statement, using two different table aliases for the same base table, was allowed:
CREATE TABLE t1 (c1 int)
GO
INSERT t1 VALUES (1)
INSERT t1 VALUES (2)
GO
UPDATE t1
SET c1 = 50
FROM t1 a1, t1 a2
WHERE a1.c1 = 1 AND
a2.c1 = 2
GO
Syntax no longer supported. Use the alias, rather than the table name, after the UPDATE keyword. The UPDATE statement would be rewritten to:
UPDATE a1
SET c1 = 50
FROM t1 a1, t1 a2
WHERE a1.c1 = 1 AND
a2.c1 = 2

Expect differences in behavior as compared to SQL Server version 6.0.
This UPDATE statement with table and alias references worked.
USE pubs
GO
UPDATE titles
SET t.ytd_sales = t.ytd_sales + s.qty
FROM titles t, sales s
WHERE t.title_id = s.title_id
AND s.ord_date =
(SELECT MAX(sales.ord_date) FROM sales)
GO
The alias specified after the UPDATE keyword must match the alias specified following the SET keyword. Without this change, the compatibility level setting must be changed to 65 for this UPDATE statement to function as it did in version 6.x.

Here is the same UPDATE statement rewritten:

USE pubs
GO
UPDATE t
    SET t.ytd_sales = t.ytd_sales + s.qty
        FROM titles t, sales s
           WHERE t.title_id = s.title_id
            AND s.ord_date = (SELECT MAX(sales.ord_date) FROM sales)
GO

Expect differences in behavior as compared to SQL Server version 6.x when using different table references following the UPDATE keyword of the UPDATE statement and the SET keyword of the UPDATE statement.


ODBC (Level 4)
SQL Server 6.x | SQL Server 2000
In the version 2.65 ODBC driver, the long-running query interval, specified by calling SQLSetConnectOption with the driver-specific connection option SQL_COPT_SS_PERF_QUERY_INTERVAL, was specified in seconds. | The SQL_COPT_SS_PERF_QUERY_INTERVAL value is specified in milliseconds. Expect different results as compared to earlier versions of Microsoft® SQL Server™. Multiply the value of SQL_COPT_SS_PERF_QUERY_INTERVAL by 1,000 to convert the number of seconds to milliseconds. For more information about SQL_COPT_SS_PERF_QUERY_INTERVAL, see SQLSetConnectAttr.
For earlier versions of the ODBC SQL Server driver, messages from consecutive PRINT, RAISERROR, DBCC, or similar statements (in a batch or stored procedure) were combined into a single result set. | For the ODBC SQL Server 3.51-compliant driver (included with SQL Server 2000), messages from consecutive PRINT, RAISERROR, DBCC, or similar statements (in a batch or stored procedure) are returned in a separate result set for each statement. Expect different results as compared to earlier versions of SQL Server. Call SQLMoreResults to process the result set from each statement.
Earlier versions of the ODBC SQL Server driver returned SQL_SUCCESS when executing a searched UPDATE or DELETE statement that affects no rows (using SQLExecute, SQLExecDirect, or SQLParamData). SQLRowCount returned zero. | When an ODBC version 3.x application uses the ODBC SQL Server 3.5 driver included with this release, it returns SQL_NO_DATA when executing a searched UPDATE or DELETE statement that affects no rows (using SQLExecute, SQLExecDirect, or SQLParamData). SQLRowCount still returns zero. Expect different results as compared to earlier versions of SQL Server. Handle SQL_NO_DATA appropriately.


Data Types (Level 4)
SQL Server 6.x SQL Server 2000
The decimal and numeric data types could use anywhere from 2 through 17 bytes to store a value, depending on the precision of the stored value. numeric and decimal now use 5, 9, 13, or 17 bytes of storage.

Expect different results as compared to earlier versions of Microsoft® SQL Server™. Be sure that databases using the numeric or decimal data types have sufficient storage for the change in storage bytes.
Results that were too small to display, called floating point underflow, returned inconsistent results for some mathematical operators and functions. SQL Server now returns 0.0 and no error message for all instances of floating point underflow.

Because of the fixed size of floating point numbers like the float and real data types, approximate numeric data have intrinsic precision and ranges of values. In cases of floating point underflow, a result of 0.0 will be returned and no error message will be displayed. For example, the mathematical calculation of 2 to the -100.0 power would have a result 0.0.

Expect different results as compared to earlier versions of SQL Server. Expect different results with floating point underflow with the mathematical functions or operators. For more information, see Using Mathematical Functions.

+ (Add)
- (Subtract)
* (Multiply)
/ (Divide)
ATN2
AVG
CONVERT
EXP
POWER
RADIANS
SUM
A negative second parameter equal to the number of digits in the ROUND expression returned a value of 0 for integer, float, and money data types. When the second parameter was negative and less than the number of digits in the ROUND expression, ROUND returned a value that rounded the right-most digit down to 0. When the second parameter in the ROUND function is a negative value (for all numeric data types) that is less than the number of digits in the expression, SQL Server returns a value that is rounded up to the next digit position.

Expect different results with the ROUND function, compared to earlier versions of SQL Server, when the second parameter is negative.
The DATEADD and DATEDIFF functions returned a date value when adding or subtracting date values. Direct date value addition and subtraction operations are supported for datetime and smalldatetime using the +(Add) and -(Subtract) operators.

For simple date arithmetic, you can also use addition ( + (Add) ) or subtraction ( - (Subtract)) instead of DATEADD and DATEDIFF.


Replication (Level 4)
SQL Server 6.x | SQL Server 2000
Subscriptions to one or more articles in a publication were created either through SQL Server Enterprise Manager or through the appropriate system stored procedures. | SQL Server Enterprise Manager no longer allows subscription to one or more articles. Subscribing to one or more articles of a publication can be done only by using the appropriate replication system stored procedures. Expect different results as compared to earlier versions of SQL Server. Use the replication system stored procedures to subscribe to one or more articles of a publication. When using SQL Server Enterprise Manager, it is necessary to subscribe to the entire publication.

Replication functions differently between SQL Server 2000 and SQL Server version 6.5 servers. In addition, SQL Server 2000 offers enhanced scripting ability after your replication topology is created in the user interface. This enhanced scripting allows mass implementation of replication topology with a minimum of time and effort.


Rebuilding the Registry (Level 4)

Note In Microsoft® SQL Server™ 2000, this utility is replaced by the setup option, Registry Rebuild.

Pre-SQL Server 7.0 SQL Server 7.0
Executing this SQL Server Setup statement rebuilt the registry:
setup/t RegistryRebuild = On.
No longer supported. Instead, use Setup to rebuild the registry.


Functions (Level 4)
SQL Server 6.x | SQL Server 2000
The @@DBTS global variable was incremented any time any page in the database was modified in any way. | The value returned by the @@DBTS function changes only if a row containing a timestamp column is modified. Expect different results as compared to earlier versions of Microsoft® SQL Server™ when using @@DBTS.


CREATE PROCEDURE (Level 4)
SQL Server 6.x | SQL Server 2000
CREATE PROCEDURE statements failed if they contained a CREATE TABLE or SELECT INTO statement creating a temporary table with the same name as a temporary table that existed at the time the CREATE PROCEDURE statement was executed. | The CREATE PROCEDURE statement succeeds. Recode any logic that depended on the earlier behavior.


Security (Level 3)
SQL Server 6.x | SQL Server 2000
The ON {table | view} (column [,...n]) syntax for the GRANT statement assigned the specified permissions to the columns given for the specified table or view. | The ON {table | view} (column [,...n]) syntax for the GRANT statement is supported for backward compatibility only. Consider using the SQL-92 standard GRANT syntax for object permissions and placing the column list before the ON clause.
The term integrated security allowed a SQL Server to use Windows NT Authentication mechanisms to validate logins for all connections. Standard security used SQL Server's own login validation process for all connections. Mixed security allowed login requests to be validated using either integrated or standard security. | The terms Windows Authentication and Mixed Mode replace integrated security and mixed security, respectively. Standard security no longer exists. Consider using the terms Windows Authentication and Mixed Mode rather than integrated security and mixed security. Do not refer to standard security. For more information about security modes, see Authentication.
The SETUSER statement allowed a database owner to impersonate another user. | SETUSER is included in Microsoft® SQL Server™ 2000 for backward compatibility only, and is not recommended. This statement may no longer be supported in a future release of SQL Server. Consider removing all references to SETUSER.


Backup and Restore (Level 4)
SQL Server 6.x | SQL Server 2000
The LOAD HEADERONLY statement retrieved a result set detailing the header information from a database dump. | The result set has changed. Expect a different result set from RESTORE HEADERONLY, compared to LOAD HEADERONLY in earlier versions of SQL Server. For more information about RESTORE HEADERONLY, see RESTORE HEADERONLY.


SELECT (Level 4)
SQL Server 6.x | SQL Server 2000
The left outer join (*=) and right outer join (=*) operators were used in SELECT statements to produce left and right outer joins, respectively. | The SQL-92-standard syntax of LEFT OUTER JOIN and RIGHT OUTER JOIN is preferred. However, join operators supported in earlier versions of Microsoft® SQL Server™ are supported. It is recommended that you remove all references of the left outer join (*=) and right outer join (=*) operators in all SELECT statement FROM clauses and replace with references to the SQL-92-standard syntax RIGHT OUTER JOIN and LEFT OUTER JOIN. Future versions of SQL Server will support only the SQL-92-standard syntax.


Devices (Level 3)

The database architecture of Microsoft® SQL Server™ 2000 differs from the database architecture of SQL Server 6.x. In SQL Server 2000:

  • Operating system files replace database devices.

  • Data files and transaction logs cannot co-exist on the same operating system file.

  • A single operating system file cannot be shared by multiple databases.

For more information about database architecture, see Overview of SQL Server Architecture.

SQL Server 6.x SQL Server 2000
DISK INIT created database or transaction log devices. When DISK INIT followed either a CREATE DATABASE or ALTER DATABASE statement, SQL Server used the specified devices for storing the specified database or transaction log. The CREATE DATABASE statement syntax and ALTER DATABASE statement syntax both allow the creation of separate data and log files. Both CREATE DATABASE and ALTER DATABASE create operating system files and databases in a single step (generating a log file automatically, if none is specified with the LOG ON clause).

Consider removing all references to DISK INIT and replacing with references to either CREATE DATABASE or ALTER DATABASE.

DISK INIT has limited support in SQL Server 2000. Existing scripts will run as long as they do not have data and log sharing of the same data files.
DISK REINIT restored device entries to appropriate system tables when the device entry was missing from sysdevices. Removed; no replacement.

Consider removing all references to DISK REINIT.
sp_logdevice put syslogs (contains the transaction log) on a separate database device. To add another log segment to a database with an existing log segment, it was necessary to execute DISK INIT followed by sp_logdevice. Removed. The CREATE DATABASE statement creates a log file on a new operating system file.

Consider removing all references to sp_logdevice and replacing with references to CREATE DATABASE. SQL Server 6.x scripts using the LOG ON clause of CREATE DATABASE will work as expected. Scripts without the LOG ON clause of CREATE DATABASE will have a log file generated automatically.
Devices created using DISK INIT and CREATE DATABASE could be dropped only by using sp_dropdevice. Databases created without DISK INIT before CREATE DATABASE can be dropped with DROP DATABASE; otherwise, use sp_dropdevice.

Use sp_dropdevice when using DISK INIT, followed by CREATE DATABASE.

Examples
A. Use both DISK INIT and CREATE DATABASE syntax

This example uses DISK INIT and CREATE DATABASE and works in SQL Server version 6.5 and SQL Server 2000:

DISK INIT name = 'testdb_data',
   physname = 'c:\testdb_data.dat',
   vdevno = 9,
   size = 10240
DISK INIT name = 'testdb_log',
   physname = 'c:\testdb_log.dat',
   vdevno = 8,
   size = 10240
CREATE DATABASE testdb
   ON testdb_data = 10
   LOG ON  testdb_log = 10
GO
B. Use of sp_logdevice and CREATE DATABASE in SQL Server 2000 fails

In earlier versions of SQL Server, this script created a 20 MB database consisting of the two files named testdb_data and testdb_log. This script also moved the transaction log to the testdb_log device by using sp_logdevice.

Note Scripts like this one were usually generated by the SQL Server 6.5 sp_help_revdatabase system stored procedure, which used sp_logdevice to ensure the proper device layout for database restores. Because SQL Server 2000 creates the database when it is restored, scripts such as these are no longer necessary.

-- SQL Server 6.x example.
DISK INIT name = 'testdb_data',
   physname = 'c:\testdb_data.dat',
   vdevno = 9,
   size = 10240
DISK INIT name = 'testdb_log',
   physname = 'c:\testdb_log.dat',
   vdevno = 8,
   size = 10240
CREATE DATABASE testdb on testdb_data = 10, testdb_log = 10
-- Use sp_logdevice to move the log to the testdb_log device.
EXEC sp_logdevice testdb, testdb_log

In SQL Server 2000, the above script does not work the same as in SQL Server 6.x because sp_logdevice no longer exists.

In SQL Server 2000, this script creates a 20 MB database consisting of the two files named testdb_data and testdb_log. In addition, SQL Server generates a log file automatically, which is 25 percent of the database size. In the following script (using the devices created earlier), a 10 MB log file is generated automatically:

CREATE DATABASE testdb on testdb_data = 10, testdb_log = 10
C. Use CREATE DATABASE syntax only

Using the SQL Server 2000 CREATE DATABASE syntax, the database from the earlier example could be created as follows:

CREATE DATABASE testdb ON (name = 'testdb_data',
   filename = 'd:\testdb_data.dat', size = 10)
   LOG ON (name = 'testdb_log', filename = 'd:\testdb_log.dat',
   size = 10)


SET SHOWPLAN (Level 3)
SQL Server 6.x | SQL Server 2000
The SET SHOWPLAN statement returned output as informational messages through SQLGetDiagRec in ODBC, or through the message handler in DB-Library applications. | The SET SHOWPLAN statement is no longer supported. It has been replaced by SET SHOWPLAN_TEXT and SET SHOWPLAN_ALL. The output of SET SHOWPLAN_TEXT and SET SHOWPLAN_ALL is returned not as informational messages, but as a result set. Consider removing all references of SET SHOWPLAN and replacing with references to either SET SHOWPLAN_TEXT (to display readable text) or SET SHOWPLAN_ALL (to display output that can be parsed more easily by an application building a report of showplan output). The application needs to process the output as part of the result set, not as messages returned through the ODBC SQLGetDiagRec function or the DB-Library message handler.


Backup and Restore (Level 3)
SQL Server 6.x | SQL Server 2000
The DUMP statement created database or transaction log backups (dumps). | The DUMP DATABASE and DUMP TRANSACTION statements are synonymous with BACKUP DATABASE and BACKUP LOG statements. Support for the DUMP DATABASE and DUMP TRANSACTION statements may be removed in a future release. Consider removing all references of DUMP DATABASE and replacing with references to BACKUP DATABASE. Consider removing all references of DUMP TRANSACTION and replacing with references to BACKUP LOG.
The LOAD statement restored or loaded database or transaction log backups (dumps). | The LOAD DATABASE and LOAD TRANSACTION statements are synonymous with the RESTORE DATABASE and RESTORE LOG statements. Support for the LOAD DATABASE and LOAD TRANSACTION statements may be removed in a future release. Consider removing all references of LOAD DATABASE and replacing with references to RESTORE DATABASE. Consider removing all references of LOAD TRANSACTION and replacing with references to RESTORE LOG. For more information about RESTORE DATABASE, see RESTORE.
The CREATE DATABASE ...FOR LOAD statement syntax created a destination database before its restoration from a database backup and prevented anyone from using the database between the CREATE DATABASE, ALTER DATABASE, and LOAD statements. | The CREATE DATABASE ...FOR LOAD syntax is supported for backward compatibility only. However, because SQL Server now creates the destination database within a restore operation, it is recommended that the destination database not be created before executing the restore operation. Do not create the database prior to restoring it.


DELETE and SELECT (Level 4)
SQL Server 6.x SQL Server 2000
Duplicate table names in the FROM clause of Microsoft® SQL Server™ version 6.0 DELETE or SELECT statement caused SQL Server to treat both table references as the same table. SQL Server discarded the reference to the second authors table in this SELECT example:
USE pubs
GO
SELECT *
FROM authors, authors
GO

However, if the table names specified in the FROM clause of the DELETE or SELECT were not identical, SQL Server version 6.0 treated the two table references as two different tables as in this SELECT example:

USE pubs
GO
SELECT *
FROM pubs..authors, pubs.dbo.authors
GO
 Duplicate table names in the FROM clause of a DELETE or SELECT statement generate errors in SQL Server. Rewrite statements using aliases. Here is a SELECT example:
SELECT *
FROM pubs..authors AS a1, pubs.dbo.authors AS a2

USE pubs
SELECT *
FROM authors AS au1, authors AS au2

Expect different results as compared to SQL Server version 6.0. Rewrite DELETE and SELECT statements to use aliases in the FROM clause when referring to more than one instance of the same table.


Devices (Level 4)
SQL Server 6.x | SQL Server 2000
The DISK RESIZE statement altered the size of a database device. | The DISK RESIZE statement is supported, but may not be supported in future releases. In addition, the DISK RESIZE statement does not alter the size of the database. Instead, use ALTER DATABASE. Expect different results as compared to earlier versions of Microsoft® SQL Server™. Use the MODIFY FILE clause of the ALTER DATABASE statement to alter the size of a database.


System Stored Procedures (System) (Level 3)
SQL Server 6.x | SQL Server 2000
Job management was called task management, and several system stored procedures allowed system administrators to create and manage tasks. | The task management system stored procedures are no longer documented and are included for backward compatibility only. Even though Microsoft® SQL Server™ 2000 supports the task management system stored procedures (sp_addtask, sp_droptask, sp_helptask, sp_reassigntask, and sp_updatetask) for scheduling and managing SQL Server jobs, consider using either SQL Server Enterprise Manager or the job-related system stored procedures listed in the following table for managing jobs.

The task-related stored procedures listed in the SQL Server 6.x column below have been replaced by the corresponding job-related stored procedures shown in the SQL Server 2000 column.

SQL Server 6.x | SQL Server 2000
sp_addtask | sp_add_job sp_add_jobstep sp_add_jobschedule sp_start_job
sp_droptask | sp_delete_job sp_delete_jobstep sp_delete_jobschedule
sp_helptask | sp_help_jobhistory sp_help_jobschedule sp_help_jobstep
sp_reassigntask | sp_purge_jobhistory sp_stop_job
sp_updatetask | sp_update_job sp_update_jobstep sp_update_jobschedule


DBCC (Level 4)
SQL Server 6.x | SQL Server 2000
Each DBCC statement had a certain output format. | The output formats of many DBCC statements have changed. Expect different results as compared to earlier versions of Microsoft® SQL Server™.
The DBCC PERFMON and DBCC SQLPERF statements documented SQL Server performance statistics used for studying SQL Server performance. | No longer documented. These statements may change in a future release of SQL Server. Use the Windows 2000 System Monitor Windows NT 4.0 Performance Monitor to monitor the performance counters for SQL Server. For more information, see Monitoring with Windows Performance Monitor.


Aliases (Level 4)
SQL Server 6.x | SQL Server 2000
An alias allowed a user to temporarily assume the identity of another user within a database and perform actions as the aliased user. For example, the database owner could be aliased to a user so they could act as that user, if the user were on vacation. | Roles have replaced aliases. Because a user can belong to more than one role at a time, it is no longer necessary to assume the identity of another. Users belonging to the same roles have the same permissions automatically, assuming permissions are only applied at the role level, not the user level. Expect different results as compared to earlier versions of SQL Server. Use roles instead of aliases. For more information about database roles, see Managing Permissions.


DBCS String Comparisons (Level 4)
SQL Server 6.x | SQL Server 2000
When comparing DBCS space characters, the Unicode A140 space character (U-A140) was not equal to the Unicode 0020 (U-0020) space character. | Comparisons involving the Unicode A140 space character (U-A140) are now equivalent to the Unicode 0020 (U-0020) space character. Expect different results as compared to earlier versions of SQL Server when comparing DBCS space characters.


Global Variables (Level 4)
Pre-SQL Server 7.0 | SQL Server 7.0
Global variables were system-supplied, predeclared variables that were distinguished from local variables by having two at symbols (@@) preceding their names. | Transact-SQL global variables are a form of function and are now referred to as functions. For more information, see Functions.


DB-Library (Level 1)
SQL Server 6.x | SQL Server 2000
DB-Library's two-phase commit special library managed transactions distributed across two or more servers. | The DB-Library two-phase commit is no longer supported. Use Microsoft Distributed Transaction Coordinator (MS DTC) to accomplish simultaneous updates on two servers. Remove all references to DB-Library's two-phase commit.
DB-Library applications could be developed in Microsoft® Visual Basic®. | The development libraries for DB-Library for Visual Basic are not supplied. Existing DB-Library for Visual Basic applications will run against SQL Server 2000, but must be maintained using the development libraries for SQL Server 6.5. All new Visual Basic applications written to access SQL Server should use the Visual Basic data APIs such as ActiveX Data Objects (ADO) and Remote Data Objects (RDO).


SET SHOWPLAN (Level 1)
SQL Server 6.x | SQL Server 2000
SET SHOWPLAN generated a description of the processing plan for the query and processed it immediately unless the SET NOEXEC setting was enabled. | SET SHOWPLAN has been replaced with SET SHOWPLAN_ALL and SET SHOWPLAN_TEXT. The SET SHOWPLAN_ALL and SET SHOWPLAN_TEXT statements return only query or statement execution plan information and do not execute the query or statement. To execute the query or statement, turn the appropriate showplan statement OFF. The query or statement will then execute. Remove all references to either SET SHOWPLAN ON or SET SHOWPLAN OFF and replace with references to either SET SHOWPLAN_ALL ON, SET SHOWPLAN_TEXT ON, SET SHOWPLAN_ALL OFF, or SET SHOWPLAN_TEXT OFF. Expect differences in behavior as compared to earlier versions of SQL Server.


Bulk Copy (Level 2)
SQL Server 6.x SQL Server 2000
The bcp utility (using DB-Library) could import datetime or smalldatetime values in character-mode data files using:
  • The default format used by DB-Library (mmm dd yyy hh:mmXX where XX is either A.M. or P.M.).

  • Any format supported by dbconvert except the ODBC format.

bcp exported character-mode data files with datetime and smalldatetime values by using the default DB-Library format.

 The bcp utility (which uses ODBC) can import datetime and smalldatetime values in character-mode data files using:
  • The default format used by DB-Library.

  • The format used by ODBC (yyyy-mm-dd hh:mm:ss[.f...]).

However, bcp does not use other formats supported by dbconvert.

bcp exports datetime and smalldatetime values using the ODBC default format.

Expect different results as compared to earlier versions of SQL Server. To bulk copy data in character mode between SQL Server 6.x and SQL Server 2000 servers, use the same bcp version (either SQL Server 6.x or SQL Server 2000) for both importing and exporting data.

To export data from a SQL Server 2000 server into a character-mode data file and later import that data using a DB-Library bulk copy application, use the SQL Server 6.x version of bcp.

For existing datetime or smalldatetime values in a character-mode data file in a format other than the DB-Library default:

  • Change the values to the DB-Library default format for continued use with SQL Server 6.x and SQL Server 2000 bcp.

  • Change the values to the ODBC format for use with SQL Server 2000 bcp.
bcp exported money values in character mode data files using digit grouping symbols (for example, the comma in the United States when using the U.S. version of SQL Server, the US version of Microsoft Windows NT, and US settings) and two digits after the decimal point. bcp exports money values in character mode data files without digit grouping symbols, but with four digits after the decimal point.

Expect different results as compared to earlier versions of SQL Server.

To read character files created by version 6.x DB-Library bcp in SQL Server 2000, use the -V switch. For more information, see bcp Utility.


Indexes (Level 1)
SQL Server 6.x | SQL Server 2000
The SORTED_DATA_REORG clause of CREATE INDEX eliminated the sort performed when a clustered index was created. | Replaced by the DROP_EXISTING clause of CREATE INDEX. Remove all references to the SORTED_DATA_REORG clause of CREATE INDEX and replace with references to DROP_EXISTING.
The SORTED_DATA clause of CREATE INDEX eliminated the sort performed when a clustered index was created and physically reorganized the data. | Removed; no longer available. Remove all references to the SORTED_DATA clause of CREATE INDEX.
bcp could import an already sorted data file into a SQL Server table. Creating a clustered index on an ordered table could be optimized by using the SORTED_DATA clause of CREATE INDEX. The SORTED_DATA clause forced SQL Server not to sort or reorganize the previously ordered table. | SQL Server returns an error message stating that the SORTED_DATA clause of CREATE INDEX is ignored and no longer supported. Remove all references to the SORTED_DATA clause of CREATE INDEX. Consider creating the clustered index before using bcp to import the data. bcp uses improved index maintenance strategies to make data importation with a preexisting index faster than earlier releases and avoids resorting of data after importation.
The ALLOW_DUP_ROW and IGNORE_DUP_ROW clauses of the CREATE INDEX statement allowed data to be updated into tables with a unique index and without having to filter out duplicates first. | No longer supported. Using either ALLOW_DUP_ROW or IGNORE_DUP_ROW in the CREATE INDEX statement generates a warning message. If there is no unique clustered index and there is a need to avoid duplicate rows, create a unique constraint on one or more columns other than the clustering key.


Backup and Restore (Level 1)

Because backups are not compatible between servers running Microsoft® SQL Server™ 2000 and servers running earlier versions of SQL Server, SQL Server 6.x database dumps (backups) cannot be restored onto a SQL Server 2000 server. For more information about upgrading your databases to SQL Server 2000, see Upgrading Databases from SQL Server 6.5 (Upgrade Wizard).

SQL Server 6.x | SQL Server 2000
The VOLUME clause of the DUMP and LOAD statements indicated the volume ID for a dump device. | The VOLUME keyword has been replaced by the MEDIANAME clause. Use of the VOLUME clause results in an error. Remove all references of the VOLUME keyword in all BACKUP, DUMP, LOAD, or RESTORE statements and replace with references to MEDIANAME.
The DUMP and LOAD statements supported the use of diskettes. | Backing up to diskette is not supported. Back up to hard disk, and then copy the backup file to one or more diskettes.
The sysbackuphistory, sysbackupdetail, sysrestorehistory, and sysrestoredetail system tables tracked DUMP and LOAD history information. | The DUMP and LOAD history tracking system tables have been removed and replaced by a new set of system tables. Remove all references to sysbackuphistory, sysbackupdetail, sysrestorehistory, and sysrestoredetail. Because the structure and contents of the backup system tables have changed significantly, familiarize yourself with these new system tables before referencing them: backupfile, backupmediafamily, backupmediaset, backupset, restorefile, restorefilegroup, and restorehistory.


Disk Mirroring (Level 1)
SQL Server 6.x | SQL Server 2000
DISK MIRROR, DISK REMIRROR, and DISK UNMIRROR performed SQL Server disk mirroring. | No longer supported because SQL Server mirroring is no longer supported. Use Microsoft Windows NT® or hardware-based RAID. For more information, see your Windows NT or hardware documentation.


System Stored Procedures (Replication) (Level 1)
SQL Server 6.x | SQL Server 2000
sp_replica remotely set (on a Subscriber) a sysobjects category bit that marked the table as a replica. | Removed; no longer supported or available. Remove all references to sp_replica.
sp_replsync acknowledged completion of a manual synchronization when used from a Subscriber. | Removed; no longer supported or available. Remove all references to sp_replsync.
sp_helppublicationsync provided information about a scheduled synchronization task for a publication. | No longer supported. An error message is returned if this stored procedure is used. Remove all references to sp_helppublicationsync.
sp_subscribe and sp_unsubscribe remotely added or canceled a subscription to a particular article within a publication, to a whole publication, or to all publications. | No longer supported. An error message is returned if this stored procedure is used. Remove all references to either sp_subscribe or sp_unsubscribe, or use the @@ERROR function to test for errors.
name value parameter of sp_changepublication was used to provide the new publication name. | Removed; no longer supported or available. Remove all references to the name value parameter of sp_changepublication.
sp_addpublisher added a Publisher at the Subscriber and added a Distribution Publisher at the Distributor. | Replaced by sp_adddistpublisher. Remove all references to sp_addpublisher and replace with references to sp_adddistpublisher.
sp_droppublisher dropped a publication server. | Removed; no longer supported or available. Remove all references to sp_droppublisher. To drop a Publisher at a Distributor, use sp_dropdistpublisher.
sp_distcounters was used to query for delivered or undelivered commands as used by Performance Monitor, which no longer uses this procedure. | No longer supported. The new view MSdistribution_status presents much of the same information.
sp_helpreplicationdb was used to return information about a specified database or a list of all publication databases on the server. | Removed; no longer supported. Remove all references to sp_helpreplicationdb and replace with references to sp_helpreplicationdboption.
sp_replstatus updated the internal table structure for replication. | Removed; no longer supported. Remove references to sp_replstatus.


Security (Level 2)

New Information - SQL Server 2000 SP3.

SQL Server 6.x | SQL Server 2000
The GRANT and REVOKE statements granted and revoked permissions, respectively. The REVOKE statement denied a permission to a single user that was granted to the user's group. | The security model uses DENY in addition to GRANT and REVOKE. REVOKE has changed to remove a previously granted or denied permission. DENY creates an entry in the security system that denies a permission from a security account and prevents the user, group, or role from inheriting the permission through its group and role memberships. The REVOKE statement can no longer be used to deny permission to a user whose group has permission. Use the DENY statement to deny permissions explicitly to a specific user or group. Expect different results as compared to earlier versions of SQL Server. Recognize that scripts using the SQL Server 6.x security model using GRANT and REVOKE behave differently than scripts using the current model of GRANT, REVOKE, and DENY if REVOKE was used to deny permissions to selected members of a group.
When executing an RPC, logins using integrated security mode referred to an internal login name with the backslashes (\) translated to underscores (_). For example, \Domain\Joe was translated to Domain_Joe. | Those servers upgraded to SQL Server that execute RPC calls no longer translate backslashes to underscores when using Windows NT Authentication. To use the SQL Server version 6.x naming convention for login names, use sp_addlinkedsrvlogin to map the backslash version of the username to an underscore version. Expect different results as compared to earlier versions of SQL Server. Add references for sp_addlinkedsrvlogin to translate backslash version login names to underscore versions to maintain version 6.x login translations when the sending server of an RPC uses SQL Server 2000.

Examples
A. Map specific backslash login to underscore login

This example maps the \LONDON1\nancyd login name to LONDON1_nancyd:

sp_addlinkedsrvlogin 'receiving_server_name',
   false,
   'LONDON1\nancyd',
   'LONDON1_nancyd', [sapassword]
B. Map specific backslash login to sa login

This example maps Nancy's LONDON1 login to the sa login, because Nancy's domain login is part of the built-in administrators group:

sp_addlinkedsrvlogin 'receiving_server_name',
   false,
   'LONDON1\nancyd',
   'sa', [sapassword]


Database Options (Level 1)

Administrative scripts may have used these database options. In SQL Server 2000, database options should be set with the ALTER DATABASE statement rather than the sp_dboption stored procedure. For more information about database options, see Setting Database Options and ALTER DATABASE.

SQL Server 6.x | SQL Server 2000
The subscribe option of sp_dboption enabled or disabled a database for subscriptions. | Removed; no longer available. Use sp_addsubscription to enable or disable a database for subscriptions.
The no chkpt. on recovery option of sp_dboption defined whether or not a checkpoint record was added to a database recovered during a SQL Server startup. | Removed; no longer available. When using a warm standby server, use the WITH STANDBY clause of the RESTORE statement.


Configuration Options (Level 1)

Administrative scripts may have used these configuration options. For more information about configuration options, see Setting Configuration Options.

SQL Server 6.x | SQL Server 2000
backup buffer size specified the size of the dump and load buffer (used to increase backup speed). | Removed; no longer supported. Remove all references to backup buffer size.
backup threads specified the number of threads to be reserved for striped dump and load operations. | Removed; no longer supported. Remove all references to backup threads.
database size set the default number of megabytes (MB) allocated to each new user database. | Removed; no longer supported. Remove all references to database size.
free buffers determined the threshold of free buffers available to the system. | Removed; no longer supported. Remove all references to free buffers.
hash buckets set the number of buckets used for hashing pages to buffers in memory. | Removed; no longer supported. Remove all references to hash buckets.
LE threshold maximum determined the maximum number of page locks to hold before escalating to a table lock. | Removed; no longer supported. Remove all references to LE threshold maximum.
LE threshold minimum determined the minimum number of page locks required before escalating to a table lock. | Removed; no longer supported. Remove all references to LE threshold minimum.
LE threshold percent specified the percentage of page locks needed on a table before a table lock is requested. | Removed; no longer supported. Remove all references to LE threshold percent.
logwrite sleep specified the number of milliseconds that a write to the log will be delayed if the buffer is not full. | Removed; no longer supported. Remove all references to logwrite sleep.
max lazywrite IO tuned the priority of batched asynchronous I/O operations performed by the lazy writer. | Removed; no longer supported. Remove all references to max lazywrite IO.
memory set the size of available memory, in 2K units. | Removed; no longer supported. Memory is configured automatically based on need and available memory. To control the range of memory configured automatically, use the min server memory and max server memory options. Remove all references to memory.
open databases set the maximum number of databases that can be open at one time on SQL Server. | Removed; no longer supported. Remove all references to open databases.
procedure cache specified the percentage of memory allocated to the procedure cache after the SQL Server memory needs are met. | Removed; no longer supported. Remove all references to procedure cache.
RA cache hit limit specified the number of cache hits that a read-ahead request could have before it was canceled. | Removed; no longer supported. Remove all references to RA cache hit limit.
RA cache miss limit specified the number of cache misses that occurred during a horizontal traversal before read-ahead started for that command. | Removed; no longer supported. Remove all references to RA cache miss limit.
RA delay specified the delay of read-ahead, in milliseconds. | Removed; no longer supported. Remove all references to RA delay.
RA pre-fetches determined how far ahead the read-ahead manager read (on an extent basis) before the pre-fetch manager idled. | Removed; no longer supported. Remove all references to RA pre-fetches.
RA slots per thread specified the number of simultaneous requests each read-ahead service thread managed. | Removed; no longer supported. Remove all references to RA slots per thread.
RA worker threads specified the number of threads used to service read-ahead requests. | Removed; no longer supported. Remove all references to RA worker threads.
recovery flags determined what information SQL Server displayed in the error log during recovery. | Removed; no longer supported. Remove all references to recovery flags.
remote conn timeout specified a time limit to break a server-to-server connection. | Removed; no longer supported. Remove all references to remote conn timeout.
SMP concurrency specified the maximum number of CPUs that would be used by SQL Server. | Removed; no longer supported. Remove all references to SMP concurrency.
sort pages specified the maximum number of pages to be allocated to sorting per user. | Replaced by min memory per query. For more information about the min memory per query option, see Server Memory Options. Replace all references of sort pages with min memory per query and index create memory.
tempdb in ram placed the tempdb database in RAM, if needed. | No longer supported because SQL Server 2000 has been optimized for maximum performance. Remove all references to tempdb in ram.
trace flag 204 supported queries containing sort columns in the ORDER BY clause not included in the select list when the DISTINCT keyword was supplied. | No longer supported. Remove all references to trace flag 204. For more information about supported trace flags, see Trace Flags.
user connections set the maximum number of simultaneous connections to SQL Server allowed. | Now an advanced option. Default value of 0 indicates automatic growth. Remove all references to user connections.

For more information about other changes to configuration options, see SQL Server 2000 and SQL Server version 7.0.


ODBC (Level 2)
SQL Server 6.x SQL Server 2000
SQL_ERROR was returned by SQLExecute, SQLExecDirect, or SQLParamData when extended stored procedures or batches met the following criteria:
  • The first data-returning statement caused an error (either by a run-time error or a RAISERROR statement with severity greater than or equal to 11).

  • There was data from any other statement, even a simple RETURN statement, after the error-causing statement.

Due to the SQL_ERROR return code, the statement handle was available for use immediately.

 SQL_SUCCESS_WITH_INFO is returned when an ODBC 3.x application uses the ODBC SQL Server 3.51-compliant driver included with this release (using SQLExecute, SQLExecDirect, or SQLParamData).

Due to the SQL_SUCCESS_WITH_INFO return code, process the results for that statement handle before it is available for use.

Expect different results as compared to earlier versions of SQL Server. Handle SQL_SUCCESS_WITH_INFO using SQLGetDiagRec, and then call SQLMoreResults to process the remaining results, as appropriate.


Disk Commands (Level 1)
SQL Server 6.x | SQL Server 2000
DISK REINIT and DISK REFIT restored usage information from system tables when a device existed (the file was present) but the entries in sysusages no longer existed. | Removed; no longer supported or available. Remove all references to DISK REINIT. Replace all references of DISK REFIT with references to ALTER DATABASE, which adds and drops filegroups included in a database, and modifies the size of each database filegroup.


Data Types (Level 2)
SQL Server 6.x SQL Server 2000
Conversion of binary or varbinary to decimal or numeric was explicit. This conversion is implicit.

Expect different results as compared to earlier versions of SQL Server. Expect conversions of binary or varbinary to decimal or numeric to be implicit. For more information about data type conversions, see CAST and CONVERT. For more information about system-supplied data types, see Data Types.
Conversion of binary or varbinary to smallmoney was not allowed. This conversion is allowed.

Expect different results as compared to earlier versions of SQL Server. Use as appropriate.
Conversion of datetime or smalldatetime to decimal, numeric, float, real, int, smallint, tinyint, money, smallmoney, or bit was not allowed. This conversion is allowed.

Expect different results as compared to earlier versions of SQL Server. Use as appropriate.
Conversion of float or real to binary or varbinary was not allowed. This conversion is allowed.

Expect different results as compared to earlier versions of SQL Server. Use as appropriate.
Conversion of money or smallmoney to char or varchar was implicit. This conversion is explicit.

Expect different results as compared to earlier versions of SQL Server. Expect conversions of money or smallmoney to char or varchar to be explicit.
Conversion of bit to money or smallmoney was not allowed. This conversion is allowed.

Expect different results as compared to earlier versions of SQL Server. Use as appropriate.
sysname data type was varchar(30). sysname data type is nvarchar(128), which allows for 128 Unicode characters.

Expect different results as compared to earlier versions of SQL Server. Expect any columns or local variables defined as sysname to allow Unicode data. For more information about sysname, see Data Types.

No direct support for the nchar, nvarchar, and ntext Unicode data types because maximum storage was 255 bytes for char, binary, varchar, and varbinary data types. The maximum number of bytes that can be stored in char, binary, varchar, and varbinary data types is increased to 8,000. SQL Server 2000 clients fully support the nchar, nvarchar, and ntext data types. SQL Server 6.x clients accessing SQL Server 2000 with these Unicode data types will experience these results:

nvarchar data is returned as varchar and nchar data is returned as char. nvarchar and nchar values longer than 255 double-byte characters are truncated to 255 single-byte characters.

Attempting to access ntext data causes SQL Server to issue a 4004 error. ntext data cannot be sent to version 6.x clients.

char, varchar, binary, and varbinary values longer than 255 bytes are truncated to 255 bytes.

Expect different results as compared to earlier versions of SQL Server. Expect changes in data when accessing SQL Server 2000 data from version 6.x clients. To eliminate these differences, upgrade the clients to SQL Server 2000 client software.
Using CONVERT to convert an empty string to int (CONVERT(int, '')) or float (CONVERT(float, '')) returned a zero. Using CAST or CONVERT to convert an empty string to int (CAST('' AS int)) or float (CAST('' AS float)) returns an error message.

Expect different results as compared to earlier versions of SQL Server.


INSERT (Level 2)
SQL Server 6.x SQL Server 2000
An INSERT x SELECT INTO Y statement ignored table Y and inserted the SELECT results into table X, as shown.
INSERT X
SELECT select_list INTO Y
 The INSERT...SELECT INTO syntax is retained only when the compatibility setting is equal to 60 or 65. If the compatibility setting is 70 or 80 and a similar query is executed, SQL Server returns a syntax error.

Expect different results as compared to earlier versions of SQL Server. Set the compatibility setting to 60 or 65 by executing sp_dbcmptlevel to retain version 6.x functionality for queries using INSERT ...SELECT INTO syntax. Otherwise, use a compatibility setting of 80.
In an INSERT statement, a SELECT statement returning a scalar value was allowed in the VALUES clause. The INSERT statement cannot have a SELECT statement in the VALUES clause as one of the values to be inserted. The version 6.x supportability is available only when the compatibility setting is equal to 60 or 65.

Expect different results as compared to earlier versions of SQL Server. Set the compatibility setting to 60 or 65 by executing sp_dbcmptlevel to retain version 6.x functionality for using a SELECT statement in the VALUES clause of an INSERT statement. Otherwise, use a compatibility setting of 80.
A ROLLBACK statement in a stored procedure referenced in an INSERT table EXEC procedure statement caused the INSERT to be rolled back, but the batch continued. A ROLLBACK statement in the stored procedure referenced by an INSERT...EXEC statement causes the entire transaction to be rolled back and the batch stops executing. The version 6.x supportability is available only when the compatibility setting is equal to 60 or 65.

Expect different results as compared to earlier versions of SQL Server. Set the compatibility setting to 60 or 65 by executing sp_dbcmptlevel to retain version 6.x functionality for ROLLBACK statement behavior inside an INSERT...EXEC statement. Otherwise, use a compatibility setting of 80.


UPDATETEXT (Level 2)
SQL Server 6.x | SQL Server 2000
UPDATETEXT initialized text columns to NULL, allocating a full 2K page. | If the compatibility level setting of sp_dbcmptlevel is 65, UPDATETEXT initializes text columns to NULL. However, if the compatibility level setting is 70 or 80, WRITETEXT initializes text columns to NULL; UPDATETEXT initializes text columns to an empty string. Expect differences in behavior when initializing text values to NULL (using UPDATETEXT or WRITETEXT) depending on the compatibility level setting of sp_dbcmptlevel.


Database Pages and Extents (Level 2)
SQL Server 6.x | SQL Server 2000
A database extent consisted of eight 2 KB pages. | A database extent consists of eight 8 KB pages. Different objects can now share an extent or an object can have its own extent. A table and index both have a minimum of two pages. Expect different results as compared to earlier versions of SQL Server. Adjust disk space requirements for adequate database storage. For more information, see Pages and Extents.


RIGHT (Level 2)
SQL Server 6.x | SQL Server 2000
RIGHT was a reserved word. | RIGHT is a reserved keyword and should not be used for database object names (unless using identifiers). For more information about SQL Server 2000 reserved keywords, see Using Reserved Keywords. Expect different results as compared to earlier versions of SQL Server because RIGHT is now a reserved keyword. For more information about using RIGHT with identifiers, see Using Identifiers.


Utilities (Level 1)
SQL Server 6.x | SQL Server 2000
The probe login, which required no password, was used by DB-Library and Windows NT Performance Monitor. The DB-Library two-phase commit library used the probe login to check on the status of distributed transactions. It was also used by Windows NT Performance Monitor to get statistics from SQL Server. | The probe login has been eliminated. Windows NT Performance Monitor will always use Windows NT Authentication, known earlier as integrated security, to connect to SQL Server. Ensure that your Windows NT username and password have the appropriate privileges to use Windows NT Performance Monitor.


System Stored Procedures (System) (Level 1)

New Information - SQL Server 2000 SP3.

SQL Server 6.x | SQL Server 2000
Several system stored procedures were used for documenting keys. | Removed; no longer supported or available. Use declarative referential integrity by implementing keys and constraints with either ALTER TABLE or CREATE TABLE. Remove all references to these system stored procedures and replace with references to either sp_help or sp_helpconstraint: sp_commonkey sp_dropkey sp_foreignkey sp_helpjoins sp_helpkey sp_primarykey
sp_placeobject put future space allocations for a table or index on a particular segment. | sp_placeobject is no longer available because segments no longer exist. Use the ON FILEGROUP syntax of the CREATE TABLE statement to place table or index information about a separate filegroup. Remove all references of sp_placeobject and replace with references to the ON FILEGROUP clause of the CREATE TABLE statement.
sp_dbinstall installed a database and its devices, and was used for removable media. | Removed; no longer supported or available. Remove all references to sp_dbinstall and replace with references to sp_attach_db.
sp_makestartup and sp_unmakestartup set a stored procedure for auto execution and discontinued auto execution of the stored procedure, respectively. | Removed; no longer supported or available. Remove all references of either sp_makestartup or sp_unmakestartup and replace with references to sp_procoption.
The sp_helplogins, sp_helprotect, and sp_tableoption system stored procedures supported pattern matching (using wildcard characters), which allowed flexibility in specific parameters. | Pattern matching using the wildcard characters is no longer supported in these system stored procedures because any system stored procedure identifier may contain a pattern matching character. Remove all references to pattern matching in sp_helplogins, sp_helprotect, and sp_tableoption.
The fallback option of sp_serveroption indicated a fallback server. | The fallback option of sp_serveroption is no longer available because the fallback option is no longer supported. Remove all references to the fallback option of sp_serveroption.
sp_setlangalias assigned or changed the alias for an alternate language. | Removed; no longer supported. Use the aliases provided in syslanguages. Remove all references to sp_setlangalias.
sp_droplanguage dropped an alternate language from the server and removed its row from master.dbo.syslogins. | Removed; no longer supported. Remove all references to sp_droplanguage.
Fallback support was provided by executing system stored procedures that shifted control of databases and devices from a broken primary server to a fallback server. | Fallback support is no longer supported using the fallback system stored procedures. Support for fallback servers is supported using Microsoft Windows NT Clustering Service. Remove all references to these fallback system stored procedures: sp_fallback_activate_svr_db, sp_fallback_deactivate_svr_db, sp_fallback_enroll_svr_db, sp_fallback_help, sp_fallback_permanent_svr, sp_fallback_upd_dev_drive, sp_fallback_withdraw_svr_db.
sp_devoption displayed or set device status. | Removed; no longer available. Remove all references to sp_devoption.
sp_diskdefault set a database device status to indicate whether the device can be used for database storage when the user does not specify a database device or specifies DEFAULT with the CREATE DATABASE or ALTER DATABASE statements. | Removed; no longer available. Remove all references to sp_diskdefault.
sp_helplog reported the name of the device that contains the first page of the log in the current database. | Removed; no longer available. Remove all references to sp_helplog.
sp_helpstartup reported a listing of all auto-start stored procedures. | Removed; no longer available. Remove all references to sp_helpstartup and replace with references to sp_procoption.
sp_sqlexec provided a convenient way for SQL Server database clients and servers to send a language statement of any format to an Open Data Services server application. | Removed; no longer available. Remove all references to sp_sqlexec.
sp_help_revdatabase analyzed an existing database and created a script that could be used to replicate the database structure on another server. | Removed; no longer available. If applicable, use the SQL-DMO Script Method of the Database Object to generate similar information. Remove all references to sp_help_revdatabase.
sp_addlanguage added an alternate language to a server. | Removed; no longer available. Remove all references to sp_addlanguage.


Services (Level 1)
SQL Server 6.x | SQL Server 2000
SQL Executive provided the SQL Server scheduling engine. SQL Executive offered extensive and varied task scheduling and alerting abilities, and was capable of handling large client/server environments. | SQL Executive tasks are now performed by SQL Server Agent. Use SQL Server Agent for scheduling purposes. For more information, see Configuring the SQL Server Agent Service.


Custom Sort Orders (Level 1)
SQL Server 6.x | SQL Server 2000
Custom sort orders were installed from definition files (usually with an .srt file extension). | Removed; no longer available or supported. Remove all references to custom sort orders. During installation of SQL Server 2000, select an appropriate sort order. For more information, see Windows Collation Sorting Styles.


SET SHOWPLAN (Level 2)
SQL Server 6.x | SQL Server 2000
When SET SHOWPLAN was set ON, SQL Server executed Transact-SQL statements. | When set ON, the SET SHOWPLAN_ALL and SET SHOWPLAN_TEXT statements, which replace SET SHOWPLAN, do not execute Transact-SQL statements. Expect different results as compared to earlier versions of SQL Server. Expect a difference in behavior when SET SHOWPLAN_ALL or SET SHOWPLAN_TEXT are set to ON.


SQL-DMO (Level 1)

SQL-DMO applications are administrative tools and should be updated to work with SQL Server 2000. It is recommended that code be recompiled and any error messages returned from the build process be used to track any necessary changes.

SQL Server 6.x SQL Server 2000
SQL-DMO is implemented in Sqlole.dll. The SQL-DMO objects exhibit properties, methods, and events that automate administrative tasks for SQL Server version 6.5 and earlier. SQL-DMO, implemented in Sqlole.dll, cannot connect to and operate against SQL Server 2000 or SQL Server 7.0. SQL-DMO is implemented in Sqldmo.dll. These SQL-DMO objects expose the properties, methods, and events that automate administrative tasks for SQL Server. They cannot be used to connect to and operate against a SQL Server version 6.5 (or earlier) server. Therefore, it is recommended that you rewrite SQL-DMO applications.

If the application must operate against both SQL Server 2000 and version 6.5 or earlier of SQL Server, reference both Sqldmo.dll and Sqlole.dll components in the application. Develop new, separate subroutines referencing the SQL Server 2000 SQL-DMO objects from the existing subroutines.

If the application will work against SQL Server 2000 only, rewrite existing subroutines to reference SQL Server 2000 SQL-DMO objects.

If the application will not be used against your new SQL Server 2000 server(s), continue to use the application unchanged.


Segments (Level 1)
SQL Server 6.x | SQL Server 2000
Indexes could be placed on segments using the CREATE INDEX statement. | Segments are no longer supported. However, CREATE INDEX can create an index on a filegroup. Remove all references to segments and replace with references to filegroups within a CREATE INDEX statement.
Tables could be created on a particular segment by using the CREATE TABLE statement. | CREATE TABLE references files and filegroups instead of segments. Remove all references to segments and replace with references to files and filegroups within a CREATE TABLE statement.
User-defined segments allowed the placement of database objects on certain devices for performance reasons. | Segments are no longer supported. Multidisk RAID devices generally provide a greater increase in performance with a lower associated administrative cost. Use filegroups for user-defined placement of data, indexes, or text. Remove all references to these segment-related system stored procedures: sp_addsegment sp_dropsegment sp_extendsegment sp_helpsegment Create, modify, or drop files and filegroups; and place indexes on files or filegroups using CREATE TABLE, CREATE DATABASE, ALTER DATABASE, and CREATE INDEX.


Security (Level 1)
SQL Server 6.x | SQL Server 2000
DENY was not a reserved keyword and could be used as an object identifier. | DENY is a reserved keyword. Rename any object named DENY. Change all Transact-SQL statements and scripts referencing the object to use the new object name. If DENY is retained as an object identifier, all references to the object must use Delimited Identifiers.


LTRIM and RTRIM Trimming Functions (Level 2)
SQL Server 6.x SQL Server 2000
The LTRIM and RTRIM functions returned NULL in queries using zero-length strings:
SELECT RTRIM('')

SELECT DATALENGTH(RTRIM(''))
Zero-length strings are supported. The queries shown return nonnull values; the first returns '' and the second returns 0.

Expect different results as compared to earlier versions of SQL Server. LTRIM and RTRIM provide different output from earlier versions of SQL Server.


Table Hints (Level 2)
SQL Server 6.x | SQL Server 2000
These table hints (previously called optimizer hints) could be specified as just the keyword following the FROM clause: FASTFIRSTROW, HOLDLOCK, INDEX, NOLOCK, PAGLOCK, TABLOCK, TABLOCKX, and UPDLOCK. | Table hints must be specified following the FROM clause using a WITH clause. Table hints must be enclosed in parentheses. Expect different results as compared to earlier versions of SQL Server. For more information, see DELETE, FROM, INSERT, SELECT, and UPDATE.


Transactions (Level 2)
SQL Server 6.x | SQL Server 2000
When CURSOR_CLOSE_ON_COMMIT was set OFF, a ROLLBACK statement did not close a Transact-SQL cursor defined with the DECLARE CURSOR statement. Server cursors opened through database API functions were also left open after a ROLLBACK statement. | When CURSOR_CLOSE_ON_COMMIT is set OFF, a ROLLBACK statement closes any Transact-SQL cursor defined with the SQL-92 form of the DECLARE CURSOR statement, unless the DECLARE CURSOR statement contains either the INSENSITIVE or STATIC keywords. All API server cursors are also closed unless they have been defined as STATIC cursors (such as using the ODBC SQL_CURSOR_STATIC attribute). Expect different results as compared to earlier versions of SQL Server. Reopen all cursors after issuing a ROLLBACK statement.
The REPEATABLE READ clause of the SET TRANSACTION ISOLATION LEVEL statement behaved identically to the SERIALIZABLE clause. There was no way to ensure repeatable reads without also protecting against phantoms (after a rollback, the value read logically never existed). Transactions that required REPEATABLE READ semantics had to pay the additional concurrency penalty of serializability. | The REPEATABLE READ clause now does not necessarily protect against phantoms. Serializable transactions, set using the SERIALIZABLE clause of SET TRANSACTION ISOLATION LEVEL, allow less concurrency than the REPEATABLE READ clause because they protect against phantoms. Expect different results as compared to earlier versions of SQL Server. Many applications only need REPEATABLE READ semantics for correct operation. Use the REPEATABLE READ clause of SET TRANSACTION ISOLATION LEVEL for applications requiring REPEATABLE READ semantics but that do not need phantom protection. If phantom protection is required, use the SERIALIZABLE clause.

Here is a summary of phantom protection for both SQL Server versions 6.5 and SQL Server 2000 using SET TRANSACTION ISOLATION LEVEL.

Phantom protection | SQL Server 6.5 | SQL Server 2000
REPEATABLE READ | Yes | No
SERIALIZABLE | Yes | Yes


Backup and Restore (Level 2)

New Information - SQL Server 2000 SP3.

SQL Server 6.x | SQL Server 2000
Using the SKIP and INIT clauses of the DUMP statement together overwrote the contents of the backup device unconditionally. | The SKIP and INIT clauses of the BACKUP statement preserve the Microsoft Tape Format media header. In some situations, this prevents overwriting the backup contents. The FORMAT clause overwrites the media unconditionally, generating a new header, and is required for media used for the first time or when necessary to overwrite the media header. Expect different results as compared to earlier versions of SQL Server. If the media is empty, SKIP and INIT act the same as the FORMAT clause of the BACKUP or DUMP statements and write a new media header. If the media is not empty, SKIP and INIT do not write a new media header.
The LOAD statement did not create the database automatically when restoring the database backup. | It is no longer necessary to create the database before restoring it. The RESTORE statement re-creates the database automatically, including all files. However, database devices are not re-created in sysdevices. These devices are supported only for backward compatibility. After restoration, databases originally created using devices (DISK INIT) appear as if they had been created using SQL Server 2000 file syntax. Expect different results as compared to earlier versions of SQL Server. Consider using the new syntax in CREATE DATABASE and ALTER DATABASE for specifying files.
The NO_LOG clause of DUMP was used only when you ran out of space in the database and could not use DUMP TRANSACTION WITH TRUNCATE_ONLY to purge the log. The NO_LOG clause removes the inactive part of the log without making a backup copy of it, and saves space by not logging the operation. The TRUNCATE_ONLY clause of the DUMP statement removed the inactive part of the log without making a backup copy of it. | The NO_LOG and TRUNCATE_ONLY clauses of RESTORE are synonyms. Both clauses of BACKUP now remove the inactive part of the log without making a backup copy of it and truncate the log. Expect different results as compared to earlier versions of SQL Server. Expect the NO_LOG and TRUNCATE_ONLY clauses of the BACKUP or DUMP statements to behave identically.
Recovery of multiple transaction logs could be performed without special keywords in the LOAD statement. | It is no longer possible to restore multiple transaction logs without using the WITH clauses of the RESTORE statement. Expect different results as compared to earlier versions of SQL Server. Use the appropriate RESTORE syntax for restoring a database with multiple transaction logs as shown in the following examples. All but the last RESTORE statement should specify the NORECOVERY clause.
When loading a database, all database options of sp_dboption were unaffected and had to be set manually. | Changes to all sp_dboption database settings (except the offline, merge publish, published, and subscribed settings) are logged, like any other change. When a database is restored and recovered, all database options of sp_dboption are rolled forward. Every database option will be in its expected state at the time when recovery finished, consistent with the remainder of the database. Expect different results as compared to earlier versions of SQL Server. It is no longer necessary to reset the database options after a RESTORE operation.

Examples

A. Restore a database by applying a full database backup and multiple transaction logs

This example restores a database with multiple transaction log backups.

RESTORE DATABASE mydb
FROM mydb
WITH NORECOVERY

RESTORE LOG mydb
FROM mydb_log1
WITH NORECOVERY

RESTORE LOG mydb
FROM mydb_log2
WITH RECOVERY

SQL Server 6.x | SQL Server 2000
A warm standby server could be brought up in read-only mode between recovery of each transaction log, provided that the no chkpt. on recovery option of sp_dboption was enabled. | A warm standby server can be brought up in read-only mode between transaction log restore operations if an undo file is used. Expect different results as compared to earlier versions of SQL Server. Use an undo file for a warm standby server using the STANDBY clause of RESTORE, as shown in the following example.

B. Restore a database using the STANDBY clause and an undo file

This example brings the server up to allow write operations on the databases by using a final, necessary RESTORE statement.

RESTORE DATABASE mydatabase
FROM mydb_backup
WITH NORECOVERY

RESTORE LOG mydb
FROM mydb_log1
WITH RECOVERY STANDBY = 'c:\mssql\data\mydbundo.dat'

RESTORE LOG mydb
FROM mydb_log2
WITH RECOVERY STANDBY = 'c:\mssql\data\mydbundo.dat'

RESTORE DATABASE mydb
WITH RECOVERY


System Tables (Level 2)
SQL Server 6.x | SQL Server 2000
System tables were used internally by SQL Server for a wide range of uses. | Some system tables have had minor changes, while others have been replaced by Information Schema Views that provide the same information. Expect different results as compared to earlier versions of SQL Server. Use the provided Information Schema Views or ODBC catalog system stored procedures to obtain system catalog information.
The logptr column of sysdatabases was a pointer to the transaction log. | The logptr column has been renamed to status2. Remove all references of the logptr column of sysdatabases and replace with references to the status2 column.
The dumptrdate column of sysdatabases was the date of the last DUMP TRANSACTION. | This column is now Reserved. Expect different results as compared to earlier versions of SQL Server. Remove all references to the dumptrdate column of sysdatabases.
The langid column of sysmessages contained the SQL Server message group ID. | The langid column has been renamed to msglangid. Expect different results as compared to earlier versions of SQL Server. Remove all references of the langid column of sysmessages and replace with references to the msglangid column.
A NULL value for the language column of the syslogins table was equivalent to specifying us_english. | A NULL value for the language column is no longer equivalent to us_english. Expect different results as compared to earlier versions of SQL Server. Remove all NULL values for the language column of syslogins and replace with the name of the language to be used.
System tables obtained their column values by insertion of a specific value (SQL Server 2000 uses computed columns in many system and user-defined tables.) | System tables (and user-defined tables) can now use computed columns. Expect different results as compared to earlier versions of SQL Server. SQL Server version 6.5 queries involving table hints and system tables may still produce the same result set, but may behave differently in SQL Server 2000. For example, the query may still wait for some locks even if the NOLOCK table hint has been specified in the query's FROM clause.


Views (Level 2)

New Information - SQL Server 2000 SP3.

SQL Server 6.x | SQL Server 2000
Updatable views were restricted to modifications that affected only one table. | Partitioned views can modify more than one table involved in the view. The DELETE, INSERT, and UPDATE statements can reference a view as long as SQL Server can translate the user's update request unambiguously to updates in the base tables referenced in the view's definition. Expect differences in behavior when working with updatable, partitioned views that have more than one table involved in DELETE, INSERT, or UPDATE statements.


Program Group Tools and Utilities (Level 1)

In Microsoft® SQL Server™ 2000, these tools have been renamed or replaced.

SQL Server 6.x | SQL Server 2000
ISQL_w | SQL Query Analyzer
MS Query | N/A
SQL Client Configuration | Client Network Utility
SQL Enterprise Manager | SQL Server Enterprise Manager
SQL Help | N/A
SQL Security Manager | N/A
SQL Trace | SQL Server Profiler
SQL Performance Monitor | N/A. SQL Server performance counters are added to the Windows 2000 System Monitor or the Windows NT 4.0 Performance Monitor.
SQL Service Manager | SQL Server Service Manager
SQL Setup | N/A


SELECT (Level 2)
SQL Server 6.x | SQL Server 2000
A SELECT statement without an ORDER BY clause returned the rows in an apparent ordered set. | An explicit ORDER BY clause for a SELECT statement is required to ensure any useful ordering of data. In addition, the exact results depend upon the collation being used. Expect different results as compared to earlier versions of SQL Server. Add an explicit ORDER BY clause to all SELECT statements needing to produce ordered rows.


Configuration Options (Level 2)

Administrative scripts may have used these configuration options. For more information about configuration options, see sp_configure and Setting Configuration Options.

SQL Server 6.x | SQL Server 2000
open objects set the maximum number of database objects that can be open at one time on SQL Server. | Now an advanced option. Default value of 0 indicates automatic growth. Expect different results as compared to earlier versions of SQL Server. Remove all references to open objects. For more information, see open objects Option.
user connections set the maximum allowed number of simultaneous connections to SQL Server. | Now an advanced option. Default value of 0 indicates automatic growth. Expect different results as compared to earlier versions of SQL Server. Remove all references to user connections Option.


Triggers and System Stored Procedures (Level 2)
SQL Server 6.x | SQL Server 2000
sp_helpsql provided syntax for Transact-SQL statements, system stored procedures, and other special topics. | sp_helpsql is included, but no longer returns syntax information for Transact-SQL statements or system stored procedures. Executing sp_helpsql produces a message that recommends obtaining syntax information from Online Help. Expect different results as compared to earlier versions of SQL Server. Use SQL Server Books Online for the syntax of Transact-SQL statements and system stored procedures.
Only one trigger for each data modification event (INSERT, UPDATE, or DELETE) was allowed for each table. If a new trigger was created for a specific data modification event, it replaced the previous trigger. | Microsoft® SQL Server™ allows multiple triggers to be created for each data modification event (DELETE, INSERT, or UPDATE). For example, if CREATE TRIGGER FOR UPDATE is executed for a table that already has an UPDATE trigger, an additional UPDATE trigger is created. Expect different results as compared to earlier versions of SQL Server. Enable multiple triggers by setting the compatibility level to 80 in sp_dbcmptlevel. Retain SQL Server 6.x behavior by setting the compatibility level to 60 or 65. For more information, see sp_dbcmptlevel and CREATE TRIGGER.
If a trigger modified the table on which it was defined, the triggers were not invoked recursively for that modification. | SQL Server allows recursive invocation of triggers. Expect different results as compared to earlier versions of SQL Server. Enable recursive triggers by setting the RECURSIVE_TRIGGERS database option. For more information about recursive and nested triggers, see Nested Triggers.
Several parameters of sp_create_removable referred to devices. | Devices have been replaced with files and filegroups. Expect different results as compared to earlier versions of SQL Server. Replace all device references in sp_create_removable with references to filegroups
References to text or image columns in either the inserted or deleted tables appeared as NULL. | References to text or image columns in both the inserted and deleted tables are no longer allowed unless the compatibility level setting of sp_dbcmptlevel is 60 or 65. Expect a difference in behavior when referring to text or image columns in inserted and deleted tables when using CREATE TRIGGER, depending on the setting of sp_dbcmptlevel.
SQL Server searched the current database followed by a search in master for a stored procedure using the sp_ prefix. | Stored procedures with the prefix sp_ are first looked up in master. If a user-defined stored procedure has the same name as a system-supplied stored procedure residing in master, SQL Server always finds the system-supplied stored procedure. Expect different results as compared to earlier versions of SQL Server. Expect a difference in behavior when calling user-defined stored procedures with the sp_ prefix. Either explicitly qualify the name of the user-defined stored procedure, or rename the user-defined stored procedure.
The settings of SET ANSI_NULLS and SET QUOTED_IDENTIFIER statements were active only during the session that changed either option. | The settings of both SET QUOTED_IDENTIFIER and SET ANSI_NULLS are saved when a stored procedure is created or altered. These original settings are enabled when the stored procedure is executed, and any client session settings are restored afterward. Within the stored procedure, any changes to SET ANSI_NULLS do not take effect until after the stored procedure executes. Expect different results as compared to earlier versions of SQL Server. Develop databases or applications with one setting for SET QUOTED_IDENTIFIER, SET ANSI_NULLS, and all other pertinent SET options. If a client session changes SET options, do so outside of stored procedures.
When executing remote stored procedures, these procedures may have assumed non-standard behavior for the options set by SET ANSI_DEFAULTS. In addition, remote stored procedures may not have explicitly set these options (set by SET ANSI_DEFAULTS) to OFF. | When executing remote stored procedures, these procedures are executed with SET ANSI_DEFAULTS set to ON. Expect different results as compared to earlier versions of SQL Server. Expect a difference in behavior when executing remote stored procedures if non-standard settings were used with SET ANSI_DEFAULTS, or if options were not explicitly set to OFF.


SET DISABLE_DEF_CNST_CHK (Level 1)
SQL Server 6.x | SQL Server 2000
The SET DISABLE_DEF_CNST_CHK setting controlled interim constraint checking. | Removed; no longer available. Remove all references to SET DISABLE_DEF_CNST_CHK.


SQL Alerter (Level 1)
SQL Server 6.x | SQL Server 2000
SQL Alerter, SQLALRTR.exe, was used to integrate the alert engine with the Windows NT Performance Monitor alerter. | Removed; no longer supported or available. Replaced by SQL Server performance condition alerts. Remove all references to SQL Alerter and replace with references to SQL Server performance condition alerts. For more information, see Defining Alerts.


DECnet Network Library (Level 1)
SQL Server 6.x | SQL Server 2000
For Intel-based, MIPS-based, and Alpha AXP-based computers, server DECnet Sockets Net-Libraries provided connectivity with PATHWORKS networks by allowing clients running on VMS to connect to SQL Server. | Removed; no longer supported. Remove all references to the DECnet Sockets Net-Libraries.


Empty Strings (Level 2)
SQL Server 6.x | SQL Server 2000
An empty string could be interpreted as either a NULL or a single blank character. | Interpretation of an empty string is controlled by the compatibility level, which is set with the sp_dbcmptlevel system stored procedure. If the compatibility level is 65 or lower, SQL Server interprets empty strings as single spaces. If the compatibility level is 70 or 80, SQL Server interprets empty strings as empty strings. For more information, see sp_dbcmptlevel. Expect differences in interpretation of empty strings compared to earlier versions of SQL Server. Transact-SQL functions and statements affected by the setting of sp_dbcmptlevel include CHARINDEX, DATALENGTH, LEFT, LTRIM, PATINDEX, REPLICATE, RIGHT, RTRIM, SPACE, SUBSTRING, and UPDATETEXT.


System Tables (Level 1)
SQL Server 6.x | SQL Server 2000
System tables were used internally by SQL Server for a wide range of uses, including maintaining the list of character sets that SQL Server could use and containing information about active locks. | System tables have changed significantly. Most SQL Server 6.x system tables will continue to work properly. Views provided allow applications referencing SQL Server 6.x system tables to continue functioning properly. However, some SQL Server 2000 data cannot be referenced through these views. Use the provided Information Schema Views or ODBC catalog system stored procedures to obtain system table information. Modify scripts as appropriate. Any scripts referencing SQL Server 6.x system tables will not be converted properly.
sysdevices contained one row for each disk dump, tape dump, and database device. | The mirrorname and stripeset columns have been removed. sysdevices is retained only for dump devices and also for backward compatibility (supporting DISK INIT and SQL Server 6.x CREATE DATABASE syntax). Remove all references to the mirrorname and stripeset columns of sysdevices.
syshistory contained one row for each scheduled event, alert, or task that occurred. | Replaced by sysjobhistory. Remove all references to syshistory and replace with references to sysjobhistory.
sysindexes contained one row for each clustered index and one row for each nonclustered index. | The distribution, segment, rowpage, keys1, and keys2 columns have been removed. Remove all references to the distribution, segment, rowpage, keys1, and keys2 columns of sysindexes. In addition, soid is reserved3, and csid is reserved4.
syskeys used for objects | Removed; no replacement. Remove all references to syskeys.
syslocks contained information about active locks. | Removed; replaced by syslockinfo. Remove all references to syslocks and replace with references to syslockinfo.
syslogs contained the transaction log. | Removed; no replacement. The database log is now an operating system file. Remove all references to syslogs.
sysprocesses contained information about SQL Server processes. | The gid column has been removed. In SQL Server, the suid column has been removed. Remove all references to these columns of sysprocesses.
sysprocedures contained entries for each view, default, rule, trigger, CHECK constraint, DEFAULT constraint, and stored procedure. | Removed; replaced by syscomments. SQL Server obtains procedure text from syscomments when procedures need to be compiled. Remove all references to sysprocedures and replace with references to syscomments.
syssegments contained one row for each segment (named collection of disk fragments). | Removed; no replacement. Segments are no longer supported. Use filegroups instead. Remove all references to syssegments. Use filegroups instead by using CREATE DATABASE, ALTER DATABASE, CREATE TABLE, ALTER TABLE, and CREATE INDEX.
systasks contained one row for every scheduled task. | Removed; replaced by sysjobs, sysjobsteps, and sysjobservers. Remove all references to systasks and replace with references to sysjobs, sysjobsteps, and sysjobservers as appropriate.
sysusages contained one row for each disk-allocation piece assigned to a database. | Removed; no replacement. SQL Server relies on sysdevices for database file information. Filegroups are supported, and the sysfiles and sysfilegroups system tables are added. These system tables reside in every database and describe database files and filegroups. Remove all references to sysusages.
master.dbo.spt _datatype_info | Removed; no replacement. Remove all references to master.dbo.spt_datatype_info.

For more information, see System Tables.


UPDATE (Level 2)
SQL Server 6.x | SQL Server 2000
When ARITHABORT was set to OFF, an UPDATE statement encountering an arithmetic overflow condition would set the updated value to NULL, or skip the update if the value belonged to a nonnull column. | When SET ARITHABORT is OFF and an INSERT, UPDATE, or DELETE statement encounters an arithmetic error, SQL Server inserts or updates a NULL value. If the target column is not nullable, the insert or update action fails and the user receives an error. Expect different results as compared to earlier versions of SQL Server. Use the @@ERROR function to test for errors after UPDATE or INSERT statements.


Databases (Level 1)
SQL Server 6.x | SQL Server 2000
The ON database_device = size clause of ALTER DATABASE specified the amount of space, in megabytes (MB), allocated to the database extension and could be used following DISK INIT to alter the database device size. | If the file was not created originally by DISK INIT, the ON database_device = size syntax cannot be specified with ALTER DATABASE. Instead, use the MODIFY FILE clause of ALTER DATABASE to alter the size of a database file. Remove all references of the ON database_device = size clause of ALTER DATABASE. For more information, see ALTER DATABASE.


Keyset Cursors (Level 2)
SQL Server 6.x | SQL Server 2000
When using a keyset cursor, a row deletion followed by a row insertion using the same key as the deleted row caused the inserted row to occupy the slot of the original row. | When using a keyset cursor, a row deletion followed by a row insertion with the same key as the deleted row allows the original row to remain empty and the newly inserted row to be inserted at the end. Expect different results as compared to earlier versions of SQL Server. Expect a change in behavior when inserting and deleting rows with the same key values when using keyset cursors.


DB-Library (Level 2)
SQL Server 6.x SQL Server 2000
When connected to a version 6.x SQL Server, a call to dbcursorfetchex resulting in a cursor position after the end of the cursor result set returned:
  • FAIL, with either a keyset or an insensitive cursor.

  • SUCCEED, with all row status indicators set to 0, with either a dynamic or forward cursor.
 A call to dbcursorfetchex resulting in a cursor position after the end of the cursor result set returns SUCCEED. All row status indicators are set to 0. This behavior applies to all types of cursors.

Expect different results as compared to earlier versions of SQL Server. Expect different results, compared to SQL Server 6.x, when a call to dbcursorfetchex results in a cursor position after the end of the cursor result set. To achieve SQL Server 6.x behavior, use compatibility level 65.


Indexes (Level 2)
SQL Server 6.x | SQL Server 2000
The DROP INDEX statement dropped the pages holding the clustered index B-tree when used on a clustered index. | On a clustered index, the DROP INDEX statement must rebuild all nonclustered indexes. SQL Server must also replace the clustered index keys in the nonclustered leaf rows with row pointers. Expect different results as compared to earlier versions of SQL Server. Use the DROP_EXISTING clause of the CREATE INDEX statement if, for example, dropping or re-creating clustered indexes to set a new fill factor value.


Replication (Level 1)
SQL Server 6.x | SQL Server 2000
Restricted publications could be created through the user interface and used in replicating data. | Restricted publications cannot be created through the user interface and are no longer supported. Remove all references to restricted publications. A replacement for restricted publications will be available in a later release. For more information, see Replication Overview.
Publish and subscribe properties could be set using the DBOption object. | No longer available. Remove all references to the DBOption object and replace with references to the EnablePublishing property of the ReplicationDatabase object.
The repl_publisher login allowed replication processes on the distributor to connect to a subscription server and replicated table schema and data to destination databases. | No longer available. Remove all references to the repl_publisher login and replace with references to a login in a publication access list (PAL). For more information about PALs, see Publication Access Lists.


System Stored Procedures (Tasks) (Level 1)

Replace the following unsupported Microsoft® SQL Server™ 6.x task-related system stored procedures with the corresponding SQL Server 2000 job-related system stored procedures.

SQL Server 6.x | SQL Server 2000
sp_addalert | sp_add_alert
sp_addnotification | sp_add_notification
sp_addoperator | sp_add_operator
sp_dropalert | sp_delete_alert
sp_dropnotification | sp_delete_notification
sp_dropoperator | sp_delete_operator
sp_helpalert | sp_help_alert
sp_helphistory | sp_help_jobhistory
sp_helpnotification | sp_help_notification
sp_helpoperator | sp_help_operator
sp_purgehistory | sp_purge_jobhistory
sp_runtask | sp_start_job
sp_stoptask | sp_stop_job
sp_updatealert | sp_update_alert
sp_updatenotification | sp_update_notification
sp_updateoperator | sp_update_operator

Task management has been changed to job management.


Data Access Objects (DAO) (Level 1)
SQL Server 6.x | SQL Server 2000
Version 3.x of the Data Access Objects (DAO) functioned properly when accessing SQL Server version 6.x servers. | Because the ODBC driver that ships with SQL Server 2000 exposes new GUID and Unicode data types when connecting to SQL Server, DAO version 3.x does not work properly with SQL Server 2000. However, the odbccmpt Utility is provided to enable SQL Server version 6.x ODBC compatibility for a DAO application.


Transactions (Level 1)
SQL Server 6.x SQL Server 2000
A data type conversion error not inside a transaction returned an error to SQL Server. If the data type conversion was inside a transaction, the transaction continued. For example:
USE pubs
CREATE TABLE test (c1 int)
GO
BEGIN TRANSACTION
GO
INSERT INTO test VALUES (1)
GO
INSERT INTO test VALUES ('aaa')
GO
COMMIT TRANSACTION
GO
SELECT *
FROM test
 SQL Server returns an error when an attempted data type conversion fails. If the data type conversion error occurs inside a transaction, the transaction is terminated. Expect differences in behavior as compared to earlier versions of SQL Server if a data type conversion fails inside a transaction.


System Stored Procedures (General Extended Procedures) (Level 1)
SQL Server 6.x | SQL Server 2000
xp_snmp_getstate returned the state of the SQL Server Simple Network Management Protocol (SNMP) agent. xp_snmp_raisetrap permitted a client to define and send a trap (an SNMP alert) to an SNMP client. | Removed; no longer available. Remove all references to either xp_snmp_getstate or xp_snmp_raisetrap.


DBCC (Level 1)

New Information - SQL Server 2000 SP3.

SQL Server 6.x | SQL Server 2000
DBCC DBREINDEX used the SORTED_DATA and SORTED_DATA_REORG clauses. The SORTED_DATA clause eliminated the sort performed when a clustered index was created and physically reorganized the data. The SORTED_DATA_REORG clause eliminated the sort performed when a clustered index was created. | Removed; no longer supported. Remove all references to either the SORTED_DATA or the SORTED_DATA_REORG clauses of DBCC DBREINDEX and replace with references to the DROP_EXISTING clause of CREATE INDEX.
DBCC SHRINKDB either returned the minimum size to which a database could shrink, or shrank the size of the specified database to the specified value. | Removed; no longer supported or available. Remove all references of DBCC SHRINKDB and replace with references to DBCC SHRINKDATABASE. Consider shrinking databases automatically by using the AUTO_SHRINK option of ALTER DATABASE.
DBCC MEMUSAGE provided detailed reports on memory use. | Removed; no longer supported or available. Remove all references of DBCC MEMUSAGE and replace with references to these Performance Monitor counters.

Performance Monitor object name | Performance Monitor counter name
SQL Server: Buffer Manager Object | Procedure Cache Pages
SQL Server: Cache Manager Object | Procedure Cache Hit Ratio
 | Procedure Cache Pages
 | Procedure Cache Object Counts*

* These counters are available for various categories of cache objects including ad hoc sql, prepared sql, procedures, triggers, and so on.


Open Data Services (Level 1)

In SQL Server 2000, Open Data Services, now called extended stored procedures, no longer supports gateway applications.

SQL Server 6.x | SQL Server 2000
The ODBC client driver for Open Data Services gateways (ODSGT32.DLL) and associated resource files were used by ODBC clients to connect to Open Data Services gateway servers. | Not shipped with SQL Server 2000. The SQL Server version 6.x ODSGT32.DLL and associated resource files work against an Open Data Services gateway recompiled with SQL Server version 7.0 headers and libraries. Use the SQL Server version 6.x ODBC client driver for Open Data Services (ODSGT32.DLL) and associated resource files to connect from an ODBC client to an Open Data Services gateway. Consider redesigning your application using Windows NT Component Services.
Open Data Services data structures such as SRV_CONFIG, SRV_PROC, and SRV_SERVER were exposed in the Open Data Services header file. | These data structures are no longer exposed, and the data structure members have changed. Applications that reference these data structures directly or their members must be changed and recompiled using the SQL Server 7.0 Open Data Services header file (srv.h) and relinked using the SQL Server 7.0 Open Data Services library file (opends60.lib). These changes should be made to avoid the possibility of server failures.
Earlier versions of SQL Server could make remote stored procedure calls against gateways compliant with 6.x or 4.x versions of Open Data Services. | SQL Server 2000 does not support remote stored procedure calls against gateways compliant with 6.x and 4.x versions of Open Data Services. SQL Server 2000 does support remote stored procedure calls against gateways compliant with SQL Server 2000. Gateways compiled and linked with earlier versions of Open Data Services should be recompiled with SQL Server 7.0 version of Open Data Services. Consider using distributed query if your target data source has an ODBC or an OLE DB provider on Windows NT or Windows 95/98.


 SQL Server Setup Help

See SQL Server Books Online to review this topic.


Glossary

Symbols

New Information - Shiloh SP3.

(All) level

The optional highest level of a dimension. The (All) level contains a single member that is the summary of all members of the immediately subordinate level.

A

action

An end user-initiated operation upon a selected cube or portion of a cube. The operation can launch an application with the selected item as a parameter or retrieve information about the selected item.

active statement

An SQL statement that has been executed but whose result set has not yet been canceled or fully processed.

active voice

Indicates the subject of the sentence is the entity that performs the action described by the verb. For example, customers buy products is in active voice, whereas products are bought by customers is in passive voice.

See also: passive voice

ActiveX Data Objects

An easy-to-use application programming interface (API) that wraps OLE DB for use in languages such as Visual Basic, Visual Basic for Applications, Active Server Pages, and Microsoft Internet Explorer Visual Basic Scripting.

ActiveX Data Objects (Multidimensional) (ADO MD)

A high-level, language-independent set of object-based data access interfaces optimized for multidimensional data applications. Visual Basic and other automation languages use ADO MD as the data access interface to multidimensional data storage. ADO MD is a part of ADO 2.0 and later.

ad hoc connector name

The OpenRowset function in the FROM clause of a query, which allows all connection information for an external server and data source to be issued every time the data must be accessed.

add-in

A custom extension, written in any language that supports the Component Object Model (COM), usually Visual Basic, that interacts with Analysis Manager and provides specific functionality. Add-ins are registered with the Analysis Add-in Manager. They are called by the Analysis Add-in Manager in response to user actions in the user interface.

adjective phrasing

A way of expressing a relationship in English in which an entity is described by an adjective (either a single word or another entity containing the adjective). For example, in the phrasing the cities are hot, hot is the adjective, and cities is the entity being described.

ADO

See definition for: ActiveX Data Objects

ADO MD

See definition for: ActiveX Data Objects (Multidimensional) (ADO MD)

adverb

The part of speech modifying a verb, an adjective, or another adverb. In English Query, adverbs such as very and recent are interpreted correctly; however, other adverbs, such as rapidly or graciously are not interpreted.

aggregate function

A function that performs a calculation on a column in a set of rows and returns a single value.

aggregate query

A query (SQL statement) that summarizes information from multiple rows by including an aggregate function such as Sum or Avg .

aggregation

A table or structure that contains precalculated data for a cube.

aggregation

A collection of objects that makes a whole. An aggregation can be a concrete or conceptual set of whole-part relationships among objects.

aggregation prefix

A string that is combined with a system-defined ID to create a unique name for a partition's aggregation table.

aggregation wrapper

A wrapper that encapsulates a COM object within another COM object.

alert

A user-defined response to a SQL Server event. Alerts can either execute a defined task or send an e-mail and/or pager message to a specified operator.

alias

An alternative name for a table or column in expressions that is often used to shorten the name for subsequent reference in code, prevent possible ambiguous references, or provide a more descriptive name in the query output. An alias can also be an alternative name for a server.

aliasing

To allow the name of an object, property, or relationship to be reused in a new context while keeping all other attributes constant.

All member

The single member of the (All) level. By default, the name of the All member is All followed by a space and the dimension name.

See also: default member

American National Standards Institute (ANSI)

An organization of American industry and business groups that develops trade and communication standards for the United States. Through membership in the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), ANSI coordinates American standards with corresponding international standards.

Analysis server

The server component of Analysis Services that is specifically designed to create and maintain multidimensional data structures and provide multidimensional data in response to client queries.

ancestor

A member in a superior level in a dimension hierarchy that is related through lineage to the current member within the dimension hierarchy. For example, in a Time dimension containing the levels Quarter, Month, and Day, Qtr1 is an ancestor of January 1.

See also: child, descendant, parent, sibling

annotational property

A property that is maintained by Meta Data Services as string data that can be attached to any repository object that exposes the IAnnotationalProps interface.

anonymous subscription

An anonymous subscription is a type of pull subscription for which detailed information about the subscription and the Subscriber is not stored.

ANSI

See definition for: American National Standards Institute (ANSI)

ANSI to OEM conversion

The conversion of characters that must occur when data is transferred from a database that stores character data using a specific code page to a client application on a computer that uses a different code page. Typically, Windows-based client computers use ANSI/ISO code pages, and some databases (for compatibility reasons) may use OEM code pages, such as the MS-DOS 437 code page or code page 850.

API

See definition for: application programming interface (API)

API server cursor

A server cursor built to support the cursor functions of an application programming interface (API), such as ODBC, OLE DB, ADO, and DB-Library. An application does not usually request a server cursor directly; it calls the cursor functions of the API. The SQL Server interface for that API implements a server cursor if that is the best way to support the requested cursor functionality.

See also: server cursor

application programming interface (API)

A set of routines available in an application, such as ActiveX Data Objects (ADO), for use by software programmers when designing an application interface.

application role

A SQL Server role created to support the security needs of an application.

archive file

The .cab file created by archiving an Analysis Services database.

article

An object specified for replication. An article is a component in a publication and can be a table, specified columns (using a column filter), specified rows (using a row filter), a stored procedure or view definition, the execution of a stored procedure, a view, an indexed view, or a user-defined function.

atomic

Either all of the transaction data modifications are performed or none of them are performed.

attribute

In data mining, a single characteristic of a case. An attribute is used to provide information about a case. For example, weight can be an attribute of a case that involves shipping containers.

See also: case

authentication

The process of validating that the user attempting to connect to SQL Server is authorized to do so.

See also: SQL Server Authentication

authorization

The operation that verifies the permissions and access rights granted to a user.

automatic recovery

Recovery that occurs every time SQL Server is restarted. Automatic recovery protects your database if there is a system failure.

autonomy

The independence one site has from other sites when performing modifications to data.

axis

A set of tuples. Each tuple is a vector of members. A set of axes defines the coordinates of a multidimensional data set. For more information about axes, see the OLE DB documentation.

See also: slice, tuple

B

backup

A copy of a database, transaction log, file, or filegroup used to recover data after a system failure.

backup device

A tape or disk used in a backup or restore operation.

backup file

A file that stores a full or partial database, transaction log, or file and/or filegroup backup.

backup media

The tape, disk, or named pipe used to store a backup set.

backup set

The output of a single backup operation.

balanced hierarchy

A dimension hierarchy in which all leaf nodes are the same distance from the root node.

base data type

Any system-supplied data type, for example, char , varchar , binary , and varbinary . User-defined data types are derived from base data types.

See also: data type, user-defined data type

base table

A table stored permanently in a database. Base tables are referenced by views, cursors, SQL statements, and stored procedures.

See also: underlying table

batch

A set of SQL statements submitted together and executed as a group. A script is often a series of batches submitted one after the other.

bcp files

Files that store bulk copy data created by the bulk copy utility or synchronization.

bcp utility

A command prompt bulk copy utility that copies SQL Server data to or from an operating system file in a user-specified format.

bigint data type

An integer data type with a value from -2^63 (-9,223,372,036,854,775,808) through 2^63-1 (9,223,372,036,854,775,807).

binary data type

A fixed-length binary data type with a maximum length of 8,000 bytes.

binary large object

A piece of binary data that has an exceptionally large size (such as pictures or audio tracks stored as digital data), or any variable or table column large enough to hold such values. In Transact-SQL, a BLOB is stored in an image column. Sometimes the term BLOB is also applied to large character data values, such as those stored in text or ntext columns.

binding

In SQL application programming interfaces (APIs), binding is associating a result set column or a parameter with a program variable so that data is moved automatically into or out of a program variable when a row is fetched or updated.

bit data type

A data type that holds a value of either 1 or 0.

bitwise operation

An operation that manipulates a single bit, or tests whether a bit is on or off.

BLOB

See definition for: binary large object

blocks

A series of Transact-SQL statements enclosed by BEGIN and END. You can nest BEGIN...END blocks within other BEGIN...END blocks.

Boolean

An operation or expression that can be evaluated only as either true or false.

browse mode

A function that lets you scan database rows and update their values one row at a time. Several browse mode functions return information that an application can use to examine the structure of a complicated ad hoc query.

built-in functions

A group of predefined functions provided as part of the Transact-SQL and Multidimensional Expressions (MDX) languages.

business rules

The logical rules that are used to run a business. Business rules can be enforced in the .com objects that make up the middle tier of a Windows DNA system, they can also be enforced in a SQL Server database using triggers, stored procedures, and constraints.

C

cache aging

The mechanism of caching that determines when a cache row is outdated and must be refreshed.

calculated column

A column in a table that displays the result of an expression rather than stored data. For example, CalculatedCostColumn = Price * Quantity .

calculated field

A field defined in a query that displays the result of an expression rather than stored data.

calculated member

A member of a dimension whose value is calculated at run time using an expression. Calculated member values may be derived from other members' values. A calculated member is any member that is not an input member. For example, a calculated member Profit can be determined by subtracting the value of the member Costs from the value of the member Sales.

See also: input member

calculation condition

A Multidimensional Expressions (MDX) logical expression used to determine whether a calculation formula will be applied against a cell in a calculation subcube.

See also: solve order

calculation formula

A Multidimensional Expressions (MDX) expression used to supply a value for cells in a calculation subcube, subject to the application of a calculation condition.

See also: solve order

calculation pass

A stage of calculation in a multidimensional cube in which applicable calculations are evaluated. Multiple passes may be required to complete all calculations.

See also: solve order

calculation subcube

The set of multidimensional cube cells used to create a calculated cells definition. The set of cells is defined by a combination of Multidimensional Expressions (MDX) set expressions.

See also: solve order

call-level interface (CLI)

The interface supported by ODBC for use by an application.

candidate key

A column or set of columns that have a unique value for each row in a table. Each candidate key value uniquely identifies a single row in the table. Tables can have multiple candidate keys. One candidate key in a table is specified by the database designer to be the primary key for the table, and any other candidate key is called an alternate key.

cascading delete

An operation that deletes a row containing a primary key value that is referenced by foreign key columns in existing rows in other tables. On a cascade delete, all of the rows whose foreign key values reference the deleted primary key value are also deleted.

cascading update

An operation that updates a primary key value that is referenced by foreign key columns in existing rows in other tables. On a cascade update, all of the foreign key values are updated to match the new primary key value.

case

In data mining, an abstract view of data characterized by attributes and relations to other cases. A case is a distinct member of a case set, and can be a member of multiple case sets.

See also: case key, case set, attribute

case key

In data mining, the element of a case by which the case is referenced within a case set.

See also: case

case set

In data mining, a set of cases.

See also: case

cell

In a cube, the set of properties, including a value, specified by the intersection when one member is selected from each dimension.

cellset

In ADO MD, an object that contains a collection of cells selected from cubes or other cellsets by a multidimensional query.

certificate

A collection of data used for authentication and secure exchange of information on nonsecured networks, such as the Internet. A certificate securely binds a public encryption key to the entity that holds the corresponding private encryption key. Certificates are digitally signed by the issuing certification authority and can be managed for a user, a computer, or a service.

change script

A text file that contains SQL statements for all changes made to a database, in the order in which they were made, during an editing session. Each change script is saved in a separate text file with an .sql extension. Change scripts can be applied back to the database later, using a tool such as osql .

changing dimension

A dimension that has a flexible member structure. A changing dimension is designed to support frequent changes to structure and data.

char data type

A character data type that holds a maximum of 8,000 characters.

character format

Data stored in a bulk copy data file using text characters.

See also: native format

character set

A character set determines the types of characters that SQL Server recognizes in the char , varchar , and text data types. Each character set is a set of 256 letters, digits, and symbols specific to a country/region or language. The printable characters of the first 128 values are the same for all character sets. The last 128 characters, sometimes referred to as extended characters, are unique to each character set. A character set is related to, but separate from, Unicode characters.

CHECK constraints

Defines which data values are acceptable in a column. You can apply CHECK constraints to multiple columns, and you can apply multiple CHECK constraints to a single column. When a table is dropped, CHECK constraints are also dropped.

checkpoint

An event in which the database engine writes dirty buffer pages to disk. Dirty pages are pages that have been modified, but the modifications have not yet been written to disk. Each checkpoint writes to disk all pages that were dirty at the last checkpoint and still have not been written to disk. Checkpoints occur periodically based on the number of log records generated by data modifications, or when requested by a user or a system shutdown.

child

A member in the next lower level in a hierarchy that is directly related to the current member. For example, in a Time dimension containing the levels Quarter, Month, and Day, January is a child of Qtr1.

See also: parent, ancestor, descendant, sibling

classification

See definition for: prediction

clause

In English Query, a sequence of related words within a sentence, having both a subject and a predicate and functioning as either an independent or a dependent unit. In Transact-SQL, a subunit of an SQL statement. A clause begins with a keyword.

CLI

See definition for: call-level interface (CLI)

client application

An application that retrieves data from an Analysis server and performs local analysis and presentation of data from relational or multidimensional databases. Client applications connect to the Analysis server through the PivotTable Service component.

client cursor

A cursor implemented on the client. The entire result set is first transferred to the client, and the client application programming interface (API) software implements the cursor functionality from this cached result set.

clustered index

An index in which the logical order of the key values determines the physical order of the corresponding rows in a table.

clustering

A data mining technique that analyzes data to group records together according to their location within the multidimensional attribute space. Clustering is an unsupervised learning technique.

See also: segmentation

code page

For character and Unicode data, a definition of the bit patterns that represent specific letters, numbers, or symbols (such as 0x20 representing a blank space and 0x74 representing the character "t"). Some data types use 1 byte per character; each byte can have 1 of 256 different bit patterns.

collation

A set of rules that determines how data is compared, ordered, and presented. Character data is sorted using collation information, including locale, sort order, and case-sensitivity.

See also: locale, SQL collation

column

In an SQL table, the area in each row that stores the data value for some attribute of the object modeled by the table. For example, the Employees table in the Northwind sample database models the employees of the Northwind Traders company. The LastName column in each row of the Employees table stores the last name of the employee represented by that row, the same way a Last Name field in a window or form would contain a last name.

See also: row

column filter

Column filters restrict the columns to be included as part of a snapshot, transactional or merge publication.

column-level collation

The ability of SQL Server 2000 to support multiple collations in a single instance. Databases can have default collations different from the default collation of the instance. Individual columns and variables can be assigned collations different from the default collation for the instance or database. Each column in a table can have a different collation.

column-level constraint

A constraint definition that is specified within a column definition when a table is created or altered. The constraint applies only to the associated column.

See also: constraint

COM

See definition for: Component Object Model (COM)

COM-structured storage file

A component object model (COM) compound file used by Data Transformation Services (DTS) to store the version history of a saved DTS package.

command relationship

Provides instructions to hardware based on natural-language questions or commands. For example, "Play the album with song XXX on it."

commit

An operation that saves all changes to databases, cubes, or dimensions made since the start of a transaction. A commit guarantees that all of the transaction's modifications are made a permanent part of the database, cube or dimension. A commit also frees resources, such as locks, used by the transaction.

See also: roll back

comparative form

A form of an adjective or adverb that refers to a comparison or that denotes a greater degree. Shorter adjectives and some adverbs typically form their comparative degree by adding -er, such as young and younger.

Component Object Model (COM)

A Microsoft specification for developing component software. Several SQL Server and database application programming interfaces (APIs) such as SQL-DMO, OLE DB, and ADO are based on COM. Some SQL Server components, such as Analysis Services and English Query, store objects as COM objects.

See also: method

composite index

An index that uses more than one column in a table to index data.

composite key

A key composed of two or more columns.

computed column

A virtual column in a table whose value is computed at run time. The values in the column are not stored in the table, but are computed based on the expression that defines the column. An example of the definition of a computed column is: Cost as Price * Quantity .

concatenation

To combine two or more character strings or expressions into a single character string or expression, or to combine two or more binary strings or expressions into a single binary string or expression.

concurrency

A process that allows multiple users to access and change shared data at the same time. SQL Server uses locking to allow multiple users to access and change shared data at the same time without conflicting with each other.

conjunction

A part of speech (such as and or although) used to connect words, phrases, clauses, or sentences. Coordinating conjunctions (and, but, or, nor, for, so, yet) connect and relate words and word groups of equal grammatical rank.

connection

An interprocess communication (IPC) linkage established between a SQL Server 2000 application and an instance of SQL Server 2000. The connection is a network link if the application is on a computer different from the SQL Server 2000 instance. If the application and the SQL Server 2000 instance are on the same computer, the linkage is formed through a local IPC mechanism, such as shared memory. The application uses the IPC linkage to send Transact-SQL statements to SQL Server and to receive result sets, errors, and messages from SQL Server.

constant

A group of symbols that represent a specific data value. The format of a constant depends on the data type of the value it represents. For example, 'abc' is a character string constant, 123 is an integer constant, 'December 16, 1999' is a datetime constant, and 0x02FA is a binary constant.

constraint

A property assigned to a table column that prevents certain types of invalid data values from being placed in the column. For example, a UNIQUE or PRIMARY KEY constraint prevents you from inserting a value that is a duplicate of an existing value, a CHECK constraint prevents you from inserting a value that does not match a search condition, and NOT NULL prevents you from inserting a NULL value.

See also: column-level constraint

continuation media

The backup media used when the initial medium becomes full, allowing continuation of the backup operation.

control-break report

A report that summarizes data in user-defined groups or breaks. A new group is triggered when different data is encountered.

control-of-flow language

Transact-SQL keywords that control the flow of execution of SQL statements and statement blocks in triggers, stored procedures, and batches.

correlated subquery

A subquery that references a column in the outer statement. The inner query is executed for each candidate row in the outer statement.

CPU busy

A SQL Server statistic that reports the time, in milliseconds, the central processing unit (CPU) spent on SQL Server work.

crosstab query

Displays data for summarized values from a field or table, and then groups them by two sets of facts: one down the left side and the other across the top of the datasheet.

cube

A set of data that is organized and summarized into a multidimensional structure defined by a set of dimensions and measures.

See also: multidimensional structure

cube file

See definition for: local cube

cube role

A collection of users and groups with the same access to a cube. A cube role is created when you assign a database role to a cube, and it applies only to that cube.

See also: custom rule, database role

cursor

An entity that maps over a result set and establishes a position on a single row within the result set. After the cursor is positioned on a row, operations can be performed on that row, or on a block of rows starting at that position. The most common operation is to fetch (retrieve) the current row or block of rows.

cursor data type

A special data type used to reference a cursor.

cursor library

A part of the ODBC and DB-Library application programming interfaces (APIs) that implements client cursors. A cursor library is not commonly used in current systems; server cursors are used instead.

custom rollup

An aggregation calculation that is customized for a dimension level or member and overrides the aggregate functions of a cube's measures.

custom rule

In a role, a specification that limits the dimension members or cube cells that users in the role are permitted to access.

See also: cube role, database role

D

data block

In text , ntext , and image data, a data block is the unit of data transferred at one time between an application and an instance of SQL Server 2000. The term is also applied to the units of storage for these data types. In tape backup files, data block is the unit of physical I/O.

data connection

A collection of information required to access a specific database. The collection includes a data source name and logon information. Data connections are stored in a project and are activated when the user performs an action that requires access to the database. For example, a data connection for a SQL Server database consists of the name of the database, the location of the server on which it resides, network information used to access that server, and a user ID and password.

Data Control Language (DCL)

The subset of SQL statements used to control permissions on database objects. Permissions are controlled using the GRANT and REVOKE statements.

data definition

Specifying the attributes, properties, and objects in a database.

data definition language (DDL)

A language, usually part of a database management system, that is used to define all attributes and properties of a database, especially row layouts, column definitions, key columns (and sometimes keying methodology), file locations, and storage strategy.

data dictionary

A set of system tables, stored in a catalog, that includes definitions of database structures and related information, such as permissions.

data dictionary view

A system table.

data explosion

The exponential growth in size of a multidimensional structure, such as a cube, due to the storage of aggregated data.

See also: density, sparsity

data file

In bulk copy operations, the file that transfers data from the bulk copy out operation to the bulk copy in operation. In SQL Server 2000 databases, data files hold the data stored in the database. Every SQL Server 2000 database has at least one primary data file, and can optionally have multiple secondary data files to hold data that does not fit on the primary data file.

See also: log file

data integrity

A state in which all the data values stored in the database are correct. If incorrect data values have been stored in a database, the database is said to have lost data integrity.

data lineage

Information used by Data Transformation Services (DTS), in conjunction with Meta Data Services, that records the history of package execution and data transformations for each piece of data.

data manipulation language (DML)

The subset of SQL statements used to retrieve and manipulate data.

data mart

A subset of the contents of a data warehouse. A data mart tends to contain data focused at the department level, or on a specific business area.

See also: data warehouse

data member

A child member generated for a nonleaf member in a parent-child dimension. A data member contains a value directly associated with a nonleaf member that is independent of the summary value calculated from the descendants of the member. For example, a data member can contain a manager's salary so that either individual salaries or summarized salaries can be displayed.

data modification

An operation that adds, deletes, or changes information in a database using Transact-SQL statements such as INSERT, DELETE, and UPDATE.

data pump

An OLE DB service provider that provides the infrastructure to import, export, and transform data between heterogeneous data stores using Data Transformation Services (DTS).

data scrubbing

Part of the process of building a data warehouse out of data coming from multiple online transaction processing (OLTP) systems. The process must address errors such as incorrect spellings, conflicting spelling conventions between two systems, and conflicting data (such as having two part numbers for the same part).

data source

In ADO and OLE DB, the location of a source of data exposed by an OLE DB provider.

See also: ODBC data source

data source

The source of data for an object such as a cube or dimension. It is also the specification of the information necessary to access source data. It sometimes refers to an object of ClassType clsDataSource .

data source name (DSN)

The name assigned to an ODBC data source. Applications can use DSNs to request a connection to a system ODBC data source, which specifies the computer name and (optionally) the database to which the DSN maps.

data type

An attribute that specifies what type of information can be stored in a column, parameter, or variable. System-supplied data types are provided by SQL Server; user-defined data types can also be created.

See also: base data type

data warehouse

A database specifically structured for query and analysis. A data warehouse typically contains data representing the business history of an organization.

See also: data mart, fact table

data-definition query

An SQL query that contains Data Definition Language (DDL) statements. These are statements that allow you to create or alter objects (such as tables, indexes, views, and so on) in the database and to migrate database objects from Microsoft Access.

database

A collection of information, tables, and other objects organized and presented to serve a specific purpose, such as searching, sorting, and recombining data. Databases are stored in files.

database catalog

The part of a database that contains the definition of all the objects in the database, as well as the definition of the database.

See also: system catalog

database diagram

A graphical representation of the objects in a database. A database diagram can be either a whole or a partial picture of the structure of a database; it includes objects for tables, the columns they contain, and the relationship between them.

database file

One of the physical files that make up a database.

database language

The language used for accessing, querying, updating, and managing data in relational database systems. SQL is a widely used database language. The Microsoft SQL Server implementation of SQL is called Transact-SQL.

database object

A database component. A table, index, trigger, view, key, constraint, default, rule, user-defined data type, or stored procedure in a database. May also refer to a database.

database object

An object (tables, fields, and joins) that is used in an English Query application to answer queries.

database owner

A member of the database administrator role of a database. There is only one database owner. The owner has full permissions in that database and determines the access and capabilities provided to other users.

database project

A collection of one or more data connections (a database and the information needed to access that database). When you create a database project, you can connect to one or more databases through ODBC and view their components through a visual user interface that includes a Database Designer for designing and creating databases and a Query Designer for creating SQL statements for any ODBC-compliant database.

database role

A collection of users and groups with the same access to an Analysis Services database. You can assign a database role to multiple cubes in the database, thereby granting the role's users access to these cubes.

See also: cube role, custom rule

database schema

The names of tables, fields, data types, and primary and foreign keys of a database. Also known as the database structure.

database script

A collection of statements used to create database objects. Transact-SQL scripts are saved as files, usually ending with .sql.

dataset

In OLE DB for OLAP, the set of multidimensional data that is the result of executing a Multidimensional Expressions (MDX) SELECT statement. For more information about datasets, see the OLE DB documentation.

datetime data type

A SQL Server system data type that stores a combined date and time value from January 1, 1753, through December 31, 9999, with an accuracy of three-hundredths of a second, or 3.33 milliseconds.

DBCS

See definition for: double-byte character set (DBCS)

DCL

See definition for: Data Control Language (DCL)

DDL

See definition for: data definition language (DDL)

deadlock

A situation when two users, each having a lock on one piece of data, attempt to acquire a lock on the other's piece. Each user would wait indefinitely for the other to release the lock, unless one of the user processes is terminated. SQL Server detects deadlocks and terminates one user's process.

See also: livelock

decimal data type

Fixed precision and scale numeric data from -10^38 -1 through 10^38 -1.

decision support

Systems designed to support the complex analytic analysis required to discover business trends. The information retrieved from these systems allows manager to make business decisions based on timely and accurate analysis of business trends.

decision tree

A treelike model of data produced by certain data mining methods. Decision trees can be used for prediction.

See also: prediction

declarative referential integrity (DRI)

FOREIGN KEY constraints defined as part of a table definition that enforce proper relationships between tables. The constraints ensure that proper actions are taken when DELETE, INSERT, and UPDATE statements remove, add, or modify primary or foreign key values. The DRI actions enforced by FOREIGN KEY constraints can be supplemented with additional referential integrity logic defined in triggers on a table.

default

A data value, option setting, collation, or name assigned automatically by the system if a user does not specify the value, setting, collation, or name. An action taken automatically at certain events if a user has not specified the action to take.

DEFAULT constraint

A property defined for a table column that specifies a constant to be used as the default value for the column. If any subsequent INSERT or UPDATE statement specifies a value of NULL for the column, or does not specify a value for the column, the constant value defined in the DEFAULT constraint is placed in the column.

default database

The database the user is connected to immediately after logging in to SQL Server.

default instance

The copy of SQL Server that uses the computer name on which it is installed as its name.

See also: named instance, multiple instances

default language

The language that SQL Server 2000 uses for errors and messages if a user does not specify a language. Each SQL Server 2000 login has a default language.

default member

The dimension member used in a query when no member is specified for the dimension. The default member of a dimension is the All member if an (All) level exists, or else an arbitrary member of the highest level. You can also set default members for individual roles in custom rules for dimension security.

See also: All member

default result set

The default mode SQL Server uses to return a result set back to a client. Rows are sent to the client in the order they are placed in the result set, and the application must process the rows in this order. After executing an SQL statement on a connection, the application cannot do anything on the connection other than retrieve the rows in the result set until all the rows have been retrieved. The only other action that an application can perform before the end of the result set is to cancel the remainder of the result set. This is the fastest method to get rows from SQL Server to the client.

See also: firehose cursors

Delete query

A query (SQL statement) that removes rows from one or more tables.

delimiter

In Transact-SQL, characters that indicate the start and end of an object name, using either double quotation marks ("") or brackets ([]).

denormalize

To introduce redundancy into a table in order to incorporate data from a related table. The related table can then be eliminated. Denormalization can improve efficiency and performance by reducing complexity in a data warehouse schema.

See also: star schema

density

The percentage of cells that contain data in a multidimensional structure. Analysis Services stores only cells that contain data. A dense cube requires more storage than a sparse cube of identical structure design.

See also: data explosion, sparsity

deny

Removes a permission from a user account and prevents the account from gaining permission through membership in groups or roles within the permission.

dependencies

The views and procedures that depend on the specified table or view.

descendant

A member in a dimension hierarchy that is related to a member of a higher level within the same dimension. For example, in a Time dimension containing the levels Year, Quarter, Month, and Day, January is a descendant of 1997.

See also: child, parent, ancestor, sibling

destination object

An object in a repository that participates in a relationship such that the object is the destination of the relationship. For example, component is the destination object in the relationship project has component .

See also: origin object

device

See definition for: file

dictionary entry

Defined words in the English Query dictionary. You can make additions to the dictionary through the English Query domain editor by specifying the word, its part of speech, and an optional irregular form.

differential database backup

A database backup that records only those changes made to the database since the last full database backup. A differential backup is smaller, and is faster to restore than a full backup and has minimal effect on performance.

dimension

A structural attribute of a cube, which is an organized hierarchy of categories (levels) that describe data in the fact table. These categories typically describe a similar set of members upon which the user wants to base an analysis. For example, a geography dimension might include levels for Country, Region, State or Province, and City.

See also: measure, virtual dimension, level, member group

dimension hierarchy

One of the hierarchies of a dimension.

See also: hierarchy

dimension table

A table in a data warehouse whose entries describe data in a fact table. Dimension tables contain the data from which dimensions are created.

See also: primary dimension table, fact table

direct connect

The state of being connected to a back-end database, so that any changes you make to a database diagram automatically update your database when you save the diagram or selected items in it.

direct object

A noun (along with any of its modifiers) naming whom or what after a transitive verb. For example, the customer buys the products (the products is the direct object.)

direct response mode

The default mode in which SQL Server statistics are gathered separately from the SQL Server Statistics display. Data is available immediately to SQL Server Performance Monitor; however, the statistics displayed are one period behind the statistics retrieved.

dirty pages

Buffer pages that contain modifications that have not been written to disk.

dirty read

Reads that contain uncommitted data. For example, transaction1 changes a row. Transaction2 reads the changed row before transaction1 commits the change. If transaction1 rolls back the change, transaction2 has read a row that never logically existed.

distribute

To move transactions or snapshots of data from the Publisher to Subscribers, where they are applied to the destination tables in the subscription databases.

distributed query

A single query that accesses data from multiple data sources.

distribution database

A database on the Distributor that stores data for replication including transactions, snapshot jobs, synchronization status, and replication history information.

distribution retention period

The distribution retention period determines the amount of information stored for a replication agent and the length of time subscriptions will remain active in the distribution database. When the distribution retention period is exceeded, the Distribution Clean Up Agent runs.

Distributor

A server that hosts the distribution database and stores history data, and/or transactions and meta data.

See also: local Distributor, remote Distributor

DML

See definition for: data manipulation language (DML)

domain

In Windows 2000 security, a collection of computers grouped for viewing and administrative purposes that share a common security database. In relational databases, the set of valid values allowed in a column.

domain integrity

An integrity mechanism that enforces the validity of entries for a given column. The mechanism, such as the CHECK constraint, can restrict the possible data values by data type, format, or range of values allowed.

double-byte character set (DBCS)

A character set that generally uses two bytes to represent a character, allowing more than 256 characters to be represented. DBCSs are typically used in environments that use ideographic writing systems, such as Japanese, Korean, and Chinese.

DRI

See definition for: declarative referential integrity (DRI)

drill down/drill up

A technique for navigating through levels of data ranging from the most summarized (up) to the most detailed (down). For example, when viewing the details of sales data by year, a user can drill down to display sales data by quarter, and further to display data by month.

drill through

To retrieve the detailed data from which the data in a cube cell was summarized.

DSN

See definition for: data source name (DSN)

DSN-less connection

A type of data connection that is created based on information in a data source name (DSN), but is stored as part of a project or application. DSN-less connections are especially useful for Web applications because they enable you to move the application from one server to another without recreating the DSN on the new server.

DTS package

An organized collection of connections, Data Transformation Services (DTS) tasks, DTS transformations, and workflow constraints defined by the DTS object model and assembled either with a DTS tool or programmatically.

DTS package template

A model Data Transformation Services (DTS) package. The template is used to help create and configure a particular type of package.

dump

See definition for: backup

dump file

See definition for: backup file

dynamic cursor

A cursor that can reflect data modifications made to the underlying data while the cursor is open. Updates, deletes, and inserts made by users are reflected in the dynamic cursor.

dynamic filter

Merge replication filters that restrict data based on a system function or user-defined function (for example: SUSER_SNAME()).

dynamic locking

The process used by SQL Server to determine the most cost-effective locks to use at any one time.

dynamic recovery

The process that detects and/or attempts to correct software failure or loss of data integrity within a relational database management system (RDBMS).

dynamic snapshot

A snapshot of a merge publication with dynamic filters that is applied using bulk copy files to improve performance.

dynamic SQL statements

In Embedded SQL for C, an SQL statement built and executed at run time.

E

encrypted trigger

A trigger that is created with an optional encryption parameter that encrypts the definition text and cannot be decrypted. Encryption makes the information indecipherable to protect it from unauthorized viewing or use.

encryption

A method for keeping sensitive information confidential by changing data into an unreadable form.

English Query

Refers to a Microsoft application development product that allows users to ask questions in English, rather than in a computer language such as SQL. For example, you might ask, "How many customers bought products last year?" rather than prepare an equivalent SQL statement.

English Query application

An application based on a relational database that gives end users the ability to pose queries in English, rather than in a computer language such as SQL.

entity

In English Query, an entity is a real-world object, referred to by a noun (person, place, thing, or idea), such as people, products, shipments, cities, and so on. Entities are semantic objects.

entity integrity

A state in which all the rows in a database have a not-null primary key value, all tables have primary keys, and no table has any duplicate primary key values. This ensures that there are no duplicate entries for anything represented in the database.

enumeration

A data type of a property. It specifies that a property value should support a fixed set of constant strings or integer values.

equijoin

A join in which the values in the columns being joined are compared for equality, and all columns are included in the results.

error log

A text file that records system information from SQL Server.

error state number

A number associated with SQL Server 2000 messages that helps Microsoft support engineers find the specific code location that issued the message. This can be helpful in diagnosing errors that may be generated from multiple locations in the SQL Server 2000 code.

escape character

A character used to indicate that another character in an expression is meant literally and not as an operator. For example, in SQL, the character "%" is used as a wildcard character to mean "any number of characters in this position." However, if you want to search for a string such as "10%" (ten percent), you cannot specify "10%" alone as a search string, because the "%" would be interpreted as "any number of characters in addition to 10." By specifying an escape character, you can flag instances where "%" specifically means percent. For example, if you specify the escape character "#", you can indicate a search string of "10#%" to mean "ten percent."

exclusive lock

A lock that prevents any other transaction from acquiring a lock on a resource until the original lock on the resource is released at the end of the transaction. An exclusive lock is always applied during an update operation (INSERT, UPDATE, or DELETE).

explicit transaction

A group of SQL statements enclosed within transaction delimiters. The first delimiter must be either BEGIN TRANSACTION or BEGIN DISTRIBUTED TRANSACTION, and the end delimiter must be one of the following:

COMMIT TRANSACTION

COMMIT WORK

ROLLBACK TRANSACTION

ROLLBACK WORK

SAVE TRANSACTION.

expression

In SQL, a combination of symbols and operators that evaluate to a single data value. Simple expressions can be a constant, variable, column, or scalar function. Complex expressions are one or more simple expressions connected by operators.

extended stored procedure

A function in a dynamic link library (DLL) that is coded using the SQL Server 2000 Extended Stored Procedure API. The function can then be invoked from Transact-SQL using the same statements that are used to execute Transact-SQL stored procedures. Extended stored procedures can be built to perform functionality not possible with Transact-SQL stored procedures.

extent

The unit of space allocated to a SQL Server object, such as a table or index, whenever the object needs more space. In SQL Server 2000, an extent is eight contiguous pages.

F

fact

A row in a fact table in a data warehouse. A fact contains values that define a data event such as a sales transaction.

fact table

A central table in a data warehouse schema that contains numerical measures and keys relating facts to dimension tables. Fact tables contain data that describes specific events within a business, such as bank transactions or product sales.

See also: data warehouse, dimension table, star join, star schema

Federal Information Processing Standard (FIPS)

Standards that apply to computer systems purchased by the United States government. Each FIPS standard is defined by the National Institute of Standards and Technology (NIST). The current standard for SQL products is FIPS 127-2, which is based on the ANSI SQL-92 standard. ANSI SQL-92 is aligned with ISO/IEC SQL-92.

fetch

An operation that retrieves a row or block of rows from a cursor. Transact-SQL batches, stored procedures, and triggers use the FETCH statement to fetch from Transact-SQL cursors. Applications use application programming interface (API) fetch functions.

field

An area in a window or record that stores a single data value. Some databases, such as Microsoft Access, use field as a synonym for column.

field length

In bulk copy, the maximum number of characters needed to represent a data item in a bulk copy character format data file.

field terminator

In bulk copy, one or more characters marking the end of a field or row, separating one field or row in the data file from the next.

file

In SQL Server databases, a basic unit of storage for a database. One database can be stored in several files. SQL Server uses three types of files: data files (which store data), log files (which store transaction logs), and backup files (which store backups of a database).

file DSN

Stores connection information for a database in a file that is saved on your computer. The file is a text file with the extension .dsn. The connection information consists of parameters and corresponding values that the ODBC Driver Manager uses to establish a connection.

file storage type

Defines the storage format used in the data file that transfers data from a bulk copy out operation to a bulk copy in operation. In native mode files, all data is stored using the same internal structures that SQL Server 2000 uses to store the data in a database. In character mode files, all data is converted to character strings.

filegroup

In SQL Server, a named collection of one or more files that forms a single unit of allocation or for administration of a database.

fill factor

An attribute of an index that defines the amount of free space on each page of the index. FILLFACTOR accommodates future expansion of table data and reduces the potential for page splits. FILLFACTOR is a value from 1 through 100 that specifies the percentage of the index page to be left empty.

filter

A set of criteria that controls the set of records returned as a result set. Filters can also define the sequence in which rows are returned.

filtering

The ability to restrict data based upon criteria set in the WHERE clause of an SQL statement. For replication, filtering occurs on table articles defined in a publication. The result is partitions of data that can be published to Subscribers.

See also: partitioning, vertical filtering

FIPS

See definition for: Federal Information Processing Standard (FIPS)

firehose cursor

An obsolete term for default result set.

firehose cursors

Obsolete term for default result sets.

See also: default result set

fixed database role

A predefined role that exists in each database. The scope of the role is limited to the database in which it is defined.

fixed server role

A predefined role that exists at the server level. The scope of the role is limited to the SQL Server instance in which it is defined.

FK

See definition for: foreign key (FK)

flattened interface

An interface created to combine members of multiple interfaces.

flattened rowset

A multidimensional data set presented as a two-dimensional rowset in which unique combinations of elements of multiple dimensions are combined on an axis. For more information, see the OLE DB documentation.

float data type

A data type that holds floating-point number data from -1.79E + 308 through 1.79E + 308. float , double precision , and float(n) are SQL Server float data types.

foreign key (FK)

The column or combination of columns whose values match the primary key (PK) or unique key in the same or another table. Also called the referencing key.

foreign table

A table that contains a foreign key.

forward-only cursor

A cursor that cannot be scrolled; rows can be read only in sequence from the first row to the last row.

fragmentation

Occurs when data modifications are made. You can reduce fragmentation and improve read-ahead performance by dropping and re-creating a clustered index.

full outer join

A type of outer join in which all rows in all joined tables are included, whether they are matched or not.

full-text catalog

Stores all of the full-text indexes for tables within a database.

full-text enabling

The process of allowing full-text querying to occur on the current database.

full-text index

The portion of a full-text catalog that stores all of the full-text words and their locations for a given table.

full-text query

As a SELECT statement, a query that searches for words, phrases, or multiple forms of a word or phrase in the character-based columns (of char , varchar , text , ntext , nchar , or nvarchar data types). The SELECT statement returns those rows meeting the search criteria.

full-text service

The SQL Server component that performs the full-text querying.

function

A piece of code that operates as a single logical unit. A function is called by name, accepts optional input parameters, and returns a status and optional output parameters. Many programming languages support functions, including C, Visual Basic, and Transact-SQL. Transact-SQL supplies built-in functions, which cannot be modified, and supports user-defined functions, which can be created and modified by users.

G

global default

A default that is defined for a specific database and is shared by columns of different tables.

global properties

General properties of an English Query application, such as the default year setting or the start date of the fiscal year.

global rule

A rule that is defined for a specific database and is shared by columns of different tables.

global subscriptions

A subscription to a merge publication with an assigned priority value used for conflict detection and resolution.

global variable

In SQL Server, a variable that can be referenced by multiple Data Transformation Services (DTS) tasks. In earlier versions of SQL Server, the term referred to the Transact-SQL system functions whose names start with two at signs (@@).

grant

Applies permissions to a user account, which allows the account to perform an activity or work with data.

granularity

The degree of specificity of information contained in a data element. A fact table that has fine granularity contains many discrete facts, such as individual sales transactions. A table that has coarse granularity stores facts that are summaries of individual elements, such as sales totals per day.

guest

A special user account that is present in all SQL Server 2000 databases and cannot be removed from any database. If a connection is made using a login that has not been assigned a user account in a database and the connection references objects in that database, it has the permissions assigned only to the guest account in that database.

H

heterogeneous data

Data stored in multiple formats. For example, data stored in a SQL Server database, a text file, and an Excel spreadsheet.

hierarchy

A logical tree structure that organizes the members of a dimension such that each member has one parent member and zero or more child members.

See also: level, dimension hierarchy

HOLAP

See definition for: hybrid OLAP (HOLAP)

homogeneous data

Data that comes from multiple data sources that are all managed by the same software (for example, data that comes from several Exchange spreadsheets, or data that comes from several SQL Server 2000 instances). A SQL Server 2000 distributed query is homogeneous if all the data comes from SQL Server 2000 instances.

hop

In data communications, one segment of the path between routers on a geographically dispersed network. A hop is comparable to one "leg" of a journey that includes intervening stops between the starting point and the destination. The distance between each of those stops (routers) would be a communications hop.

horizontal partitioning

To segment a single table into multiple tables based on selected rows. Each of the multiple tables has the same columns but fewer rows.

See also: partitioning

HTML

See definition for: Hypertext Markup Language (HTML)

huge dimension

In Analysis Services, a dimension that contains more than approximately ten million members. Huge dimensions must use relational OLAP (ROLAP) storage mode.

See also: very large dimension

hybrid OLAP (HOLAP)

A storage mode that uses a combination of multidimensional data structures and relational database tables to store multidimensional data. Analysis Services stores aggregations for a HOLAP partition in a multidimensional structure and stores facts in a relational database.

See also: multidimensional OLAP (MOLAP), relational OLAP (ROLAP)

Hypertext Markup Language (HTML)

A system of marking up, or tagging, a document so that it can be published on the World Wide Web. Documents prepared in HTML include reference graphics and formatting tags. You use a Web browser (such as Microsoft Internet Explorer) to view these documents.

I

identifier

The name of an object in a database. An identifier can be from 1 through 128 characters.

identity column

A column in a table that has been assigned the identity property. The identity property generates unique numbers.

identity property

A property that generates values that uniquely identify each row in a table. When inserting rows into a table that has an identity column, SQL Server generates the next identity value automatically based on the last used identity value and the increment value specified during column creation.

idle time

A SQL Server 2000 Agent condition that defines the level of CPU usage by the SQL Server 2000 database engine that constitutes an idle state. SQL Server 2000 Agent jobs can then be created to run whenever the database engine CPU usage falls below the level defined in the idle time definition. This minimizes the impact the SQL Server Agent jobs may have on other tasks accessing the database.

IEC

See definition for: International Electrotechnical Commission (IEC)

image data type

A SQL Server variable-length binary data type with a maximum length of 2^31 - 1 (2,147,483,647) bytes.

immediate updating

An option available with snapshot replication and transactional replication that allows data modifications to be made to replicated data at the Subscriber. The data modifications are then immediately propagated to the Publisher using two-phase commit protocol (2PC).

immediate updating Subscribers

See definition for: immediate updating subscriptions

immediate updating subscriptions

A subscription to a snapshot or transactional publication for which the user is able to make data modifications at the Subscriber. The data modifications are then immediately propagated to the Publisher using two-phase commit protocol (2PC).

implicit transaction

A connection option in which each SQL statement executed by the connection is considered a separate transaction.

implied permission

Permission to perform an activity specific to a role. Implied permissions cannot be granted, revoked, or denied.

incremental update

The set of operations that either adds new members to an existing cube or dimension, or adds new data to a partition. One of three processing options for a cube or partition. One of two processing options for a dimension.

See also: refresh data, process

index

In a relational database, a database object that provides fast access to data in the rows of a table, based on key values. Indexes can also enforce uniqueness on the rows in a table. SQL Server supports clustered and nonclustered indexes. The primary key of a table is automatically indexed. In full-text search, a full-text index stores information about significant words and their location within a given column.

index ORing

An execution strategy that consists of looking up rows of a single table using several indexes, followed by producing the result (by combining the partial results). Usually corresponds to an OR in the WHERE <search_conditions>. For example, WHERE R.a = 6 OR R.b = 7 with indexes on columns R.a and R.b.

index page

A database page containing index rows.

indirect object

A word (or words) naming the one (or ones) indirectly affected by the action of the verb. For example, Emily sliced me some cheese. (Me is the indirect object.)

information model

An object-oriented schema that defines meta data constructs used to specify the structure and behavior of an application, process, component, or software artifact.

initial media

The first medium in each media family.

initial snapshot

Files including schema and data, constraints, extended properties, indexes, triggers and system tables necessary for replication. The initial snapshot is transferred to Subscribers when implementing replication.

See also: synchronization

inner join

An operation that retrieves rows from multiple source tables by comparing the values from columns shared between the source tables. An inner join excludes rows from a source table that have no matching rows in the other source tables.

input member

A member whose value is loaded directly from the data source instead of being calculated from other data.

See also: calculated member

input set

The set of data provided to a Multidimensional Expressions (MDX) value expression upon which the expression operates. For more information about set value expressions, see the OLE DB documentation.

input source

Any table, view, or schema diagram used as an information source for a query.

insensitive cursor

A cursor that does not reflect data modification made to the underlying data by other users while the cursor is open.

Insert query

A query that copies specific columns and rows from one table to another or to the same table.

Insert Values query

A query (SQL statement) that creates a new row and inserts values into specified columns.

instance

A copy of SQL Server running on a computer. A computer can run multiple instances of SQL Server 2000. A computer can run only one instance of SQL Server version 7.0 or earlier, although in some cases it can also be running multiple instances of SQL Server 2000.

int (integer) data type

A SQL Server system data type that holds whole numbers from -2^31 (-2,147,483,648) through 2^31 - 1 (2,147,483,647).

integer

In SQL Server 2000, a data type category that includes the bigint , int , smallint , and tinyint data types.

integrated security

See definition for: Windows Authentication

integrity constraint

A property defined on a table that prevents data modifications that would create invalid data.

intent lock

A lock placed on one level of a resource hierarchy to protect shared or exclusive locks on lower-level resources. For example, before a SQL Server 2000 database engine task applies shared or exclusive row locks within a table, it places an intent lock on the table. If another task tries to apply a shared or exclusive lock at the table level, it is blocked by the table-level intent lock held by the first task. The second task does not have to check for individual page or row locks before locking the table, it only has to check for an intent lock on the table.

interactive structured query language (ISQL)

An interactive command prompt utility provided with SQL Server that allows users to execute Transact-SQL statements or batches from a server or workstation and view the results returned.

interface

A defined set of properties, methods, and collections that form a logical grouping of behaviors and data. Classes are defined by the interfaces that they implement. An interface may be implemented by many different classes.

interface implication

If an interface implies another interface, then any class that implements the first interface must also implement the second interface. Interface implication is used in an information model to get some of the effects of multiple inheritance.

internal identifier

A more compact form of an object identifier in a repository. An internal identifier is guaranteed to be unique only within a single repository.

See also: object identifier

International Electrotechnical Commission (IEC)

One of two international standards bodies responsible for developing international data communications standards. The International Electrotechnical Commission (IEC) works closely with the International Organization for Standardization (ISO) to define standards of computing. They jointly published the ISO/IEC SQL-92 standard for SQL.

International Organization for Standardization (ISO)

One of two international standards bodies responsible for developing international data communications standards. International Organization for Standardization (ISO) works closely with the International Electrotechnical Commission (IEC) to define standards of computing. They jointly published the ISO/IEC SQL-92 standard for SQL.

Internet-enabled

A publication setting that enables replication to Internet Subscribers.

interprocess communication (IPC)

A mechanism through which operating system processes and threads exchange data and messages. IPCs include local mechanisms such as Windows shared memory, or network mechanisms such as Windows Sockets.

IPC

See definition for: interprocess communication (IPC)

irregular form

A form of an English word that is an exception to the standard rules of inflection. For example, the past-tense of run is ran , not runned ; likewise, the plural of alumnus is alumni , not alumnuses .

irregular form type

The type of inflection (plural, past tense, or unknown) for which a word uses an irregular form. For example, the word woman has an irregular plural form (women), as you don't form the plural of woman in the standard way by adding -s or -es.

irregular noun

A noun plural that is not formed by adding -s or -es, such as men or women.

irregular verb

A verb that is not inflected in the usual ways. One example of an irregular verb is one that does not add -ed to the root form to create the past tense and past participle. There are several common types of irregular verbs classified according to how they indicate past tense and past participle: vowel changes (begin, began, begun); -en added (beat, beat, beaten); vowel changes (spin, spun, spun); -d changes to -t (lend, lent, lent); no change (put, put, put).

ISO

See definition for: International Organization for Standardization (ISO)

isolation level

The property of a transaction that controls the degree to which data is isolated for use by one process and guarded against interference from other processes. Setting the isolation level defines the default locking behavior for all SELECT statements in your SQL Server session.

ISQL

See definition for: interactive structured query language (ISQL)

J

job

A specified series of operations, called steps, performed sequentially by SQL Server Agent.

join

As a verb, to combine the contents of two or more tables and produce a result set that incorporates rows and columns from each table. Tables are typically joined using data that they have in common. As a noun, the process or result of joining tables, as in the term "inner join" to indicate a particular method of joining tables.

See also: join column, logical join

join column

A column referenced in a join condition.

See also: join

join condition

A comparison clause that specifies how tables are related by their join columns.

join field

See definition for: join column

join filter

A row filter used in merge replication that defines a relationship between two tables that will be enforced during synchronization, which is similar to specifying a join between two tables.

join operator

A comparison operator in a join condition that determines how the two sides of the condition are evaluated and which rows are returned.

join path

A series of joins indicating how two tables are related. For example, Sales.SalesRepIDSalesReps.ID, SalesReps.BranchIDBranches.ID.

join table

See definition for: junction table

junction table

A table that establishes a relationship between other tables. The junction table contains foreign keys referencing the tables that form the relationship. For example, an OrderParts junction table can show what parts shipped with each order by having foreign keys to an Orders table and a Parts table.

K

kernel

In SQL Server 2000, a subset of the storage engine that is referenced in some error messages. In Windows 2000, the core of the operating system that performs basic operations.

key

A column or group of columns that uniquely identifies a row (PRIMARY KEY), defines the relationship between two tables (FOREIGN KEY), or is used to build an index.

See also: key column

key column

A column referenced by a primary, foreign, or index key.

See also: key

key range lock

A lock used to lock ranges between records in a table to prevent phantom insertions or deletions into a set of records. Ensures serializable transactions.

keyset-driven cursor

A cursor that shows the effects of updates made to its member rows by other users while the cursor is open, but does not show the effects of inserts or deletes.

keyword

A reserved word in SQL Server that performs a specific function, such as to define, manipulate, and access database objects.

L

large level

A dimension level that contains a number of members that equals or exceeds the threshold for large levels. This threshold is variable and is set in the Properties dialog box of Analysis Manager.

latency

The amount of time that elapses when a data change is completed at one server and when that change appears at another (for example, the time between when a change is made at a Publisher and when it appears at the Subscriber).

LCID

See definition for: locale identifier (LCID)

leaf

In a tree structure, an element that has no subordinate elements. For example, in Analysis Services, a leaf is a dimension member that has no descendants.

See also: nonleaf

leaf level

The bottom level of a clustered or nonclustered index. In a clustered index, the leaf level contains the actual data pages of the table. In a nonclustered index, the leaf level either points to data pages or points to the clustered index (if one exists), rather than containing the data itself.

leaf member

A dimension member without descendants.

left outer join

A type of outer join in which all rows from the left-most table in the JOIN clause are included. When rows in the left table are not matched by rows in the right table, all result set columns that come from the right table are assigned a value of NULL.

level

The name of a set of members in a dimension hierarchy such that all members of the set are at the same distance from the root of the hierarchy. For example, a time hierarchy may contain the levels Year, Month, and Day.

See also: dimension, hierarchy

level hierarchy

See definition for: dimension hierarchy

library

In Analysis Services, a folder that contains shared objects such as shared dimensions that can be used by multiple objects within a database.

linked cube

A cube based on a cube defined on another Analysis server.

See also: publishing server, source cube, subscribing server

linked server

A definition of an OLE DB data source used by SQL Server 2000 distributed queries. The linked server definition specifies the OLE DB provider required to access the data, and includes enough addressing information for the OLE DB provider to connect to the data. Any rowsets exposed by the OLE DB data source can then be referenced as tables, called linked tables, in SQL Server 2000 distributed queries.

See also: local server

linked table

An OLE DB rowset exposed by an OLE DB data source that has been defined as a linked server for use in SQL Server 2000 distributed queries. The rowsets exposed by the linked server can be referenced as tables in distributed queries.

linking table

A table that has associations with two other tables and is used indirectly as an association between those two tables.

livelock

A request for an exclusive lock that is repeatedly denied because a series of overlapping shared locks keeps interfering. SQL Server detects the situation after four denials and refuses further shared locks. A livelock also occurs when read transactions monopolize a table or page, forcing a write transaction to wait indefinitely.

See also: deadlock

local cube

A cube created and stored with the extension .cub on a local computer using PivotTable Service.

local Distributor

A server that is configured as both a Publisher and a Distributor for SQL Server Replication.

See also: Distributor, remote Distributor

local group

A group in Windows NT 4.0 or Windows 2000 containing user accounts and global groups from the domain group in which they are created and any trusted domain. Local groups cannot contain other local groups.

local login identification

The identification (ID) a user must use to log in to a local server. A login ID can have up to 128 characters. The characters can be alphanumeric; however, the first character must be a letter (for example, CHRIS or TELLER8).

local server

In SQL Server 2000 connections, an instance of SQL Server 2000 running on the same computer as the application.

When resolving references to database objects in a Transact-SQL statement, the instance of SQL Server 2000 executing the statement.

In SQL Server 2000 distributed queries, the instance of SQL Server 2000 executing the distributed query. The local server then accesses any linked servers referenced in the query.

In SQL Server 2000 remote stored procedures, the instance of SQL Server executing an EXEC statement that references a remote stored procedure. The local server then passes the execution request to the remote server on which the remote stored procedure resides.

See also: linked server, remote server

local subscription

A subscription to a merge publication using the priority value of the Publisher for conflict detection and resolution.

local variable

A user-defined variable that has an assigned value. A local variable is defined with a DECLARE statement, assigned an initial value with a SELECT or SET statement, and used within the statement batch or procedure in which it was declared.

locale

The Windows operating-system attribute that defines certain behaviors related to language. The locale defines the code page, or bit patterns, used to store character data, and the order in which characters are sorted. It also defines language-specific items such as the format used for dates and time and the character used to separate decimals in numbers. Each locale is identified by a unique number, called a locale identifier or LCID. SQL Server 2000 collations are similar to locales in that the collations define language-specific types of behaviors for instances of SQL Server 2000.

See also: collation, locale identifier (LCID)

locale identifier (LCID)

A number that identifies a Windows-based locale.

See also: locale

lock

A restriction on access to a resource in a multiuser environment. SQL Server locks users out of a specific row, column, or file automatically to maintain security or prevent concurrent data modification problems.

lock escalation

The process of converting many fine-grain locks into fewer coarse-grain locks, thereby reducing system overhead.

log file

A file or set of files containing a record of the modifications made in a database.

See also: data file

logical join

In XML View Mapper, a description of correspondence between tables based on equivalent values in one or more fields. Logical joins are automatically created during import based on table relationships. User-defined logical joins can be added through the user interface to describe additional relationships.

See also: join

logical name

A name used by SQL Server to identify a file. A logical name for a file must correspond to the rules for identifiers and can have as many as 30 characters (for example, ACCOUNTING or LIBRARY).

logical operators

The operators AND, OR, and NOT. Used to connect search conditions in WHERE clauses.

login (account)

An identifier that gives a user permission to connect to SQL Server 2000 using SQL Server Authentication. Users connecting to SQL Server 2000 using Windows NT Authentication are identified by their Windows 2000 login, and do not need a separate SQL Server 2000 login.

Note: When possible, use Windows Authentication.

login security mode

A security mode that determines the manner in which a SQL Server 2000 instance validates a login request. There are two types of login security: Windows Authentication and SQL Server authentication.

lookup table

A table, either in a database or hard-coded in the English Query application, that contains codes and the English word or phrase they represent. For example, a gender lookup table contains the following code and English descriptions:

M, Male

M

machine DSN

Stores connection information for a database in the system registry. The connection information consists of parameters and corresponding values that the ODBC Driver Manager uses to establish a connection.

Make Table query

A query (SQL statement) that creates a new table and then creates rows in it by copying rows from an existing table.

many-to-many relationship

A relationship between two tables in which rows in each table have multiple matching rows in the related table. Many-to-many relationships are maintained by using a third table called a junction table and adding the primary key columns from each of the other two tables to this table.

many-to-one relationship

A relationship between two tables in which one row in one table can relate to many rows in another table.

MAPI

See definition for: Messaging Application Programming Interface (MAPI)

master database

The database that controls the operation of each instance of SQL Server. It is installed automatically with each instance of SQL Server and keeps track of user accounts, remote user accounts, and remote servers that each instance can interact with. It also tracks ongoing processes, configurable environment variables, system error messages, tapes and disks available on the system, and active locks.

master definition site

See definition for: Publisher

master file

The file installed with earlier versions of SQL Server used to store the master , model , and tempdb system databases and transaction logs and the pubs sample database and transaction log.

master site

See definition for: Distributor

MDX

See definition for: Multidimensional Expressions (MDX)

measure

In a cube, a set of values that are based on a column in the cube's fact table and are usually numeric. Measures are the central values that are aggregated and analyzed.

See also: dimension

measurement

In English Query, an option in the Adjective Phrasing dialog box. Using it, you can specify some measurement that is represented in an entity. For example, the relationship expressed as the city is some temperature might be represented by an Area entity and a Temperature entity.

media description

The text describing the media set.

See also: media set

media family

All media in a set written by a single device (for example, an initial medium and all continuation media, if any).

See also: media set

media header

Provides information about the backup media.

media name

The descriptive name for the entire backup media set.

media set

All media involved in a backup operation.

See also: media description, media family

member

An item in a dimension representing one or more occurrences of data. A member can be either unique or nonunique. For example, 1997 and 1998 represent unique members in the year level of a time dimension, whereas January represents nonunique members in the month level because there can be more than one January in the time dimension if it contains data for more than one year.

See also: virtual dimension

member delegation

A modeling concept that describes how interface members are mapped from one interface to another.

member group

A system-generated parent of a collection of consecutive dimension members.

See also: dimension

member key column

A dimension level's property that specifies the identifiers of the members of the level. The value of this property can specify a column that contains the identifiers or an expression that evaluates to the identifiers.

See also: member name column, member variable

member name column

A dimension level's property that specifies the names of the members of the level. The value of his property can specify a column that contains the names or an expression that evaluates to the names.

See also: member key column, member variable

member property

Information about the members of a dimension level in addition to that contained in the dimension (for example, the color of a product or the telephone number of a sales representative). For more information about member properties, see the OLE DB documentation.

See also: virtual dimension

member variable

The value used internally by Analysis Services to identify a dimension member. The MemberKeyColumn property specifies the member variables for a dimension. For example, a number from 1 through 12 could be the member variable that corresponds to a month of the year.

See also: member key column, member name column

memo

A type of column containing long strings of text, typically more than 255 characters. This is the Access equivalent of a SQL Server text data type.

merge

The operation that combines two partitions into a single partition.

merge replication

A type of replication that allows sites to make autonomous changes to replicated data, and at a later time, merge changes and resolve conflicts when necessary.

See also: snapshot replication, transactional replication

message number

A number that identifies a SQL Server 2000 error message.

Messaging Application Programming Interface (MAPI)

An e-mail application programming interface (API).

meta data

Information about the properties of data, such as the type of data in a column (numeric, text, and so on) or the length of a column. It can also be information about the structure of data or information that specifies the design of objects such as cubes or dimensions.

method

A function that performs an action by using a COM object, as in SQL-DMO, OLE DB, and ActiveX Data Objects (ADO).

See also: Component Object Model (COM)

mining model

An object that contains the definition of a data mining process and the results of the training activity. For example, a data mining model may specify the input, output, algorithm, and other properties of the process and hold the information gathered during the training activity, such as a decision tree.

mining model training

The process a data mining model uses to estimate model parameters by evaluating a set of known and predictable data. Also, the act of causing a mining model to evaluate training data.

See also: training data set

mirroring

The process for protecting against the loss of data due to disk failure by maintaining a fully redundant copy of data on a separate disk. Mirroring can be implemented at several levels: in SQL Server 2000, in the operating system, and in the disk controller hardware.

Mixed Mode

Combines Windows Authentication and SQL Server Authentication. Mixed Mode allows users to connect to an instance of SQL Server, through either a Windows NT 4.0 or Windows 2000 user account or a SQL Server login.

Note: When possible, use Windows Authentication.

model

In English Query, a model is the collection of all information that is known about the objects in the English Query application. This information includes: the specified database objects (such as tables, fields, and joins); semantic objects (such as entities, the relationships between them, additional dictionary entries); and global domain default options.

model database

A database installed with SQL Server that provides the template for new user databases. SQL Server 2000 creates a new database by copying in the contents of the model database and then expanding it to the size requested.

model dependency

A relationship between two or more models in which one model is dependent on the information of another model.

module

A group of objects in a project. You can move objects between modules in a project, thus organizing those objects for a dispersed development environment.

modulo

An arithmetic operator that provides the integer remainder after a division involving two integers.

MOLAP

See definition for: multidimensional OLAP (MOLAP)

money data type

A SQL Server system data type that stores monetary values from -2^63 (-922,337,203,685,477.5808) through 2^63 - 1 (+922,337,203,685,477.5807), with accuracy to a ten-thousandth of a monetary unit.

Multidimensional Expressions (MDX)

A syntax used for defining multidimensional objects and querying and manipulating multidimensional data.

multidimensional OLAP (MOLAP)

A storage mode that uses a proprietary multidimensional structure to store a partition's facts and aggregations or a dimension. The data of a partition is completely contained within the multidimensional structure.

See also: relational OLAP (ROLAP), hybrid OLAP (HOLAP)

multidimensional structure

A database paradigm that treats data not as relational tables and columns, but as information cubes that contain dimension and summary data in cells. Each cell is addressed by a set of coordinates that specify a position in the structure's dimensions. For example, the cell at coordinates {SALES, 1997, WASHINGTON, SOFTWARE} would contain the summary of software sales in Washington in 1997.

See also: cube

multiple inheritance

A modeling term that describes how an interface receives the characteristics of more than one parent interface.

multiple instances

Multiple copies of SQL Server running on the same computer. There can be one default instance, which can be any version of SQL Server. There can be multiple named instances of SQL Server 2000.

See also: default instance, named instance

multithreaded server application

An application that creates multiple threads within a single process to service multiple user requests at the same time.

multiuser

The ability of a computer to support many users operating at the same time, while providing the computer system's full range of capabilities to each user.

N

name phrasing

An English description of a relationship in which one entity is the name of another entity. For example, in the sentence "Custnames are the names of Customers", Custnames and Customers are both entities.

named instance

An installation of SQL Server 2000 that is given a name to differentiate it from other named instances and from the default instance on the same computer. A named instance is identified by the computer name and instance name.

See also: default instance, multiple instances

named pipe

An interprocess communication (IPC) mechanism that SQL Server uses to provide communication between clients and servers. Named pipes permit access to shared network resources.

named set

A set of dimension members or a set expression that is created for reuse, for example, in Multidimensional Expressions (MDX) queries.

naming relationship

A naming convention that identifies the destination objects of that relationship by name.

native format

Bulk copy data files in which the data is stored using the same internal data structures SQL Server uses to store data in SQL Server databases. Bulk copy can quickly process native mode files because it does not have to convert data when transferring it between SQL Server and the bulk copy data file.

See also: character format

nchar data type

A fixed-length Unicode data type with a maximum of 4,000 characters. Unicode characters use 2 bytes per character and support all international characters.

nested query

A SELECT statement that contains one or more subqueries, or another term for subquery.

nested table

A data mining model configuration in which a column of a table contains a table.

Net-Library

A SQL Server communications component that isolates the SQL Server client software and database engine from the network APIs. The SQL Server client software and database engine send generic network requests to a Net-Library, which translates the request to the specific network commands of the protocol chosen by the user.

nickname

When used with merge replication system tables, a name for another Subscriber that is known to already have a specified generation of updated data. Used to avoid sending an update to a Subscriber that has already received those changes.

niladic functions

Functions that do not have any input parameters. Most niladic SQL Server functions return system information.

noise word

Words that do not participate in a full-text query search. For example, a, and, the, and so on.

nonclustered index

An index in which the logical order of the index is different than the physical, stored order of the rows on disk.

nonleaf

In a tree structure, an element that has one or more subordinate elements. For example, in Analysis Services, a dimension member that has one or more descendants. In SQL Server indexes, an intermediate index node that points to other intermediate nodes or leaf nodes.

See also: leaf

nonleaf member

A member with one or more descendants.

nonrepeatable read

When a transaction reads the same row more than one time, and between the two (or more) reads, a separate transaction modifies that row. Because the row was modified between reads within the same transaction, each read produces different values, which introduces inconsistency.

normalization rules

A set of database design rules that minimizes data redundancy and results in a database in which the database engine and application software can easily enforce integrity.

noun

A part of speech that names a person, place, thing, idea, animal, quality, or action. A noun usually changes form to indicate the plural and the possessive case.

ntext data type

A variable-length Unicode data type that can hold a maximum of 2^30 - 1 (1,073,741,823) characters. ntext columns store a 16-byte pointer in the data row, and the data is stored separately.

NULL

An entry that has no explicitly assigned value. NULL is not equivalent to zero or blank. A value of NULL is not considered to be greater than, less than, or equivalent to any other value, including another value of NULL.

nullability

The attribute of a column, parameter, or variable that specifies whether it allows null data values.

numeric expression

Any expression that evaluates to a number. The expression can be any combination of variables, constants, functions, and operators.

nvarchar data type

A variable-length Unicode data type with a maximum of 4,000 characters. Unicode characters use 2 bytes per character and support all international characters. sysname is a system-supplied user-defined data type that is a synonym for nvarchar(128) and is used to reference database object names.

O

object

In databases, one of the components of a database: a table, index, trigger, view, key, constraint, default, rule, user-defined data type, or stored procedure.

object dependencies

References to other objects when the behavior of the first object can be affected by changes in the object it references. For example, if a stored procedure references a table, changes to the table can affect the behavior of the stored procedure.

object identifier

A unique name given to an object.

In Meta Data Services, a unique identifier constructed from a globally unique identifier (GUID) and an internal identifier. All objects must have an object identifier.

See also: internal identifier

object owner

The security account that controls the permissions for an object, usually the creator of the object. Object owner is also called the database object owner.

object permission

An attribute that controls the ability to perform operations on an object. For example, table or view permissions control which users can execute SELECT, INSERT, UPDATE, and DELETE statements against the table or view.

object variable

A variable that contains a reference to an object.

ODBC

See definition for: Open Database Connectivity (ODBC)

ODBC data source

The location of a set of data that can be accessed using an ODBC driver. Also, a stored definition that contains all of the connection information an ODBC application requires to connect to the data source.

See also: data source

ODBC driver

A dynamic-link library (DLL) that an ODBC-enabled application, such as Excel, can use to access an ODBC data source. Each ODBC driver is specific to a database management system (DBMS), such as SQL Server, Access, and so on.

ODS

See definition for: Open Data Services (ODS)

OIM

See definition for: Open Information Model (OIM)

OLAP

See definition for: online analytical processing (OLAP)

OLE Automation controller

A programming environment (for example, Visual Basic) that can drive Automation objects.

OLE Automation objects

A Component Object Model (COM) object that provides Automation-compatible interfaces.

OLE Automation server

An application that exposes programmable automation objects to other applications, which are called "automation clients." Exposing programmable objects enables clients to "automate" certain functions by directly accessing those objects and using the services they make available. For example, a word processor might expose its spell-checking functionality so that other programs can use it.

OLE DB

A COM-based application programming interface (API) for accessing data. OLE DB supports accessing data stored in any format (databases, spreadsheets, text files, and so on) for which an OLE DB provider is available.

See also: OLE DB for OLAP

OLE DB consumer

Any software that calls and uses the OLE DB application programming interface (API).

OLE DB for OLAP

Formerly, the separate specification that addressed OLAP extensions to OLE DB. Beginning with OLE DB 2.0, OLAP extensions are incorporated into the OLE DB specification.

See also: OLE DB

OLE DB provider

A software component that exposes OLE DB interfaces. Each OLE DB provider exposes data from a particular type of data source (for example SQL Server databases, Access databases, or Excel spreadsheets).

OLTP

See definition for: online transaction processing (OLTP)

one-to-many relationship

In relational databases, a relationship between two tables in which a single row in the first table can be related to one or more rows in the second table, but a row in the second table can be related only to one row in the first table.

one-to-one relationship

In relational databases, a relationship between two tables in which a single row in the first table can be related only to one row in the second table, and a row in the second table can be related only to one row in the first table.

online analytical processing (OLAP)

A technology that uses multidimensional structures to provide rapid access to data for analysis. The source data for OLAP is commonly stored in data warehouses in a relational database.

online redo log

See definition for: transaction log

online transaction processing (OLTP)

A data processing system designed to record all of the business transactions of an organization as they occur. An OLTP system is characterized by many concurrent users actively adding and modifying data.

Open Data Services (ODS)

The layer of the SQL Server database engine that transfers client requests to the appropriate functions in the database engine. Open Data Services exposes the extended stored procedure API used to write DLL functions that can be called from Transact-SQL statements.

Open Database Connectivity (ODBC)

A data access application programming interface (API) that supports access to any data source for which an ODBC driver is available. ODBC is aligned with the American National Standards Institute (ANSI) and International Organization for Standardization (ISO) standards for a database Call Level Interface (CLI).

Open Information Model (OIM)

An information model published by the Meta Data Coalition (MDC) and widely supported by software vendors. The OIM is a formal description of meta data constructs organized by subject area.

optimize synchronization

An option in merge replication that allows you to minimize network traffic when determining whether recent changes have caused a row to move into or out of a partition that is published to a Subscriber.

optimizer

See definition for: query optimizer

ordered set

A set of members returned in a specific order. The ORDER function in a Multidimensional Expressions (MDX) query returns an ordered set.

origin object

An object in a repository that is the origin in a directional relationship. For example, project is the origin object in the relationship project has component .

See also: destination object, sequenced relationship

outer join

A join that includes all the rows from the joined tables that meet the search conditions, even rows from one table for which there is no matching row in the other join table. For result set rows returned when a row in one table is not matched by a row from the other table, a value of NULL is supplied for all result set columns that are resolved to the table that had the missing row.

overfitting

The characteristic of some data mining algorithms that assigns importance to random variations in data by viewing them as important patterns.

P

page

In a virtual storage system, a fixed-length block of contiguous virtual addresses copied as a unit from memory to disk and back during paging operations. SQL Server allocates database space in pages. In SQL Server, a page is 8 kilobytes (KB) in size.

page split

The process of moving half the rows or entries in a full data or index page to two new pages to make room for a new row or index entry.

parent

A member in the next higher level in a hierarchy that is directly related to the current member. The parent value is usually a consolidation of the values of all of its children. For example, in a Time dimension containing the levels Quarter, Month, and Day, Qtr1 is the parent of January.

See also: child, descendant, sibling, ancestor

partition

In Analysis Services, one of the storage containers for data and aggregations of a cube. Every cube contains one or more partitions. For a cube with multiple partitions, each partition can be stored separately in a different physical location. Each partition can be based on a different data source. Partitions are not visible to users; the cube appears to be a single object.

partitioning

The process of replacing a table with multiple smaller tables. Each smaller table has the same format as the original table, but with a subset of the data. Each partitioned table has rows allocated to it based on some characteristic of the data, such as specific key ranges. The rules that define into which table the rows go must be unambiguous. For example, a table is partitioned into two tables. All rows with primary key values lower than a specified value are allocated to one table, and all keys equal to or greater than the value are allocated to the other. Partitioning can improve application processing speeds and reduce the potential for conflicts in multisite update replication. You can improve the usability of partitioned tables by creating a view. The view, created by a union of select operations on all the partitioned tables, presents the data as if it all resided in a single table.

See also: filtering, vertical partitioning, horizontal partitioning

parts of speech

The classes into which words may be grouped according to their form changes and their grammatical relationships. The traditional parts of speech are verbs, nouns, pronouns, adjectives, adverbs, prepositions, conjunctions, and interjections.

pass order

The order of evaluation (from highest to lowest calculation pass number) and calculation (from lowest to highest calculation pass number) for calculated members, custom members, custom rollup formulas, and calculated cells in a multidimensional cube. Pass order is used to determine formula precedence when calculating values for cells in multidimensional cubes, across all calculation passes.

See also: solve order

pass-through query

A query passed uninterpreted to an external server for evaluation. The result set returned by a pass-through query can be used in the FROM clause of a query like an ordinary base table.

pass-through statement

A SELECT statement that is passed directly to the source database without modification or delay. In PivotTable Service, the PASSTHROUGH option is part of the INSERT INTO statement.

passive voice

Indicates that the subject of the verb receives the action of the verb. For example, in the sentence "The customers are sold products", the subject customers receives the action of the verb are sold .

See also: active voice

persistence

The saving of an object definition so it will be available after the current session ends.

phantom

By one task, the insertion of a new row or the deletion of an existing row in a range of rows previously read by another task that has not yet committed its transaction. The task with the uncommitted transaction cannot repeat its original read because of the change to the number of rows in the range. If a connection sets its transaction isolation level to serializable, SQL Server uses key-range locking to prevent phantoms.

phrase

A sequence of grammatically related words lacking a subject or a predicate, or both.

phrasing

A way to express a relationship in English. Types of phrasings include name, adjective, subset, preposition, verb, and trait phrasings. For example, department names are names of departments is an example of name phrasing.

physical name

The path where a file or mirrored file is located. The default is the path of the Master.dat file followed by the first eight characters of the file's logical name. For example, if Accounting is the logical name, and the Master.dat file is located in Sql\Data, the default physical name is Sql\Data\Accounti.dat. For a mirrored file, the default is the path of the Master.mir file followed by the first eight characters of the mirror file's logical name. For example, if Maccount is the name of the mirrored file, and the Master.mir file is located in Sql\Data, the default physical name is Sql\Data\Maccount.mir.

physical reads

A request for a database page in which SQL Server must transfer the requested page from disk to the SQL Server buffer pool. All attempts to read pages are called logical reads. If the page is already in the buffer, there is no associated physical read generated by the logical read. The number of physical reads never exceeds the number of logical reads. In a well-tuned instance of SQL Server, the number of logical reads is typically much higher than the number of physical reads.

pivot

To rotate rows to columns, and columns to rows, in a crosstabular data browser.

To choose dimensions from the set of available dimensions in a multidimensional data structure for display in the rows and columns of a crosstabular structure.

PK

See definition for: primary key (PK)

position

The current location of processing in a cursor. For example, after an application fetches the first 10 rows from a cursor, it is positioned on the tenth row of the cursor. Database APIs also have functions, such as the ODBC SQLSetPos function, that allow an application to move directly to a specific position in a cursor without performing a fetch.

positioned update

An update, insert, or delete operation performed on a row at the current position of the cursor. The actual change is made in the rows of the base tables used to build the current row in the cursor. Transact-SQL batches, stored procedures, and triggers use the WHERE CURRENT OF clause to perform positioned updates. Applications use API functions, such as the ODBC SQLSetPos function, to perform positioned updates.

possessive case

A grammatical case that denotes ownership or a relation analogous to ownership, for example, Mary's blood type, or John's movie.

precision

The maximum total number of decimal digits that can be stored, both to the left and right of the decimal point.

predicate

A basic grammatical division of a sentence that consists of what is said about the subject. For example, in the sentence "The voters elected the incumbent", the subject is voters and the predicate is elected the incumbent .

prediction

A data mining technique that analyzes existing data and uses the results to predict values of attributes for new records or missing attributes in existing records. For example, existing credit application data can be used to predict the credit risk for a new application.

See also: decision tree

prefix characters

A set of 1 to 4 bytes that prefix each data field in a native-format bulk-copy data file. The prefix characters record the length of the data value in the field, or contain -1 when the value is NULL.

prefix length

The number of prefix characters preceding each noncharacter field in a bcp native format data file.

prefix search

Full-text query searching for those columns where the specified character-based text, word, or phrase, is the prefix. When using a phrase, each word within the phrase is considered to be a prefix. For example, a prefix search specifying the phrase "sport fish*" matches "sport fishing", "sportsman fishing supplies", and so on.

preposition

A part of speech that links and relates a noun or noun substitute to another word in the sentence. For example, in the sentence "the dancers leaped across the stage", across is the preposition. Words commonly used as prepositions include about , after , among , before , between , but , during , for , from , in , into , near , of , on , over , to , until , with , and so on.

preposition phrasing

A way of expressing a relationship in English in which an entity serves as a subject and an entity serves as an object and are linked by a preposition. For example, in the sentence, "stories are about subjects", stories is the subject entity, about is the preposition, and subjects is the object.

primary dimension table

In a snowflake schema in a data warehouse, a dimension table that is directly related to and usually joined to the fact table. Additional tables that complete the dimension definition are joined to the primary dimension table instead of to the fact table.

See also: dimension table, snowflake schema

primary key (PK)

A column or set of columns that uniquely identify all the rows in a table. Primary keys do not allow null values. No two rows can have the same primary key value; therefore, a primary key value always uniquely identifies a single row. More than one key can uniquely identify rows in a table; each of these keys is called a candidate key. Only one candidate key can be chosen as the primary key of a table; all other candidate keys are known as alternate keys. Although tables are not required to have primary keys, it is good practice to define them. In a normalized table, all of the data values in each row are fully dependent on the primary key. For example, in a normalized employee table that has EmployeeID as the primary key, all of the columns should contain data related to a specific employee. This table does not have the column DepartmentName because the name of the department is dependent on a department ID, not on an employee ID.

primary table

The "one" side of two related tables in a one-to-many relationship. A primary table should have a primary key and each record should be unique. An example of a primary table is a table of customer names that are uniquely identified by a CustomerID primary key field.

private dimension

A dimension created for and used by a specific cube. Unlike shared dimensions, private dimensions are available only to the cube in which they are created.

See also: shared dimension

procedure cache

The part of the SQL Server memory pool that is used to store execution plans for Transact-SQL batches, stored procedures, and triggers. Execution plans record the steps that SQL Server must take to produce the results specified by the Transact-SQL statements contained in the batches, stored procedures, or triggers.

process

In a cube, the series of operations that rebuilds the cube's structure, loads data into a multidimensional structure, calculates summaries, and saves the precalculated aggregations. As a verb, to populate a cube with data and aggregations. It is one of three processing options for a cube.

In a dimension, the operation that loads data from a dimension table in a data warehouse into the levels defined for a dimension and rebuilds the structure of the dimension. It is one of two processing options for a dimension.

In a data mining model, the operation that retrieves training data from a relational or OLAP data source into the structure defined for a data mining model, statistically analyzes it with a data mining algorithm, and saves the statistical data as data mining content. As a verb, to populate a data mining model with data mining content.

See also: incremental update, refresh data

producer

Collects events in a specific event category and sends the data to a SQL Server Profiler queue.

project

In English Query, a file that contains the structure of the relational database and definitions of semantic objects, such as entities, relationships, and dictionary entries. Its extension is *.eqp. It is used to test how English Query translates English questions into SQL statements. Later, it can be compiled into a deployable application file with an *.eqd extension.

pronoun

A part of speech that takes the position of a noun and functions as one, for example, she, he, and we.

proper noun

A noun that is capitalized; a specific name, for example, John Smith.

property

A named attribute of a control, field, or database object that you set to define one of the object's characteristics (such as size, color, or screen location) or an aspect of its behavior (such as whether it is hidden).

property pages

A tabbed dialog box where you can identify the characteristics of tables, relationships, indexes, constraints, and keys. Every object in a database diagram has a set of properties that determine the definition of a database object. Each set of tabs shows only the properties specific to the selected object. If multiple objects are selected, the property pages show the properties of the first object you selected.

provider

An OLE DB provider.

An in-process dynamic link library (DLL) that provides access to a database.

proximity search

Full-text query searching for those occurrences where the specified words are close to one another.

publication

A publication is a collection of one or more articles from one database. This grouping of multiple articles makes it easier to specify a logically related set of data and database objects that you want to replicate at the same time.

publication database

A database on the Publisher from which data and database objects are marked for replication as part of a publication that is propagated to Subscribers.

publication retention period

A predetermined length of time that regulates how long subscriptions will receive updates during synchronizations and remain activated in databases.

published data

Data at the Publisher that has been replicated.

Publisher

A server that makes data available for replication to other servers, detects changed data, and maintains information about all publications at the site.

publishing server

An Analysis server that stores the source cube for one or more linked cubes.

See also: linked cube, subscribing server

publishing table

The table at the Publisher in which data has been marked for replication and is part of a publication.

pubs database

A sample database provided with SQL Server.

pull subscription

A subscription created and administered at the Subscriber. Information about the publication and the Subscriber is stored.

See also: push subscription

push subscription

A subscription created and administered at the Publisher. Information about the publication and Subscriber is stored.

See also: pull subscription

Q

query optimizer

The SQL Server database engine component responsible for generating efficient execution plans for SQL statements.

question

In English Query, an English form of a query, for example, "How many customers bought products last year?" Questions may also be posed as statements to an English Query application, for example, "List the customers that bought products last year."

Question Builder

A tool that supports users' needs to know more about the domain objects so that they can construct questions. They can find out what the domain objects contain, what kind of basic relationships are represented in the domain, and what English phrases can be used to ask about the relationships.

question file (.eqq)

An ASCII text file that contains questions (one to a line) that are ready for testing with the English Query engine. Question files are denoted with the .eqq extension. Questions can be submitted to the question file automatically with the test tool, or a developer can create a list of questions.

question template

A structure that describes a set of questions that can be asked using a particular relationship or set of relationships.

queue

A SQL Server Profiler queue provides a temporary holding place for server events to be captured.

R

ragged hierarchy

A dimension hierarchy in which one or more levels do not contain members in one or more branches of the hierarchy. For example, the state or province level in a geography hierarchy contains no members for countries or regions that do not have states or provinces.

See also: unbalanced hierarchy

range query

A query that specifies a range of values as part of the search criteria, such as all rows from 10 through 100.

rank

For full-text and SQL Server Books Online searches, a value indicating how closely rows or topics match the specified search criteria. For Meta Data Services and Analysis Services, a value indicating the relative positions of elements such as dimension members, hierarchy levels, or tuples in a set.

RDBMS

See definition for: relational database management system (RDBMS)

real data type

A SQL Server system data type that has 7-digit precision. Floating precision number data from -3.40E + 38 through 3.40E + 38. Storage size is 4 bytes.

record

A group of related fields (columns) of information treated as a unit. A record is more commonly called a row in an SQL database.

recordset

The ActiveX Database Objects (ADO) object used to contain a result set. It also exhibits cursor behavior depending on the recordset properties set by an application. ADO recordsets are mapped to OLE DB rowsets.

recovery interval

The maximum amount of time that the database engine should require to recover a database. The database engine ensures that the active portion of the database log is small enough to recover the database in the amount of time specified for the recovery interval.

recursive partitioning

The iterative process, used by data mining algorithm providers, of dividing data into groups until no more useful groups can be found.

redo log file

See definition for: backup file

referenced key

A primary key or unique key referenced by a foreign key.

referencing key

See definition for: foreign key (FK)

referential integrity (RI)

A state in which all foreign key values in a database are valid. For a foreign key to be valid, it must contain either the value NULL, or an existing key value from the primary or unique key columns referenced by the foreign key.

reflexive relationship

A relationship from a column or combination of columns in a table to other columns in that same table. A reflexive relationship is used to compare rows within the same table. In queries, this is called a self-join.

refresh data

The series of operations that clears data from a cube, loads the cube with new data from the data warehouse, and calculates aggregations. Refresh data is used when a cube's underlying data in the data warehouse changes but the cube's structure and aggregation definitions remain the same. One of three processing options for a cube.

See also: incremental update, process

regular cube

A cube that is based on tables and has its own aggregations.

regular dimension

A dimension that is neither a parent-child dimension nor a virtual dimension.

relational database

A collection of information organized in tables. Each table models a class of objects of interest to the organization (for example, Customers , Parts , Suppliers ). Each column in a table models an attribute of the object (for example, LastName , Price , Color ). Each row in a table represents one entity in the class of objects modeled by the table (for example, the customer name John Smith or the part number 1346). Queries can use data from one table to find related data in other tables.

relational database management system (RDBMS)

A system that organizes data into related rows and columns. SQL Server is a relational database management system (RDBMS).

relational OLAP (ROLAP)

A storage mode that uses tables in a relational database to store multidimensional structures.

See also: multidimensional OLAP (MOLAP), hybrid OLAP (HOLAP)

relationship

A link between tables that references the primary key in one table to a foreign key in another table. The relationship line is represented in a database diagram by a solid line if referential integrity between the tables is enforced, or a dashed line if referential integrity is not enforced for INSERT and UPDATE transactions. The endpoints of a relationship line show a primary key symbol to denote a primary key-to-foreign key relationship, or they show an infinity symbol to denote the foreign key side of a one-to-many relationship.

In English Query, an association between entities that describes what those entities have to do with one another. Relationships can be described concisely in English as simple statements about entities (for example, customers purchase products ). More than one join may be required to represent a single relationship.

relationship

In Meta Data Services, a relationship is an association between a pair of objects, where one object is an origin and the other object is a destination. The association repeats for each subsequent pair of objects, so that the destination of one relationship becomes the origin in the next relationship. In this way, all objects in an information model are associated through a chain of relationships that extend from one object to the next throughout the information model.

relationship object

An object representing a pair of objects that assume a role in relation to each other.

See also: sequenced relationship

relationship type

A definition of a relationship between two interfaces, as defined in an information model. A relationship type is similar to a class in that it describes characteristics to which specific instances must conform.

remote data

Data stored in an OLE DB data source that is separate from the current instance of SQL Server. The data is accessed by establishing a linked server definition or using an ad-hoc connector name.

remote Distributor

A server configured as a Distributor that is separate from the server configured as the Publisher.

See also: Distributor, local Distributor

remote login identification

The login identification (login ID) assigned to a user for accessing remote procedures on a remote server.

remote partition

A partition whose data is stored on an Analysis server other than the one used to store the meta data of the partition.

remote server

A definition of an instance of SQL Server used by remote stored procedure calls. Remote servers are still supported in SQL Server 2000, but linked servers offer greater functionality.

See also: local server

remote stored procedure

A stored procedure located on one instance of SQL Server that is executed by a statement on another instance of SQL Server. In SQL Server 2000, remote stored procedures are supported, but distributed queries offer greater functionality.

remote table

A table stored in an OLE DB data source that is separate from the current instance of SQL Server. The table is accessed by either establishing a linked server definition or using an ad-hoc connector name.

replicated data

Data at the Subscriber that has been received from a Publisher.

replication

A process that copies and distributes data and database objects from one database to another and then synchronizes information between databases for consistency.

Replication Conflict Viewer

Allows users to view and resolve conflicts that occurred during the merge replication process and to review the manner in which conflicts have been resolved.

Replication Monitor

Allows users to view and manage replication agents responsible for various replication tasks and to troubleshoot potential problems at the Distributor.

replication scripting

The generation of .sql scripts that can be used to configure and disable replication.

replication topology

Defines the relationship between servers and the copies of data and clarifies the logic that determines how data flows between servers.

repository

The storage container for the meta data used by Analysis Services. Meta data is stored in tables in a relational database and is used to define the parameters and properties of Analysis server objects.

repository

A database containing information models that, in conjunction with the executable software, manage the database. The term can also refer to an installation of Meta Data Services.

repository engine

Object-oriented software that provides management support for and customer access to a repository database.

repository object

A COM object that represents a data construct stored in a repository type library.

Repository SQL schema

A set of standard tables used by the repository engine to manage all repository objects, relationships, and collections. Repository SQL schema maps information model elements to SQL schema elements.

Repository Type Information Model (RTIM)

A core object model that represents repository type definitions for Meta Data Services. This object model is composed of abstract classes upon which instances of information models are based.

republish

When a Subscriber publishes data received from a Publisher to another Subscriber.

republisher

A Subscriber that publishes data that it has received from a Publisher.

resolution strategy

A set of criteria that the repository engine evaluates sequentially when selecting an object, where multiple versions exist and version information is unspecified in the calling program.

restatement

An English query, returned by the English Query engine, that is a check on the query entered by the end user. Restatements give end users a check that the English Query engine interpreted their question correctly. If the restatement is accurate, the correct SQL statements will be generated, and thus the returned answer will be valid.

result

In English Query, an English answer to a question that has been posed to an English Query application.

result set

The set of rows returned from a SELECT statement. The format of the rows in the result set is defined by the column-list of the SELECT statement.

return parameters

A legacy term for stored procedure output parameters, used in the Open Data Services and DB-Library APIs.

reusable bookmark

A bookmark that can be consumed from a rowset for a given table and used on a different rowset of the same table to position on a corresponding row.

revoke

Removes a previously granted or denied permission from a user account, role, or group in the current database.

RI

See definition for: referential integrity (RI)

right outer join

A type of outer join in which all rows in the right-most table in the JOIN clause are included. When rows in the right table are not matched in the left table, all result set columns that come from the left table are assigned a value of NULL.

ROLAP

See definition for: relational OLAP (ROLAP)

role

A SQL Server security account that is a collection of other security accounts that can be treated as a single unit when managing permissions. A role can contain SQL Server logins, other roles, and Windows logins or groups.

role

In Analysis Services, a role uses Windows security accounts to limit scope of access and permissions when users access databases, cubes, dimensions, and data mining models.

See also: rule

roll back

To remove the updates performed by one or more partially completed transactions. Rollbacks are required to restore the integrity of a database after an application, database, or system failure.

See also: commit

roll forward

To apply all the completed transactions from a database or log backup in order to recover a database to a point in time or the point of failure (for example, after events such as the loss of a disk).

root form

The simplest form of a word. For example, the root form of generating is generate. For other verbs, the present, infinitive form should be used when defining dictionary entries in English Query (use run, not ran or runs). For nouns, use the singular, not the plural form as the base word (animal, not animals).

row

In an SQL table, the collection of elements that form a horizontal line in the table. Each row in the table represents a single occurrence of the object modeled by the table and stores the values for all the attributes of that object. For example, in the Northwind sample database, the Employees table models the employees of the Northwind Traders Company. The first row in the table records all the information (for example, name and title) about the employee who has employee ID 1.

See also: column

row aggregate function

A function, which generates summary values that appear as additional rows in the query results (unlike aggregate function results that appear as new columns). It allows you to see detail and summary rows in one set of results. Row aggregate functions (SUM, AVG, MIN, MAX, and COUNT) are used in a SELECT statement with the COMPUTE clause.

row filter

Specifies a subset of rows from a table to be published and when specific rows need to be propagated to Subscribers.

row lock

A lock on a single row in a table.

rowset

The OLE DB object used to contain a result set. It also exhibits cursor behavior depending on the rowset properties set by an application.

RTIM

See definition for: Repository Type Information Model (RTIM)

rule

A database object that is bound to columns or user-defined data types, and specifies which data values are acceptable in a column. CHECK constraints provide the same functionality and are preferred because they are in the SQL-92 standard.

rule

In Analysis Services, a rule specifies restrictions such as Unrestricted, Fully Restricted, or Custom for security read and read/write role permissions.

See also: role

S

sample data

Artificially generated data presented instead of actual data when a cube is queried before it has been processed. Sample data enables you to view the effects of structure changes while modifying a cube.

savepoint

A marker that allows an application to roll back part of a transaction if a minor error is encountered. The application must still commit or roll back the full transaction when it is complete.

scalar aggregate

An aggregate function, such as MIN(), MAX(), or AVG(), that is specified in a SELECT statement column list that contains only aggregate functions. When the column list contains only aggregate functions, then the result set has only one row giving the aggregate values calculated from the source rows that match the WHERE clause predicates.

scheduled backup

An automatic backup accomplished by SQL Server Agent when defined and scheduled as a job.

schema

In the SQL-92 standard, a collection of database objects that are owned by a single user and form a single namespace. A namespace is a set of objects that cannot have duplicate names. For example, two tables can have the same name only if they are in separate schemas; no two tables in the same schema can have the same name. In Transact-SQL, much of the functionality associated with schemas is implemented by database user IDs. In database tools, schema also refers to the catalog information that describes the objects in a schema or database. In Analysis Services, a schema is a description of multidimensional objects such as cubes and dimensions. In XML View Mapper, a schema is a description of XML elements and database definitions that can be mapped to create a mapping schema.

schema rowset

A special OLE DB or Analysis Services rowset that reports catalog information for objects in databases or multidimensional cubes. For example, the OLE DB schema rowset DBSCHEMA_COLUMNS describes columns in tables, and the Analysis Services MDSCHEMA_MEASURES schema rowset describes the measures in a cube.

script

A collection of Transact-SQL statements used to perform an operation. Transact-SQL scripts are stored as files, usually with the .sql extension.

scroll

The ability to move around a cursor in directions other than forward-only. Users can move up and down the cursor.

search condition

In a WHERE or HAVING clause, predicates that specify the conditions that the source rows must meet to be included in the SQL statement. For example, the statement SELECT * FROM Employees WHERE Title = 'Sales Representative' returns only those rows that match the search condition: Title = 'Sales Representative'.

Security Identifier (SID)

A unique value that identifies a user who is logged on to the security system. SIDs can identify either one user or a group of users.

segmentation

A data mining technique that analyzes data to discover mutually exclusive collections of records that share similar attributes sets. A segmentation algorithm can use unsupervised learning techniques such as clustering or supervised learning for a specific prediction field.

See also: clustering

SELECT

The Transact-SQL statement used to return data to an application or another Transact-SQL statement, or to populate a cursor. The SELECT statement returns a tabular result set consisting of data that is typically extracted from one or more tables. The result set contains only data from rows that match the search conditions specified in WHERE or HAVING clauses.

SELECT

In Analysis Services, the Multidimensional Expressions (MDX) statement used to query cubes and return recordsets of multidimensional data.

select list

The SELECT statement clause that defines the columns of the result set returned by the statement. The select list is a comma-separated list of expressions, such as column names, functions, or constants.

Select query

A query that returns rows into a result set from one or more tables. A Select query can contain specifications for those columns to return, the rows to select, the order to put the rows in, and how to group (summarize) information.

self-join

A join in which records from a table are combined with other records from the same table when there are matching values in the joined fields. A self-join can be an inner join or an outer join. In database diagrams, a self-join is called a reflexive relationship.

semantic object

An object that can be represented by a database object or other real-world object. For example, an entity and a relationship are semantic objects.

semiadditive measure

A measure that can be summed along one or more, but not all, dimensions in a cube. For example, a quantity-on-hand measure of inventory can be summed along the geography dimension to produce a total quantity on hand for all warehouses, but it cannot be summed along the time dimension because the measure specifies snapshot quantities periodically in time.

sensitive cursor

A cursor that can reflect data modifications made to underlying data by other users while the cursor is open. Updates, deletes, and inserts made by other users are reflected in the sensitive cursor. Sensitive cursors are typically used in Transact-SQL batches, stored procedures, and triggers by omitting the INSENSITIVE keyword on the DECLARE CURSOR statement.

sequence

See definition for: identity column

sequenced collection

A collection of destination objects of a sequenced relationship object.

See also: sequenced relationship

sequenced relationship

A relationship in a repository that specifies explicit positions for each destination object within the collection of destination objects.

See also: relationship object, origin object, sequenced collection

serializable

The highest transaction isolation level. Serializable transactions lock all rows they read or modify to ensure the transaction is completely isolated from other tasks. This guarantees that a series of serializable transactions will always produce the same results if run in the same sequence.

server cursor

A cursor implemented on the server. The cursor itself is built at the server, and only the rows fetched by an application are sent to the client.

See also: API server cursor

server name

A name that uniquely identifies a server computer on a network. SQL Server applications can connect to a default instance of SQL Server by specifying only the server name. SQL Server applications must specify both the server name and instance name when connecting to a named instance on a server.

session

In English Query, a sequence of operations performed by the English Query engine. A session begins when a user logs on and ends when the user logs off. All operations during a session form one transaction scope and are subject to permissions determined by the logon username and password.

Setup initialization file

A text file, using the Windows .ini file format, that stores configuration information allowing SQL Server to be installed without a user having to be present to respond to prompts from the Setup program.

severity level

A number indicating the relative significance of an error generated by the SQL Server database engine. Values range from informational (1) to severe (25).

shared dimension

A dimension created within a database that can be used by any cube in the database.

See also: private dimension

shared lock

A lock created by nonupdate (read) operations. Other users can read the data concurrently, but no transaction can acquire an exclusive lock on the data until all the shared locks have been released.

Showplan

A report showing the execution plan for an SQL statement. SET SHOWPLAN_TEXT and SET SHOWPLAN_ALL produce textual showplan output. SQL Query Analyzer and SQL Server Enterprise Manager can display showplan information as a graphical tree.

sibling

A member in a dimension hierarchy that is a child of the same parent as a specified member. For example, in a Time dimension with Year and Month levels, the members January 1997 and February 1997 are siblings.

See also: child, descendant, parent, ancestor

SID

See definition for: Security Identifier (SID)

single-user mode

A state in which only one user can access a resource. Both SQL Server instances and individual databases can be put into single-user mode.

slice

A subset of the data in a cube, specified by limiting one or more dimensions by members of the dimension. For example, facts for a particular year constitute a slice of multiyear data.

See also: axis

smalldatetime data type

Date and time data from January 1, 1900, through June 6, 2079, with an accuracy of one minute.

smallint data type

SQL Server system integer data from -2^15 (-32,768) through 2^15 - 1 (32,767).

smallmoney data type

A SQL Server system data type that stores monetary values from -214,748.3648 through +214,748.3647, with accuracy to a ten-thousandth of a monetary unit. Storage size is 4 bytes. When smallmoney values are displayed, they are rounded up two places.

Snapshot Agent

Prepares snapshot files containing schema and data of published tables, stores the files in the snapshot folder, and inserts synchronization jobs in the publication database.

Snapshot Agent utility

Configures and triggers the Snapshot Agent, which prepares snapshot files containing schema and data of published tables and database objects.

snapshot cursor

See definition for: static cursor

snapshot replication

A type of replication that distributes data exactly as it appears at a specific moment in time and does not monitor for modifications made to the data.

See also: merge replication, transactional replication

snowflake schema

An extension of a star schema such that one or more dimensions are defined by multiple tables. In a snowflake schema, only primary dimension tables are joined to the fact table. Additional dimension tables are joined to primary dimension tables.

See also: primary dimension table, star schema

solve order

The order of evaluation (from highest to lowest solve order) and calculation (from lowest to highest solve order) for calculated members, custom members, custom rollup formulas, and calculated cells in a single calculation pass of a multidimensional cube. Solve order is used to determine formula precedence when calculating values for cells in multidimensional cubes, but only within a single calculation pass.

See also: pass order, calculation subcube, calculation pass, calculation condition, calculation formula

sort order

The set of rules in a collation that define how characters are evaluated in comparison operations and the sequence in which they are sorted.

source and target

A browsing technique in which a source object is used to retrieve its target object or objects through their relationship.

source cube

The cube on which a linked cube is based.

See also: linked cube

source database

See definition for: publication database

source database

In data warehousing, the database from which data is extracted for use in the data warehouse.

source object

The single object to which all objects in a particular collection are connected by way of relationships that are all of the same relationship type. For destination collections, the source object is the destination object. For origin collections, the source object is the origin object.

source partition

An Analysis Services partition that is merged into another and is deleted automatically at the end of the merger process.

See also: target partition

sparsity

The relative percentage of a multidimensional structure's cells that do not contain data. Analysis Services stores only cells that contain data. A sparse cube requires less storage than a dense cube of identical structure design.

See also: data explosion, density

SQL

See definition for: Structured Query Language (SQL)

SQL collation

A set of SQL Server 2000 collations whose characteristics match those of commonly-used code page and sort order combinations from earlier versions of SQL Server. SQL collations are compatibility features that let sites choose collations that match the behavior of their earlier systems.

See also: collation

SQL database

A database based on Structured Query Language (SQL).

SQL expression

Any combination of operators, constants, literal values, functions, and names of tables and fields that evaluates to a single value. For example, use expressions to define calculated fields in queries.

SQL Mail

A component of SQL Server that allows SQL Server to send and receive mail messages through the built-in Windows NT or Windows 2000 Messaging Application Programming Interface (MAPI). A mail message can consist of short text strings, the output from a query, or an attached file.

SQL query

An SQL statement, such as SELECT, INSERT, UPDATE, DELETE, or CREATE TABLE.

SQL Server Authentication

One of two mechanisms for validating attempts to connect to instances of SQL Server. Users must specify a SQL Server login ID and password when they connect. The SQL Server instance ensures the login ID and password combination are valid before allowing the connection to succeed. Windows authentication is the preferred authentication mechanism.

See also: authentication, Windows Authentication

SQL Server Event Forwarding Server

A central instance of SQL Server that manages SQL Server Agent events forwarded to it by other instances. Enables central management of SQL Server events.

SQL Server login

An account stored in SQL Server that allows users to connect to SQL Server.

SQL Server role

See definition for: role

SQL Server user

See definition for: user (account)

SQL statement

An SQL or Transact-SQL command, such as SELECT or DELETE, that performs some action on data.

SQL-92

The version of the SQL standard published in 1992. The international standard is ISO/IEC 9075:1992 Database Language SQL. The American National Standards Institute (ANSI) also published a corresponding standard (Data Language SQL X3.135-1192), so SQL-92 is sometimes referred to as ANSI SQL in the United States.

sql_variant data type

Data type that stores values of various SQL Server-supported data types except text , ntext , timestamp , and sql_variant .

standard security

See definition for: SQL Server Authentication

star join

A join between a fact table (typically a large fact table) and at least two dimension tables. The fact table is joined with each dimension table on a dimension key. SQL Server considers special index manipulation strategies on these queries to minimize access to the fact table.

An example of a schema participating in a star join query could be a sales table, the fact table (containing millions of rows), a product table, (containing the description of several hundred products), and a store table (containing several dozen store names). In this example, the product and store tables are dimension tables. A query for selecting sales data for a small set of stores and a subset of products restricted by attributes not present in the sales database is an ideal candidate for the star query optimization.

See also: fact table

star schema

A relational database structure in which data is maintained in a single fact table at the center of the schema with additional dimension data stored in dimension tables. Each dimension table is directly related to and usually joined to the fact table by a key column. Star schemas are used in data warehouses.

See also: denormalize, fact table, snowflake schema

statement permission

An attribute that controls that controls whether a user can execute CREATE or BACKUP statements.

static cursor

A cursor that shows the result set exactly as it was at the time the cursor was opened. Static cursors do not reflect updates, deletes, or inserts made to underlying data while the cursor is open. They are sometimes called snapshot cursors.

static SQL statements

In Embedded SQL for C, an SQL statement that is built at the time the application is compiled. It is created as a stored procedure when the application is compiled, and the stored procedure is executed when the application is run.

step object

A Data Transformation Services (DTS) object that coordinates the flow of control and execution of tasks in a DTS package. A task that does not have an associated step object is never executed.

store-and-forward database

See definition for: distribution database

stored procedure

A precompiled collection of Transact-SQL statements stored under a name and processed as a unit. SQL Server supplies stored procedures for managing SQL Server and displaying information about databases and users. SQL Server-supplied stored procedures are called system stored procedures.

string

A set of contiguous bytes that contain a single character-based or binary data value. In character strings, each byte, or pair of bytes, represents a single alphabetic letter, special character, or number. In binary strings, the entire value is considered to be a single stream of bits that do not have any inherent pattern. For example, the constant 'I am 32.' is an 8 byte character string, while the constant 0x0205efa3 is a 4 byte binary string.

string functions

Functions that perform operations on character or binary strings. Built-in string functions return values commonly needed for operations on character data.

Structured Query Language (SQL)

A language used to insert, retrieve, modify, and delete data in a relational database. SQL also contains statements for defining and administering the objects in a database. SQL is the language supported by most relational databases, and is the subject of standards published by the International Standards Organization (ISO) and the American National Standards Institute (ANSI). SQL Server 2000 uses a version of the SQL language called Transact-SQL.

structured storage file

See definition for: COM-structured storage file

subject

A basic grammatical division of a sentence. The subject is a noun or noun clause about which something is asserted or asked in the predicate, which it usually precedes. For example, in the sentence "The employee placed the order," the word employee is the subject of the sentence.

subquery

A SELECT statement nested inside another SELECT, INSERT, UPDATE, or DELETE statement, or inside another subquery.

subscribe

To request data from a Publisher.

Subscriber

A server that receives copies of published data.

subscribing server

An Analysis server that stores a linked cube.

See also: publishing server, linked cube

subscription

An order that defines what data will be published, when, and to what Subscriber.

subscription database

A database at the Subscriber that receives data and database objects published by a Publisher.

subset

A selection of tables and the relationship lines between them that is part of a larger database diagram. This selection can be copied to a new database diagram. This is called subsetting the diagram.

subset phrasing

A way of expressing a relationship in English in which one entity or word is a subset of another entity. For example, in the sentence "Some mountains are volcanoes", volcanoes are a subset of mountains.

superlative form

A form of an adverb or adjective that refers to a comparison or denotes the greatest degree. Shorter adjectives and some adverbs typically form their superlative degree by adding -est, as youngest or strongest.

synchronization

In replication, the process of maintaining the same schema and data at a Publisher and at a Subscriber.

See also: initial snapshot

synonym

A word that means the same thing as another word. For example, workers can be a synonym for employees .

system administrator

The person or group of people responsible for managing an instance of SQL Server. System administrators have full permissions to perform all actions in an instance of SQL Server. System administrators are either members of the sysadmin fixed server role, or log in using the sa login ID.

system catalog

A set of system tables that describe all the features of an instance of SQL Server. The system catalog records meta data such as the definitions of all users, all databases, all objects in each database, and system configuration information such as server and database option settings.

See also: database catalog

system databases

A set of four databases present in all instances of SQL Server that are used to store system information:

The master database stores all instance-level meta data, and records the location of all other databases.

The tempdb database stores transient objects that only exist for the length of a single statement or connection, such as worktables and temporary tables or stored procedures.

The model database is used as a template for creating all user databases.

The msdb database is used by the SQL Server Agent to record information on jobs, alerts, and backup histories.

See also: user database

system functions

A set of built-in functions that perform operations on and return the information about values, objects, and settings in SQL Server.

system stored procedures

A set of SQL Server-supplied stored procedures that can be used for actions such as retrieving information from the system catalog or performing administration tasks.

system tables

Built-in tables that form the system catalog for SQL Server. System tables store all the meta data for an instance of SQL Server, including configuration information and definitions of all the databases and database objects in the instance. Users should not directly modify any system table.

T

table

A two-dimensional object, consisting of rows and columns, used to store data in a relational database. Each table stores information about one of the types of objects modeled by the database. For example, an education database would have one table for teachers, a second for students, and a third for classes.

The columns of a table represent an attribute of the modeled object (for example, first name, last name, and address). Each row represents one occurrence of the modeled object. For example, one row in the Class table would record the information about an Algebra 1 class taught at 9:00 A.M. and another would record the information about a World History class taught at 10:00 A.M.

table data type

A special data type used to store a result set for later processing.

table lock

A lock on a table including all data and indexes.

table scan

A data retrieval operation where the database engine must read all the pages in a table to find the rows that qualify for a query.

table-level constraint

Constraints that allow various forms of data integrity to be defined on one column (column-level constraint) or several columns (table-level constraints) when the table is defined or altered. Constraints support domain integrity, entity integrity, and referential integrity, as well as user-defined integrity.

tabular data stream (TDS)

The SQL Server internal client/server data transfer protocol. TDS allows client and server products to communicate regardless of operating-system platform, server release, or network transport.

tape backup

A backup operation to any tape device supported by Windows NT 4.0 and Windows 2000. If you are creating a tape backup file, you must first install the tape device by using Windows NT 4.0 and Windows 2000. The tape device must be physically attached to the SQL Server you are backing up.

target object

See definition for: source and target

target partition

An Analysis Services partition into which another is merged and which contains the data of both partitions after the merger.

See also: source partition

task

See definition for: job

task object

A Data Transformation Services (DTS) object that defines pieces of work to be performed as part of the data transformation process. For example, a task can execute an SQL statement or move and transform heterogeneous data from an OLE DB source to an OLE DB destination using the DTS Data Pump.

TDS

See definition for: tabular data stream (TDS)

tempdb database

The database that provides a storage area for temporary tables, temporary stored procedures, and other temporary working storage needs.

temporary stored procedure

A procedure placed in the temporary database, tempdb , and erased at the end of the session.

temporary table

A table placed in the temporary database, tempdb , and erased at the end of the session.

text data type

A SQL Server system data type that specifies variable-length non-Unicode data with a maximum length of 2^31 -1 (2,147,483,647) characters. The text data type cannot be used for variables or parameters in stored procedures.

theta join

A join based on a comparison of scalar values (=, > , >= , < , <= , < >, !<, !>).

thread

An operating system component that allows the logic of multiuser applications to be performed as several separate, asynchronous execution paths. The SQL Server relational database engine executes multiple threads in order to make use of multiple processors. The use of threads also helps ensure that work is being performed for some user connections even when other connections are blocked (for example, when waiting for a disk read or write operation to complete).

time dimension

A dimension that breaks time down into levels such as Year, Quarter, Month, and Day. In Analysis Services, a special type of dimension created from a date/time column.

timestamp data type

A SQL Server system data type that is a monotomically increasing counter whose values are always unique within a database.

tinyint data type

A SQL Server system data type that holds whole numbers from 0 through 255. Its storage size is 1 byte.

tool

A SQL Server application with a graphical user interface used to perform common tasks.

trace file

A file used by SQL Profiler to record monitored events.

training data set

A set of known and predictable data used to train a data mining model.

See also: mining model training

trait

An attribute that describes an entity. For example, blood-type is a trait of patients.

trait phrasing

A way of expressing a relationship in English description in which a minor entity describes a major entity. For example, in the phrase, ages of customers, ages is the trait (or minor entity), and customers is the major entity.

Transact-SQL

The language containing the commands used to administer instances of SQL Server, create and manage all objects in an instance of SQL Server, and to insert, retrieve, modify and delete all data in SQL Server tables. Transact-SQL is an extension of the language defined in the SQL standards published by the International Standards Organization (ISO) and the American National Standards Institute (ANSI).

Transact-SQL cursor

A server cursor defined by using the Transact-SQL DECLARE CURSOR syntax. Transact-SQL cursors are intended for use in Transact-SQL batches, stored procedures, and triggers.

transaction

A group of database operations combined into a logical unit of work that is either wholly committed or rolled back. A transaction is atomic, consistent, isolated, and durable.

transaction log

A database file in which all changes to the database are recorded. It is used by SQL Server during automatic recovery.

transaction processing

Data processing used to efficiently record business activities, called transactions, that are of interest to an organization (for example, sales, orders for supplies, or money transfers). Typically, online transaction processing (OLTP) systems perform large numbers of relatively small transactions.

transaction rollback

Rollback of a user-specified transaction to the last savepoint inside a transaction or to the beginning of a transaction.

transactional replication

A type of replication where an initial snapshot of data is applied at Subscribers, and then when data modifications are made at the Publisher, the individual transactions are captured and propagated to Subscribers.

See also: merge replication, snapshot replication

transformable subscription

A subscription that allows data movement, transformation mapping, and filtering capabilities of Data Transformation Services (DTS) during replication.

transformation

In data warehousing, the process of changing data extracted from source data systems into arrangements and formats consistent with the schema of the data warehouse.

trigger

A stored procedure that executes when data in a specified table is modified. Triggers are often created to enforce referential integrity or consistency among logically related data in different tables.

trusted connection

A Windows network connection that can be opened only by users who have been authenticated by the network. The users are identified by their Windows login ID and do not have to enter a separate SQL Server login ID.

See also: Windows Authentication

tuple

An ordered collection of members from different dimensions. For example, (Boston, [1995]) is a tuple formed by members of two dimensions: Geography and Time. A single member is a degenerated case of a tuple and can be used as an expression without the parentheses.

See also: axis

two-phase commit

A process that ensures transactions that apply to more than one server are completed on all servers or on none.

U

unbalanced hierarchy

A dimension hierarchy in which leaf nodes differ in their distances from the root node. Component part and organization chart hierarchies are usually unbalanced.

See also: ragged hierarchy

underlying table

A table referenced by a view, cursor, or stored procedure.

See also: base table

unenforced relationship

A link between tables that references the primary key in one table to a foreign key in another table, and which does not check the referential integrity during INSERT and UPDATE transactions. An unenforced relationship is represented in a database diagram by a dashed line.

Unicode

Unicode defines a set of letters, numbers, and symbols that SQL Server recognizes in the nchar , nvarchar , and ntext data types. It is related to but separate from character sets. Unicode has more than 65,000 possible values compared to a character set's 256, and takes twice as much space to store. Unicode includes characters for most languages.

Unicode collation

This acts as a sort order for Unicode data. It is a set of rules that determines how SQL Server compares, collates, and presents Unicode data in response to database queries.

Unicode format

Data stored in a bulk copy data file using Unicode characters.

Union query

A query that combines two tables by performing the equivalent of appending one table onto the other.

UNIQUE constraints

Constraints that enforce entity integrity on a nonprimary key. UNIQUE constraints ensure that no duplicate values are entered and that an index is created to enhance performance.

unique index

An index in which no two rows are permitted to have the same index value, thus prohibiting duplicate index or key values. The system checks for duplicate key values when the index is created and checks each time data is added with an INSERT or UPDATE statement.

uniqueidentifier data type

A data type containing a unique identification number stored as a 16-byte binary string used for storing a globally unique identifier (GUID).

update

The act of modifying one or more data values in an existing row or rows, typically by using the UPDATE statement. Sometimes, the term update refers to any data modification, including insert, update, and delete operations.

update lock

A lock placed on resources (such as row, page, table) that can be updated. Updated locks are used to prevent a common form of deadlock that occurs when multiple sessions are locking resources and are potentially updating them later.

Update query

A query that changes the values in columns of one or more rows in a table.

update statistics

A process that recalculates information about the distribution of key values in specified indexes. These statistics are used by the query optimizer to determine the most efficient way to execute a query.

user (account)

A SQL Server security account or identifier that represents a specific user in a database. Each user's Windows account or SQL Server login is mapped to a user account in a database. Then, the appropriate permissions are granted to the user account. Each user account can only access data with which it has been granted permission to work.

user database

A database created by a SQL Server user and used to store application data. Most users connecting to instances of SQL Server reference user databases only, not system databases.

See also: system databases

user-defined data type

A data type, based on a SQL Server data type, created by the user for custom data storage. Rules and defaults can be bound to user-defined data types (but not to system data types).

See also: base data type

user-defined event

A type of message, defined by a user, that can be traced by SQL Profiler or used to fire a custom alert. Typically, the user is the system administrator.

user-defined function

In Analysis Services, a function defined in a Microsoft ActiveX library created using a Component Object Model (COM) automation language such as Visual Basic or Visual C++. Such libraries can be registered with Analysis Services and their functions called from Multidimensional Expressions (MDX) queries.

user-defined function

In SQL Server, a Transact-SQL function defined by a user. Functions encapsulate frequently performed logic in a named entity that can be called by Transact-SQL statements instead of recoding the logic in each statement.

utility

A SQL Server application run from a command prompt to perform common tasks.

V

value expression

An expression in Multidimensional Expressions (MDX) that returns a value. Value expressions can operate on sets, tuples, members, levels, numbers, or strings. For example, set value expressions operate on member, tuple, and set elements to yield other sets.

varbinary data type

A SQL Server system data type that holds up to 8,000 bytes of variable-length binary data.

varchar data type

A SQL Server system data type that holds variable-length non-Unicode data with a maximum of 8,000 characters.

variables

Defined entities that are assigned values. A local variable is defined with a DECLARE@localvariable statement and assigned an initial value within the statement batch where it is declared with either a SELECT or SET@localvariable statement.

verb

A part of speech denoting action, occurrence, or existence. A verb can consist of one or more words. For example, verbs appear in italics in the following sentences:

Employees sell products.

Employees will be working late.

verb phrasing

A way of expressing a relationship in English in which one entity is the subject in an action, which is expressed with a verb. For example, customers buy products. ( Customers is the entity; buy is the verb, and products is the direct object.)

vertical filtering

Filtering columns from a table. When used as part of replication, the table article created contains only selected columns from the publishing table.

See also: filtering, vertical partitioning

vertical partitioning

To segment a single table into multiple tables based on selected columns. Each of the multiple tables has the same number of rows but fewer columns.

See also: partitioning, vertical filtering

very large dimension

In Analysis Services, a dimension that contains more than approximately five million members and less than approximately ten million members. Special techniques are used to process very large dimensions.

See also: huge dimension

view

A database object that can be referenced the same way as a table in SQL statements. Views are defined using a SELECT statement and are analogous to an object that contains the result set of this statement.

view generation

A repository engine feature that is used to create relational views based on classes, interfaces, and relationships in an information model.

virtual cube

A logical cube based on one or more regular cubes or linked cubes.

virtual dimension

A logical dimension that is based on the values of properties of members of a physical dimension. For example, a virtual dimension that contains the colors red, green, and blue can be based on the Color member property of a product dimension.

See also: member property, dimension, member

visual total

A displayed, aggregated cell value for a dimension member that is consistent with the displayed cell values for its displayed children. The visual total of a cell can vary from the actual total if some children of the cell are hidden. For example, if the aggregate function is SUM, the displayed cell value for Spain is 1000, and the displayed cell value for Portugal is 2000, the visual total for Iberia is 3000.

W

WHERE clause

The part of an SQL statement that specifies which records to retrieve.

wildcard characters

Characters, including underscore (_), percent (%), and brackets ([ ]), used with the LIKE keyword for pattern matching.

wildcard search

The use of placeholders (such as * or ?) to perform a search for data in a table or field. For example, searching the Last Name field in a database using Smith*, could result in finding all records in which the last name starts with Smith, including Smith, Smithson, Smithlin, and so forth.

Windows Authentication

One of two mechanisms for validating attempts to connect to instances of SQL Server. Users are identified by their Windows user or group when they connect. Windows Authentication is the most secure mechanism for connecting to SQL Server.

See also: SQL Server Authentication, trusted connection

Windows collation

A set of rules that determines how SQL Server sorts character data. It is specified by name in the Windows Control Panel and in SQL Server 2000 during Setup.

word generation

Process of determining other forms of the word(s) specified. The Microsoft Search Service currently implements inflectional word generation. For example, if the word swim is specified, SQL Server also searches for swim , swam , and swimming .

write back

To update a cube cell value, member, or member property value.

See also: write enable

write enable

To change a cube or dimension so that users in cube roles with read/write access to the cube or dimension can change its data.

See also: write back

write-ahead log

A transaction logging method in which the log is always written prior to the data.

X

There are no glossary terms that begin with this letter.

Y

There are no glossary terms that begin with this letter.

Z

There are no glossary terms that begin with this letter.