Administrator's Companion Errata

The following changes should be made to the Microsoft SQL Server Administrator's Companion for Microsoft SQL Server 6.0.

In the SQL Server Books Online version of the Microsoft SQL Server Administrator's Companion for Microsoft SQL Server 6.5, illustrations have been updated to match the illustrations that are in the Microsoft SQL Server Administrator's Companion for Microsoft SQL Server 6.0.
Also, in books online, the introduction to Part 6, "Replication," should reference Chapter 13, "Replication Concepts," Chapter 14, "Setting Up Replication," and Chapter 15, "Advanced Replication."
On Page 62, "Configuring Servers," the listed procedure works on Windows NT server machines, but does not work on Windows NT Workstation machines. However, to hide the server on a Windows NT Workstation machine, at the command prompt, type:
```
net config server /hidden: yes
  
```
On page 90, "NetWare Clients," in the note that begins "The instructions that follow..." the following sentence should be added: "The network number is in decimal."
On page 218, "Object Permissions," the following changes should be made:
In the table in the Statement column, "REFERENCE" should be "REFERENCES" and the associated object in the Object column should be "Table, columns." "DUMP TABLE" should be added to the Statement column, along with its associated object "Table."
Also, SELECT permission does not include REFERENCES permission.
On page 437, "Before You Set Up Replication," the following paragraph should be added to the subsection "Use One Character Set":
If the character sets in use are not the same type (for example, 850 and 437), replicating extended characters between ANSI and OEM character sets is not possible unless you are using scheduled table refresh. When replicating extended characters using same-type character sets, both scheduled table refresh and log-based replication will work correctly.
On page 547, "To Set Up Replication Manually," step 6 for the sp_addpublisher stored procedure should read:
```
sp_addpublisher 'WOLFHOUND', 'dist'
go
  
```
On page 597, "Setting Alerts on Forwarded Events," the following paragraph should be added to the bulleted list at the top of the page:
Each server that participates in event forwarding must have a non-null @@servername value. Without this value, the forwarding process may not work correctly under all situations and cyclical forwarding may go undetected. The @@servername value can be set by executing the command 'sp_addserver <servername>, local' and then restarting SQL Server. For more information about using sp_addserver, see the Microsoft SQL Server Transact-SQL Reference.
On page 608, "Setting Up Mail," the following information should be added to step 5 at the bottom of the page: "When assigning a mail login name to the mail client, do not use a mail login that has a null password. A password is required to access a remote post office."
On page 616, "Setting Up a Mail Post Office," in the paragraph that begins, "When setting up the shared network directory," in the second line RWCD should be changed to RW.
On page 617, under "Using SQL Mail with a Netware Post Office," the first three paragraphs and step 1 should be replaced with the following:
You can set up the SQL Server service (MSSQLServer) to run under a Windows NT user account. With appropriate permissions, SQL Server can run SQL Mail and access a NetWare Post Office.
However, the server's LocalSystem account has no user account information that can be used when accessing remote resources. If the SQL Server service (MSSQLServer) is configured to run under the server's LocalSystem account, it cannot directly access certain server software, including Novell® NetWare®.
When SQL Server is running under LocalSystem, it is possible to set up SQL Mail to work when the post office is on a Novell NetWare file server by going through the Gateway Services for NetWare, which is provided with Windows NT version 3.5 or later.
The following steps describe how to set up SQL Mail running under LocalSystem to work with a NetWare post office:
1. Set up a gateway share on the Windows NT Server to point to the post office share on the NetWare machine. Supply a valid NetWare user account and password for an account that has RW access to the post office share. For information on how to set this up, see the Windows NT documentation on the Gateway Services for NetWare.
On pages 619 and 620, all information under the topic "Troubleshooting SQL Mail Problems" should be replaced with the following:
You can use certain basic troubleshooting techniques to diagnose and resolve most SQL Mail problems. Typically, errors in starting a mail session or in sending mail fall into two categories:
- Permissions problems when accessing Shared File System (SFS) shares that are being used as a post office
- Registry setup problems
If you encounter SQL Mail problems, perform the following steps in the order they are presented:
1. Ensure that the user who set up SQL Mail can successfully start a mail session and send mail by using the Windows NT Mail client application, MSMAIL32.EXE.
2. In SQL Server 6.0 or later, SQL Mail can run when the MSSQLServer service is assigned to the LocalSystem account, and also when it is assigned to another Windows NT user account.
Note If you are running the Windows NT Mail client application on the same machine as SQL Server, you must run the MSSQLServer service in the LocalSystem account.
Important A service that is running under the system account has no user account information associated with it. This will prevent certain network server software from allowing the Windows NT service to access resources. Microsoft LAN Manager user-level security servers and Novell® NetWare® servers will not allow a Windows NT service that is running under the system account to access their file shares.
In SQL Server 4.2x, the SQLServer service must be assigned the server's LocalSystem account. You can determine the assigned account by opening the Services application in Control Panel, selecting the SQLServer service, and choosing the Startup button.
1. If SQL Server is running under a user account, proceed to step 6. If SQL Server is running under LocalSystem, proceed with step 4.
2. When a mail session is started, mail uses information in the Windows NT Registry to determine startup information, such as the share name that is serving as a post office for the user that is logging in. This Registry information is configured for the current user. To make the information available to SQL Server, run SQL Server setup, select Set Server Options, choose the Mail Login button, and select the option Copy SQL Mail Configuration from Current User Account.
  This option creates the Registry key:
