A. It could be a variety of things.

1. Sometimes rebuilding the registry for 6.5 and below fixes the problem. From the <sql>\binn directory run the following, making sure the case is correct

setup /t RegistryRebuild = On

The setup routine will now run and ask you all the normal questions. Answer these as if you were performing the install again (same paths etc.) and it will just update all the registry entries/icons etc. It will leave the databases alone.

2. For SQL 7 try unloading and reloading the counters

unlodctr.exe MSSQLServer
lodctr.exe <sql>\BINN\sqlctr.ini

3. For 6.5 machines running on NT 4.0 it could be a permissions problem.

To work around this problem, use Regedit.exe to grant READ access to the
following key of the target machine:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer

Grant this to those wanting SQL counter access. As when granting any NT
access permission, you can grant based on an individual user or a group.

4. PSS ID Number: Q137899
Article last modified on 04-15-1997

6.0 4.21a

WINDOWS


======================================================================
----------------------------------------------------------------------
The information in this article applies to:

- Microsoft Windows NT Server versions 3.5 and 3.51
- Microsoft SQL Server, versions 4.21a & 6.0
----------------------------------------------------------------------
Bug#: 11370 (6.00)

SYMPTOMS
========

If Performance Monitor fails one or more of the following symptoms occur:

- SQL Counters are not located in the Object list.

- If you are auditing logins, the following type of error is logged:

Login failed - User. \ Reason: Not defined as a valid user
of a trusted SQL Server connection.

CAUSE
=====

The use of Performance Monitor can fail when:

- Viewing SQL Counters from a remote client.

OR

- The Probe password is not NULL.

OR

- SQL Server is listening on an alternate pipe.

WORKAROUND
==========

Set up SQL Server to use standard security because you cannot force or
"unforce" a trusted connection. Make sure SQL Server is listening on the
default pipe and the Probe password is NULL.

If you need to continue the integrated connection, simply add an advanced
connection to the SQL Server computer, pointing back to itself. That is,
use the SQL Server Client Configuration Utility to create an advanced
entry that is the same name as the SQL Server computer itself, using named
pipes and connecting to '\\.\pipe\sql\query'.