Se deniega el acceso al adjuntar una base de datos

147

Estoy usando la edición de desarrollador de SQL Server 2008. Estaba tratando de adjuntar la base de datos AdventureWorks2008.

Cuando intenté adjuntar, recibí un error de "acceso denegado". Según el registro de eventos, provenía de la O / S:

Error al abrir: no se pudo abrir el archivo D: \ ProjectData \ AdventureWorks \ AdventureWorksLT2008_Data.mdf para el número de archivo 0. Error del sistema operativo: 5 (acceso denegado).

Pensé "problema de NTFS", pero el Sistema (y yo) tenemos acceso de modificación a ambos archivos.

Descubrí que puedo conectar con éxito la base de datos si inicio sesión como sa, pero mi cuenta de usuario no funcionará.

Soy miembro del grupo de administradores locales en mi máquina y estoy en el rol de administrador de sistemas en la instancia de SQL Server.

¿Alguna idea de por qué tuve que iniciar sesión como sa?

JMarsch
fuente
¿El archivo MDF está encriptado por casualidad?
Brettski
No, la verdadera curiosidad para mí es que funciona bien si inicio sesión como sa (usando Management Studio), pero no funciona si uso mi cuenta de administrador local. Mi cuenta es un administrador, un administrador de dominio, y es la cuenta con la que inicié sesión cuando instalé SQL Server (durante la configuración había una opción para hacer que mi cuenta actual fuera un administrador de sistemas, y lo hice).
JMarsch
1
Así es como funciona UAC en W7, no es de extrañar.
Al Kepp
@AlKepp Nope - no es una cosa de UAC. Simplemente iniciar sesión como sa corrige (cuenta del servidor SQL, no tiene nada que ver con UAC) el problema. Además, solo por ser miembro del grupo de administradores locales, obtengo mis permisos, no tengo que elevar para que mis credenciales de AD funcionen.
JMarsch

Respuestas:

162

Ejecute SQL Server Management Studio como administrador. (clic derecho-> ejecutar como administrador) que se ocupó de todas las rarezas en mi caso.

SQL SRV EXPRESS 2008 R2. Windows 7

MandoMando
fuente
55
Ejecutar Management Studio como administrador NO me funcionó. Este error ocurre al intentar iniciar el servicio de Windows.
nuzzolilo
9
Ejecutar como administrador es el primer paso. El segundo paso es iniciar sesión en SQL Server mediante la autenticación de Windows. (¡Este método funcionó para mí!)
Furkan Ekinci
3
A mí también me funcionó. No se puede expresar con palabras lo agotadores y frustrantes que son los mensajes de permiso y los errores en Windows. ¡SOY ADMINISTRADOR!
David Masters el
A mí también me funcionó. Al principio no pensé que funcionaría porque SSMS es solo un cliente de UI. Pensé que necesitaba que el servicio se ejecutara como administrador. Pero ejecutar SSMS como administrador es suficiente.
Luke Vo
2
A mí también me funcionó. SQL Server 2019, SSMS 18.4
Ryan Thomas
105

Gracias por todos los comentarios. Algunos de ustedes ayudaron a llevarme a la respuesta. Esto es lo que encontré:

Fue un problema de permiso NTFS, y no un problema de SQL. Además, se ve un poco como un error (y es repetible).

El problema: la cuenta que estaba usando tenía permisos NTFS de control total para los archivos mdf y ldf. Sin embargo, tenía esos permisos a través de la membresía del grupo (el grupo de Administradores locales tenía permisos, y mi cuenta es miembro de administradores locales). (Verifiqué los permisos)

Si trato de adjuntar, me conecto a SQL Server como yo (donde estoy en el grupo de administradores), falla con el problema NTFS.

Sin embargo, si otorgo los mismos permisos de archivo que el grupo de administración local tiene directamente a mi cuenta de dominio, entonces puedo adjuntar sin problemas.

(Ah, y sí, verifiqué los grupos locales en esta máquina, y verifiqué que mi cuenta de dominio es realmente un miembro del grupo de administradores locales).

Por lo tanto, parece que el error ocurre porque algún código (ya sea en SQL Server o Management Studio) verifica los permisos que posee la cuenta de usuario, pero no llega a verificar los permisos de grupo que hereda la cuenta de usuario.

Eso me parece extraño, pero puedo reproducirlo una y otra vez, así que he concluido que es la respuesta.