```
HKEY_USERS\.DEFAULT\Software\Microsoft\Mail
```
  This Registry key is used by SQL Mail. If this Registry key is not set up properly, confirm that it is possible to start a mail session by using the account with which you are currently logged into Windows NT. If so, rerun SQL Server setup with the option Copy SQL Mail Configuration from Current User Account selected.
3. If the post office resides on a Windows NT server version 3.5x-based computer, add the post office share to the list of shares that can be accessed by services that are running under the system account. To add the post office share, use the Registry Editor file REGEDT32.EXE to add the share name to the following Registry value on the Windows NT computer where the post office is located:
```
HKEY_LOCAL_MACHINE\System\CurrentControlSet
\Services\LanmanServer\Parameters\NullSessionShares
```
  For example, if the post office is running on a computer with the name "NTServer" and the post office directory is shared as "WGPO," the value "WGPO" must be added to the NullSessionShares value.
  Because the NullSessionShares value is of the type REG_MULTI_SZ, each share name must be on a separate line from other share names.
  For this Registry change to take effect, the post office computer must be re-booted.
4. If SQL Server is running under a user account instead of the system account, confirm that step 1 was performed while the user was logged into Windows NT under the same user account that SQL Server is using.
5. Confirm that the MSSQLServer service has Change access permissions or RW access permissions to the post office share. If SQL Server is running under the system account, the post office share must grant these rights to the Everyone group.
  Additionally, if the post office is located on an NTFS partition, Everyone must be granted the same rights as the share permissions on the post office directory, including all subdirectories and all existing files in the post office directory.
  To test SQL Server access permissions on the post office share, execute the xp_cmdshell extended stored procedure, which runs with the same permissions as SQL Mail.
  You can use the following commands to test read and write access to the server, assuming the post office is located on a computer named "NTServer" and the post office directory is shared as "WGPO":
```
xp_cmdshell 'dir \\NTServer\WGPO'

xp_cmdshell 'echo 'hello' > \\NTServer\WGPO\test.txt'
```
  If either of the above commands fails, step 5, 6, or 7 has not been completed correctly.
Note An access violation can result from an attempt to execute xp_sendmail when the post office and address book are on a file share that the MSSQLServer service cannot access.

On page 743, in Chapter 24 "Additional Problem-Solving Techniques," in the topic "Moving a Device," the syntax diagram should be changed to:

sp_movedevice device_name,new_path

The stored procedure for moving a device should be replaced with the following:

/****************************************************************/
PRINT ' '
PRINT 'Creating Stored Procedure: dbo.sp_movedevice'
PRINT 'Use this prior to moving the device or DB will be suspect'
/***************************************************************/
go
EXEC sp_configure 'allow updates', 1
RECONFIGURE WITH OVERRIDE
go
IF EXISTS (SELECT * FROM sysobjects WHERE
name = 'sp_movedevice' and type = 'P')
DROP PROCEDURE sp_movedevice
go
CREATE PROCEDURE sp_movedevice @devname varchar(30), 
  @newpath varchar (127)
AS
BEGIN
BEGIN TRAN
UPDATE sysdevices set phyname = @newpath
WHERE name = @devname
IF @rowcount <> 1
BEGIN
PRINT '**********************ERROR**********************'
PRINT 'Moved failed - more or less than one row affected'
PRINT '**********************ERROR**********************'
ROLLBACK TRAN
END
ELSE
BEGIN
PRINT 'Device moved successfully'
PRINT 'Change will take effect next time you start SQL Server'
COMMIT TRAN
END
END
go
sp_configure 'allow updates',0
RECONFIGURE WITH OVERRIDE
go