This article also applies to Microsoft SQL Server 2000
Service Pack 3a (SP3a).
Because most changes introduced in Microsoft
SQL Server 2000 SP3a are related to setup, you do not have to apply Microsoft
SQL Server 2000 SP3a to instances of SQL Server 2000 or SQL Server Desktop
Engine (also known as MSDE 2000) that have already been upgraded to Microsoft
SQL Server 2000 Service Pack 3 (SP3).
However, if you have instances
that have not been upgraded to SQL Server 2000 SP3, you must upgrade those
instances directly to SQL Server 2000 SP3a instead of SQL Server 2000 SP3. If
you have any copies of the SQL Server 2000 SP3 download files that you were
planning to use for future upgrades, you must delete those copies and use
either the SQL Server 2000 SP3a download files or the SQL Server 2000 SP3a
CD-ROM instead.
For applications that distribute and install MSDE
2000, install SQL Server 2000 SP3a instead of SQL Server 2000 SP3.
While you can apply SQL Server 2000 SP3a to instances of SQL Server 2000 SP3 or
MSDE 2000 SP3, doing so has little effect on those instances.
For
more information about SQL Server 2000 SP3a, visit the following Microsoft Web
site:
SQL Server 2000 SP3 introduces new
switches for the Setup.exe in the Desktop Engine (MSDE) setup. This article
briefly describes the new switches.
MORE INFORMATION
Here is a list and a brief description of the new
switches.
ALLOWXDBCHAINING=1Enables cross-database ownership
chaining.
For additional information about cross-database chaining,
click the following article number to view the article in the Microsoft
Knowledge Base:
810474
Cross Database
Chaining
BLANKSAPWD=1Formerly, this was
USEDEFAULTSAPWD. This switch overrides the default behavior of the installer.
This switch prevents installation with a blank
sa password.
If you set
BLANKSAPWD=1, you can perform an installation with a blank
sa password.
Regardless of whether an instance of Desktop
Engine is using Microsoft Windows or Mixed Mode authentication, the Setup
cannot continue if a blank password is detected for the
sa logon. A warning message appears if a blank password is detected.
If you have a blank password for the
sa logon, before you continue you must change the password by using
the
sp_password stored procedure.
You can add an entry to the
Property table by using a Windows Installer database editing tool such as
Orca.exe to assign specific internal properties used in the SQL Server 2000 SP3
MSDE merge modules to a specific value. For example, to set the instance name,
you add an entry to the
Property table and assign the
SqlInstanceName property a specific value. SQL Server 2000 MSDE merge modules
uses the new internal properties that are listed in this table:
|
ALLOWXDBCHAINING | SqlAllowXDBChaining |
BLANKSAPWD | SqlBlankSaPwd |
DISABLENETWORKPROTOCOLS | SqlDisableNetworkProtocols |
SAPWD | SqlSaPwd |
UPGRADEPWD | SqlUpgradePwd |
Note: The internal properties are case-sensitive.
Warning: The use of blank passwords is strongly discouraged.
SAPWD=sa_password
Formerly,
SAPASSWORD="sa_password" .
Specifies the
sa password. You can use this option for new installations. Unlike
other properties, the
SAPWD property is hidden and the value is not written to the log
file.
If you specify both
SAPWD and
BLANKSAPWD,
SAPWD takes precedence and
BLANKSAPWD is ignored.
Important: If you are using an .ini file during set up, avoid storing
credentials in the .ini file.
For additional information,
click the following article number to view the article in the Microsoft
Knowledge Base:
285103
BUG: BOL Incorrect on SAPASSWORD and USEDEFAULTSAPWD Options for SQL Server 2000 Desktop Engine Installation
UPGRADEUSER=sa
Specifies the logon that will be used when you upgrade
Desktop Engine by using SQL Server Authentication. The logon must be a member
of the sysadmin fixed server role.
UPGRADEPWD= sa_password
Specifies the password for the logon that is
used when you upgrade Desktop Engine by using SQL Server Authentication.
You can specify setup parameters either on a command line or in an
.ini file. For more information, see the "Customizing Desktop Engine Setup.exe"
topic in SQL Server Books Online.
Important: Avoid storing credentials in an .ini file.
To customize the Microsoft Data Engine (MSDE)
installation that uses merge modules, edit the
Property table of the .msi file and set the Internal Property to a
specific value, as described earlier in this article. The following table shows
the mapping between the parameters (command-line switches) and their
corresponding Internal Property:
External Property | Internal Property |
ALLOWXDBCHAINING | SqlAllowXDBChaining |
BLANKSAPWD | SqlBlankSaPwd |
SAPWD | SqlSaPwd |
UPGRADEPWD | SqlUpgradePwd |
How to Upgrade an Existing Instance of Desktop EngineSQL Server 2000 SP3 introduces a new switch for
upgrading the Desktop Engine. The
/upgradesp switch replaces the
/p switch. When you use this new switch, you have two options,
depending on the information that you have about the instance of Desktop Engine
that you are upgrading. You must either know the instance name (the default is
MSSQLSERVER), or you must know what .msi file was originally used to install
the Desktop Engine.
If you know the instance name, use the
/upgradesp switch, as shown in this example:
Setup.exe /upgradesp SQLRUN INSTANCENAME=instance_name
In this case, the installer uses the instance name to determine
what .msi file was originally used to install Desktop Engine.
Note: When you upgrade the default instance, you do not have to
specify INSTANCENAME.
You can install the Desktop Engine with one of
16 .msi files (SqlRun01.msi through SqlRun16.msi). If you know the name of the
original .msi file that was used to install Desktop Engine, you can specify it
to the complete path for the SQL Server 2000 SP3 .msi file of the same name, as
shown in this example:
Setup.exe /upgradesp c:\SQL2KSP3\MSDE\Setup\SqlRun03.msi
In this example, C:\SQL2KSP3\MSDE\Setup represents the location of
the SQL Server 2000 SP3 .msi files. SqlRun03.msi is the name of the .msi file
used in the original installation.
If you do not know either the
instance name or the original .msi file, see the following article in the
Microsoft Knowledge Base:
311762 INF: How to Identify Which MSI File Was Used for an Existing MSDE Installation
This article describes how to determine the name of
the original .msi file.