visual usuarios usuario tipos studio linea datos crear conectar con comandos codigo code asignar visual-studio-2013 sql-server-data-tools

visual-studio-2013 - studio - tipos de usuarios en sql server



Cómo crear un usuario para un inicio de sesión en 2013 SQL Server Database Project (2)

Estoy tratando de crear un usuario con un inicio de sesión para un proyecto de base de datos SSDT. El inicio de sesión ya existe en el servidor de destino. Con el siguiente SQL:

CREATE USER [MyLogin] FOR LOGIN [MyLogin] WITH DEFAULT_SCHEMA = dbo GO

Me sale el error:

Error 1 SQL71501: Usuario: [MyLogin] tiene una referencia no resuelta para Iniciar sesión [MyLogin].

He encontrado dos soluciones, pero ninguna funciona con 2013:

1) Cree un proyecto de servidor para hacer referencia al inicio de sesión. Esta no es una opción en la versión actual de SSDT / VS2013

2) Deshabilitar la comprobación de esquema. Falta la opción en 2013 (creo que era Options -> Database Tools -> Schema Compare )


Realmente puede crear el inicio de sesión a nivel del servidor dentro del proyecto de base de datos de SQL Server usando la sintaxis estándar de T-SQL:

CREATE LOGIN [Login_Name] WITH PASSWORD = ''<Password>'';

Nota : También puede hacer clic con el botón derecho en el proyecto de la base de datos y elegir ''Agregar nuevo elemento'' y navegar a SQL Server> Seguridad (dentro del cuadro de diálogo de plantillas) y seleccionar ''Iniciar sesión (SQL Server)''.

Esto resuelve el error SQL71501 y (suponiendo que esté utilizando SQLPackage.exe para la implementación), permitirá a SQLPackage.exe la capacidad de comparar el objeto de seguridad con la base de datos de destino antes de que se realice la implementación y publicación.

Espero que ayude :)


Si tiene la garantía de tener el inicio de sesión en el servidor, lo mejor que puede hacer es modificar su archivo maestro dacpac. Hay algunas instrucciones sobre cómo hacer esto aquí: http://sqlproj.com/index.php/2013/02/how-to-add-objects-to-master-dacpac

Alternativamente, puede eliminar las referencias a los inicios de sesión de la parte de SSDT y manejarlas en los scripts posteriores a la implementación. Si tiene algún tipo de entorno donde se deban aplicar diferentes permisos en diferentes servidores (Desarrollo, Control de calidad, Producción), esa podría ser la mejor opción. He blogeado sobre esto aquí: http://schottsql.blogspot.com/2013/05/ssdt-setting-different-permissions-per.html

Esperemos que uno de esos ayude. De hecho, he usado la primera opción para solucionar un problema con la necesidad de usar EXECUTE AS, que requiere que el usuario esté en el proyecto. Fue un poco difícil obtener el XML exacto, pero lo resolví creando un proyecto vacío con solo ese inicio de sesión, generándolo y copiando el XML del dacpac en el dacpac maestro.