BUG: Database Fallback May Cause Dbid to Change

 Last reviewed: March 4, 1998
Article ID: Q180603
The information in this article applies to:
  • Microsoft SQL Server, version 6.5
BUG #: 17807 (SQLBUG_65)

SYMPTOMS

When a database is brought online by a fallback server, the dbid that was originally assigned to the database may not be available. This causes the fallback server to assign a new dbid number to the database. If execute permissions for objects have been established in the original database, users may not have access to the objects until they have been recompiled.

CAUSE

When a user attempts to use an object (a view, stored procedure, table, and so on), permissions are checked before the user is allowed access to the object. In the case of a stored procedure, the pre-complied version is resolved by using the original dbid. If the user does not exist in the corresponding dbid on the fallback server, an error message (error 916) will be generated, indicating the user was not found in the database. This message will then resolve and show the correct database name on the fallback server for the original dbid.

The text of error 916 is: 

   Msg 916, Level 14, State 1
   Server user id %d is not a valid user in database '%.*s'
For an example of this situation, see the MORE INFORMATION section of this article.

WORKAROUND

To work around this problem, ensure that the dbid of the original database is not in use on the fallback server.

STATUS

Microsoft has confirmed this to be a problem in SQL Server version 6.5. A supported fix is now available, but has not been fully regression- tested and should be applied only to systems experiencing this specific problem. Unless you are severely impacted by this specific problem, Microsoft recommends that you wait for the next Service Pack that contains this fix. Contact Microsoft Technical Support for more information.

MORE INFORMATION

The following example illustrates the problem: 

   Before Fallback
   ---------------

    - Original server: mydb_1 = dbid 7
    - Fallback server: mydb_2 = dbid 7

   After Fallback
   --------------

    - Fallback server: mydb_2 = dbid 7; mydb_1 = dbid 8
In this example, if a user in mydb_1 attempted to execute a stored procedure that he or she had execute permissions on, the stored procedure would fail to execute. The error message would show that the user was not found in database mydb_2 (dbid of 7 on the fallback server). If the user did exist in dbid 7, the stored procedure would be executed.

If any user who has create permissions attempted to use the stored procedure, the stored procedure would be recompiled on error. This would then re-resolve the database name to the new dbid and allow subsequent users that had execute permissions to use the object.

Additional query words: sp_fallback fall back db id
.END:
Keywords : kbbug6.50 SSrvEntMan
Version : WINNT:6.5
Platform : winnt
Issue type : kbbug
Solution Type : kbfix

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: March 4, 1998
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.