Actualización: informé esto como un error: https://connect.microsoft.com/SQLServer/feedback/details/539703/access-denied-attaching-a-database-when-permissions-are-inherited

JMarsch
fuente
104
Si, como yo, está utilizando Windows 7, deberá ejecutar SQL Server Management Studio como administrador para evitar este error.
Antony
44
Reproducido en Win7 Pro con SS2008 Express. Mismo problema para sqlcmd y SSMS. == Meldung '5120', Ebene '16', Estado '101', Servidor 'DAGO \ SQLEXPRESS', Zeile 1 - 'Die physische Datei' D: \ data \ mssql \ drei.mdf 'kann nicht geöffnet werden. Betriebssystemfehler 5: '5 (Zugriff verweigert) == Otorgar acceso completo al usuario (que es miembro del grupo de administradores locales, que tiene acceso) soluciona el problema. Además, ejecutar sqlcmd (o SSMS, supongo) como Administrador no produce este error.
Lumi
1
Anthony Highsky tiene la respuesta. Solo necesita estar seguro de ejecutar Management Studio como administrador.
James
El mismo problema y solución para mí. 2008R2, Win 7, etc. Me agregué explícitamente a la lista de seguridad y funcionó. ¿Supongo que SQL Server puede leerlos, una vez adjuntos, pero no bajo mis credenciales al adjuntar?
Andrew Backer
44
Ejecutar Management Studio como administrador NO me funcionó. Este error ocurre al intentar iniciar el servicio de Windows.
nuzzolilo
20

Me gustaría agregar información adicional a las respuestas que se publicaron.

¡Tenga cuidado al separar la base de datos porque el usuario de Windows en el que ha iniciado sesión se convierte en el único usuario con permisos para el archivo .mdf! Los permisos originales que tenía el archivo .mdf que incluía al usuario SQLServerMSSQLUser$<computer_name>$<instance_name>y la cuenta de Administradores se sobrescriben por el usuario de Windows en el que haya iniciado sesión (no el usuario del servidor SQL). Boom, todos los permisos desaparecieron así como así. Haga lo que otros han dicho y haga clic derecho en su archivo .mdf y verifique los permisos.

Me encontré con este problema porque utilicé SSMS para conectarme a la base de datos (no importa qué cuenta de servidor sql) y desconecté la base de datos. Después de hacer eso, mi usuario de Windows era el único que tenía permisos para el archivo .mdf. Más tarde, cuando intenté adjuntar el db usando la cuenta sa, arrojó el error "acceso denegado".

Para mantener intactos los permisos originales, debe desconectar la base de datos, luego separarla y luego adjuntarla en ese orden de la siguiente manera:

USE [master]
GO
-- kick all users out of the db
ALTER DATABASE mydb
SET SINGLE_USER WITH ROLLBACK IMMEDIATE 
GO

-- Take the Database Offline
ALTER DATABASE mydb SET OFFLINE WITH
ROLLBACK IMMEDIATE
GO

-- detach the db
EXEC master.dbo.sp_detach_db @dbname = N'mydb'
GO
goku_da_master
fuente
1
¡Gracias por esto! Creo que es mucho más fácil hacerlo bien si también ha iniciado sesión con una cuenta autenticada de SQL Server con privilegios de serveradmin.
William Rose
Desafortunadamente, esto no me ayuda si originalmente creé la base de datos como 'sa' en lugar de como usuario de Windows
David Gardiner,
"Tenga cuidado al separar la base de datos". Dile a SSMS que tenga cuidado. Mis problemas se produjeron porque al usar SSMS el comando Copiar base de datos falló dejándome en la ciudad del pozo sin explicación
Alan Macdonald
18

Agregue permiso a la carpeta donde está su .mdfarchivo.

Mira este nombre: NT Service\MSSQLSERVER

Y cambie el Locationnombre de su servidor.

Leonardo
fuente
55
Para encontrar el nombre de la cuenta exacta, ya que puede variar de un caso al otro, ejecute lo siguiente: SELECT servicename, service_account FROM sys.dm_server_services.
Arve Systad
13

Este problema es causado por UAC (Control de cuentas de usuario), ¿no? Aunque su cuenta de usuario es miembro del grupo Administradores, el UAC en Windows 7 no le permite hacer tareas de administrador a menos que ejecute programas "como administrador". No es un error real en SQL Server o Management Studio o lo que sea. (Aunque posiblemente podría conocer el problema y pedirle permisos elevados en lugar de quejarse del "error 5").

Al Kepp
fuente
11

