Escenario: Te pidieron restaurar una base de datos de producción en una ambiente no-productivo o DTS para unas pruebas. Todo OK pero cuando los usuarios intentan loguearse a la base de datos recién restaurada reciben el siguiente error:

“The database is not accesible” (ObjectExplorer)

Para empeorar la situación, tratas de arreglarlo dándole permisos al usuario sobre la base de datos (o recreando el login) pero ahora recibes lo siguiente:

Ya no sabes que hacer, así que te empiezas a cuestionar si la administración de base de datos es tu vocación o si realmente necesitas ese trabajo.

“No es para tanto!“

Lo sé. Esto se soluciona rápidamente ejecutando:

USE AdventureWorks2016
EXEC sp_change_users_login 'Auto_Fix', 'nombre_usuario'

Si nos da un resultado como éste, vas por buen camino. El usuario ya no debería tener problemas de acceso.

Puedes verificarlo tú mismo ejecutando esto:

USE TESTDB
EXEC sp_change_users_login 'Report';

El resultado de esto debe ser vacío. De lo contrario (ver imagen 1), aún hay usuarios por ‘arreglar’, ejecuta nuevamente el comando de auto_fix mencionado arriba con el parámetro del usuario que tenga el problema.

“¿Porqué me pasan estas cosas?“

No es el karma. Este es un típico caso de usuarios huérfanos (orphaned users) y es muy común cuando se restaura una base de datos en otro ambiente porque el usuario de base de datos está basado en un login en la master, pero el login ya no existe en la master.

Si tienes alguna duda, comentario o sugerencia, puedes mandarme un email a bitácoradeundba@gmail.com.