Ejecute SQL Server Management Studio como administrador. (clic derecho-> ejecutar como administrador) funcionó para mí con Windows 7 - SQL server 2008 R2

Rolwin Crasta
fuente
1
Esta respuesta debe ser votada. Ejecutar el SSMS como administrador es una solución alternativa que replica esta respuesta. Microsoft informa esto como "comportamiento esperado" aquí: enlace
FreeText
¿No es esto lo mismo que la respuesta de MandoMando?
mortb
10

Una base de datos SQL2005 se puede adjuntar de esta manera en Windows 7:

start menu >
 all program >
  Microsoft sql server 2005 >
   sql server management studio >
    right click >
     run as administrator >
      click ok

Y luego la base de datos adjunta se completó con éxito.

Rahul garg aggarwal
fuente
Esto funcionó con SQL Server 2016 con Management Studio 2008 R2 en Windows 10 :)
par
9

Cuando inicia sesión como sa(o cualquier cuenta de SQL Server), está funcionando como la cuenta de servicio de SQL Server, cuando inicia sesión como usted, tiene los permisos de su cuenta. Por alguna razón, no tiene el acceso a archivos adecuado, pero la cuenta de servicio sí.

Nick Craver
fuente
El problema de NTFS fue lo primero que pensé también, pero ese no parece ser el problema: soy miembro del grupo de administradores locales y verifiqué que los administradores tienen permisos de "control total" en los archivos mdf y ldf . Además, soy el propietario de los archivos: acabo de crear un directorio y copié los archivos mdf / ldf en su ubicación.
JMarsch
@JMarsch: @Nick dice que 'sa' tiene un conjunto de DERECHOS SQLSERVER, no derechos NTFS, que su cuenta no tiene.
Trevoke
@Trevoke: estoy contigo. Si ese es el caso, ¿qué derechos necesitaría asignar a mi cuenta de usuario? (Ya estoy asignado al rol de administrador del sistema)
JMarsch
1
Antigua respuesta, esta, pero para personas como yo hace cinco minutos: puede encontrar el nombre de usuario exacto del servicio ejecutandoSELECT servicename, service_account FROM sys.dm_server_services
Arve Systad
6

Encontré esta solución: haga clic derecho en la carpeta donde almacena su archivo .mdf -> haga clic en Propiedades -> elija la pestaña Seguridad, haga clic en Editar ... y dele el control total. ¡Espero que esto ayude!

quokka
fuente
5

El sausuario usa cuentas NTFS SQLServerMSSQLUser$<computer_name>$<instance_name>ySQLServerSQLAgentUser$<computer_name>$<instance_name> para acceder a los archivos de la base de datos. Es posible que desee intentar agregar permisos para uno o ambos usuarios.

No sé si resuelve su problema, ya que dice que no tiene problemas con el sausuario, pero espero que ayude.

djeidot
fuente
5

Conmigo - Ejecutando en la ventana 8 - Haga clic derecho en SQL Server Manager Studio -> Ejecutar con administrador. -> adjuntar sin problemas

Lobo gris
fuente
5

se puede arreglar fácilmente pero radicalmente, solo vaya a la carpeta donde ha almacenado el archivo mdf . seleccione archivo-> haga clic con el botón derecho -> haga clic en propiedades y otorgue permisos completos al archivo para la seguridad del usuario conectado .

Ema.H
fuente
3

Cada vez que me he encontrado con este problema fue al intentar adjuntar una base de datos que se encuentra en un directorio diferente del directorio predeterminado de la base de datos que está configurado en el servidor SQL.

Recomiendo encarecidamente que, en lugar de realizar jacks con permisos en varios directorios y cuentas, simplemente mueva su archivo de datos al directorio que el servidor sql espera encontrar.

Yo no
fuente
En muchas situaciones, estaría de acuerdo con su punto, pero con el servidor SQL, a menudo desea poder ubicar sus bases de datos en diferentes ejes o volúmenes para la escalabilidad. De hecho, es una práctica común colocar el registro de transacciones en un eje separado de la base de datos para mejorar el rendimiento de las transacciones.
JMarsch
@JMarsch: Sí ... los directorios son realmente configurables a través de la pestaña Propiedades del servidor> Configuración de la base de datos para datos predeterminados y ubicaciones de registro ...
NotMe
Eso cubre los valores predeterminados, pero eso es solo valores predeterminados. Es completamente aceptable colocar dbs en otro lugar, y realmente no es tan raro si su servidor administra más de 1 base de datos utilizada activamente.
JMarsch
Tengo este mismo problema incluso con el directorio predeterminado del servidor sql: c: \ Archivos de programa \ Microsoft SQL Server \ MSSQL10_50.SPATIAL_IM \ MSSQL \ DATA \ mydb.mdf en win7.
goku_da_master
3

Solo quería agregar esta información también.

http://www.mssqltips.com/sqlservertip/2528/database-attach-failure-in-sql-server-2008-r2/

Solución

Obtiene este error porque dos inicios de sesión diferentes realizaron las operaciones de desconexión y conexión. Entonces, los archivos, cuando se separaron, pertenecían al primer inicio de sesión, pero el archivo adjunto falló porque el inicio de sesión que se utilizó no era el propietario de los archivos mdf y ldf.

Cuando separamos los archivos de la base de datos, el propietario se convierte en la persona que realizó el comando de desconexión, por lo que para resolver el problema, debemos cambiar o agregar el otro inicio de sesión como propietario de los archivos mdf y ldf.

Haga clic derecho en el archivo "filename.mdf" y seleccione las propiedades para verificar los permisos del archivo mdf. Aquí podemos ver que solo una cuenta tiene permiso para el archivo "filename.mdf" porque esa fue la cuenta que se utilizó para separar la base de datos.

Para resolver este problema, haga clic en el botón Agregar ... para agregar el otro inicio de sesión o cualquier otro inicio de sesión necesario y otorgar el control total de inicio de sesión. También debe hacer esto para el archivo "ldf". Una vez que haya completado esta tarea, haga clic en el botón Aceptar. (Tenga en cuenta que para otras versiones del sistema operativo puede tener una opción Editar, haga clic en esto primero y luego verá la opción Agregar ...).

tormenta salvaje
fuente
Cambié mi conexión en SSMS para que coincida con el usuario que realizó la separación, y pude realizar la conexión.
glitzsfa
2

Por lo que vale para cualquiera que tenga la variación particular de este problema que tuve:

  • SQL Express 2008
  • Visual Studio 2010 Premium

A través del menú contextual de la carpeta App_data, había creado una base de datos SQL Express para fines de depuración. La cadena de conexión (utilizada por NHibernate) fue la siguiente:

Server=.\SQLExpress;
AttachDbFilename=|DataDirectory|DebugDatabase.mdf;
Database=DebugDatabase;
Trusted_Connection=Yes;

Esto me dio el mismo error de "Acceso denegado" en el archivo de base de datos. Traté de dar a varios usuarios Control total de la carpeta y los archivos, en un punto incluso a "Todos". Nada ayudó, así que eliminé los permisos agregados nuevamente.

Lo que finalmente resolvió fue abrir el Explorador de servidores en Visual Studio, luego conectarse al MDF y desconectarlo nuevamente. Después de hacer eso, mi aplicación web podía acceder a la base de datos sin problemas.

PD. Los créditos van a esta publicación de blog que encontré al buscar en Google este problema en particular, lo que desencadenó la idea de adjuntar / separar la base de datos para resolver el problema.

Jeroen
fuente
2

Moví una base de datos mdf de la carpeta de datos predeterminada a mi carpeta asp.net app_data y me encontré con este problema al intentar configurar la base de datos nuevamente en línea.

Comparé la configuración de seguridad de las otras bases de datos de archivos en la ubicación original con los archivos movidos y noté que MSSQL $ SQLEXPRESS no tenía permisos asignados a los archivos en su nueva ubicación. Agregué Control total para "NT SERVICE \ MSSQL $ SQLEXPRESS" (debe incluir ese SERVICIO NT) y se adjuntó muy bien.

Parece que la carpeta de datos original tiene estos permisos y los archivos la heredan. Mueva los archivos y los saltos de herencia, por supuesto.

Revisé el archivo mdf de otro proyecto que creé directamente en su carpeta app_data. no tiene permisos MSSQL $ SQLEXPRESS. Hmmm Me pregunto por qué a SQL Express le gusta uno pero no el otro.

Brad Mathews
fuente
Esta solución funcionó para mí en Windows 10 y SQL Server 2017 cuando movía un archivo de registro a un disco separado. En mi caso, el nombre de usuario era "NT SERVICE \ MSSQLSERVER"
John Hanley
1

Esto suena como permisos NTFS. Por lo general, significa que su cuenta de servicio de SQL Server tiene acceso de solo lectura al archivo (tenga en cuenta que SQL Server usa la misma cuenta de servicio para acceder a los archivos de la base de datos independientemente de cómo inicie sesión). ¿Está seguro de que no cambió los permisos de la carpeta entre iniciar sesión como usted mismo e iniciar sesión como sa? Si se desconecta e intenta nuevamente, ¿sigue teniendo el mismo problema?

Adrian O'Connor
fuente
En mi caso, no, lo volví a hacer varias veces para asegurarme. El problema era que mi cuenta solo tenía acceso a los archivos a través de un nivel de indirección: era miembro del grupo Administrador de dominio. El administrador de dominio era miembro del grupo de administradores locales en la máquina, y los administradores locales (y el sistema) tenían el control total de la carpeta. (entonces hubo 2 niveles de indirección grupal). Si me asignaba permisos directamente, funcionaba, si los eliminaba, aún podía copiar / eliminar los archivos de Explorere, etc., pero SQL Server no podía cargarlos.
JMarsch
Cuando intente adjuntar la base de datos. Inicie sesión ya Windows authenticated userque nos ayudará a superar el permiso en los archivos de la base de datos. (Este caso, MS SQLServer instancia en el disco que tiene el sistema operativo Windows).
Do Nhu Vy
1

Tuve el mismo problema al adjuntar una base de datos. No fue un problema de SQL, fue un problema de cuenta. Vaya al panel de control / Configuración de control de cuenta de usuario / Configure a "nunca notificar" Finalmente, reinicie la computadora y funcionó para mí.

Paola
fuente
1

Adjunté el archivo mdf haciendo clic derecho en la base de datos y eliminando el archivo de registro AdventureWorks2012_Data_log.ldf en el asistente. El archivo mdf se colocó en la siguiente ubicación

    C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA

El método anterior me ayudó a resolver el problema.

Praveen
fuente
1

Estaba leyendo esta página y tienen una frase interesante allí:

Precaución: Sea muy selectivo al agregar usuarios a estos roles. Por ejemplo, sysadmin se asigna a dbo en cada base de datos y es el equivalente a iniciar sesión con la cuenta sa.

Por supuesto, también tienen esto:

Permisos que se otorgan a usuarios y roles y son específicos de la base de datos. Todos los permisos son acumulativos con la excepción de un DENY. Un permiso denegado a nivel de usuario o de rol anula el mismo permiso otorgado a través de otras membresías de roles, con la excepción del rol fijo de servidor sysadmin. (Un administrador de sistemas conserva todos los permisos, incluso si un rol del que es miembro tiene un permiso DENY).

Entonces, si usted es un administrador de dominio y en el grupo 'sysadmin' de SQL, el mundo debería ser su crustáceo.

Por supuesto, según Microsoft, debería echar un vistazo rápido a estas dos páginas:
Enlace a los requisitos previos de la base de datos

Enlace a la instalación de bases de datos

Estás siendo travieso e intentas adjuntarlos manualmente :) En serio, ¿tienes todos los requisitos previos para la base de datos AdventureWorks2008?
Sospecho que este es solo otro caso extraño de Microsoft, pero podría estar equivocado.

Trevoke
fuente
+1 porque tu comentario me ayudó a encontrar la respuesta. Publicaré mis hallazgos en este hilo. Por cierto (estaba siendo "travieso" debido a las políticas muy extrañas donde trabajo - la base de datos de Adventureworks se distribuye como un exe. No puedo descargar los exe. (Puedo descargar archivos zip y archivos MSI, así que no veo cómo el filtrado de exe realmente no hace nada más que interponerse, pero esas son las reglas). De todos modos, podría obtener los archivos mdf sin procesar como zips de codeplex, y fue entonces cuando me encontré con esta pequeña curiosidad.
JMarsch
1

ingrese la descripción de la imagen aquí

USE [master]
GO
CREATE DATABASE [DataBasename] ON 
( FILENAME = N'C:\data\DataBasename.mdf' )
 FOR ATTACH
GO

cambie a FOR ATTACH -> FOR ATTACH_FORCE_REBUILD_LOG

USE [master]
GO
CREATE DATABASE [DataBasename] ON 
( FILENAME = N'C:\data\DataBasename.mdf' )
 FOR ATTACH_FORCE_REBUILD_LOG
GO
Valentin Petkov
fuente
Gracias, me salvaste el día
Shahrokhian
1

Obtuve este error como sa. En mi caso, la seguridad de la base de datos no importó. Agregué a todos el control total a los archivos mdf y ldf, y el adjunto salió bien.

toddmo
fuente
1

Estaba enfrentando el mismo problema en VS 2019. si alguien todavía enfrenta el mismo problema, asegúrese de tener / hacer lo siguiente:

  1. Debe tener SQL Express instalado en su m / c
  2. Debería tener SSDT instalado en VS (en VS 2019, asegúrese de verificar este componente durante la instalación) para versiones anteriores, debe agregar este componente externamente
  3. Agregue 'User Instance = True' a su cadena de conexiones
  4. Creo que es opcional: abra VS y SQL Express en modo administrativo e inicie sesión como administrador en SQL Express
Ashu_90
fuente
0

De hecho, son permisos NTFS y un error extraño en SQL Server. No estoy seguro de que el informe de error anterior sea correcto o que pueda referirse a un error adicional.

Para resolver esto en Windows 7, ejecuté SQL Server Management Studio normalmente (no como administrador). Luego intenté adjuntar el archivo MDF. En el proceso, usé la interfaz de usuario en lugar de pegar en la ruta. Me di cuenta de que el camino estaba separado de mí. Esto se debe a que el usuario de MS SQL Server (SQLServerMSSQLUser $ machinename $ SQLEXPRESS) que el software agrega para usted no tiene permisos para acceder a la carpeta (en este caso, una carpeta en mis propias carpetas de usuario).

Pegar la ruta y continuar da como resultado el error anterior. Entonces, le di al usuario de MS SQL Server permisos para leer a partir del primer directorio desde el que se le negó (mi carpeta de usuario). Luego cancelé inmediatamente la operación de propagación porque puede llevar una eternidad, y nuevamente apliqué permisos de lectura a la siguiente subcarpeta necesaria, y dejé que se propagara por completo.

Finalmente, le di al usuario de MS SQL Server permisos de modificación para los archivos .mdf y .ldf para la base de datos.

Ahora puedo adjuntar a los archivos de la base de datos.

Chris Moschini
fuente
0

Si ejecuta sql server 2012, puede obtener este error al intentar adjuntar una versión anterior de un archivo mdf. ex un archivo mdf del servidor sql 2008.

Erik Forsmyr
fuente
Creo que esa parte fue relativamente autoexplicativa. Sería bueno saber cómo solucionarlo.
dansan 02 de
0

He resuelto el problema simplemente moviendo el archivo .mdf que desea adjuntar a la carpeta pública, en mi caso lo moví a la carpeta public / users. Luego lo adjunto desde allí sin ningún problema. Espero que esto ayude.

databaseUser
fuente
0

Para aquellos que no pudieron solucionar el problema con las otras soluciones aquí, la siguiente solución funcionó para mí:

Vaya a su carpeta "DATOS" en su instalación de SQL Server, haga clic derecho, propiedades, pestaña de seguridad y agregue permisos de control total para el usuario "SERVICIO DE RED".

http://decoding.wordpress.com/2008/08/25/sql-server-2005-expess-how-to-fix-error-3417/

(El enlace anterior es para SQL 2005, pero esto solucionó una instalación de SQL 2008 R2 para mí).

Alguna información adicional: Este problema apareció para mí después de reemplazar un disco duro secundario (en el que estaba la instalación de SQL). Copié todos los archivos y restauré la letra de la unidad original en el nuevo disco duro. Sin embargo, los permisos de seguridad no se copiaron. Creo que la próxima vez usaré un mejor método para copiar datos.

nuzzolilo
fuente
0

En mi caso, lo que resolvió el problema fue lo siguiente:

USE [master]
GO
CREATE DATABASE [AdventureWorks2008R2] ON
( FILENAME = 'C:\Program Files\Microsfot SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA\AdventureWors2008R2_Data.mdf')
FOR ATTACH_REBUILD_LOG
Mella_
fuente
0

Copie la base de datos a otra carpeta y adjunte o inicie sesión en SQLServer con "Autenticación de Windows"

ingrese la descripción de la imagen aquí

Chưa biết
fuente
0

Tuve el mismo problema al volver a conectar la base de datos después de separarla y mover archivos ldf y mdf de la unidad C a F.

Para solucionarlo, tuve que agregar el principal DERECHOS DEL PROPIETARIO a ambos archivos y le di el control total sobre ellos en la pestaña Seguridad del cuadro de diálogo Propiedades.

Arte
fuente