SSIS transferencia de tareas de base de datos críptico mensaje de error 0x80131500

Question

estoy usando SSIS con VS2010 (shell) y las bases de datos que van desde SQL Server 2005 (32 bits) a SQL Server 2012 (64 bits). Estoy desarrollando directamente en el servidor de destino (no es óptimo, pero funciona).

Cuando intento utilizar la tarea Transferir base de datos, aparece un mensaje de error como el siguiente: "Error: El método Execute en la tarea devolvió el código de error 0x80131500 (Se produjo un error al transferir datos. Consulte la excepción interna para detalles.). El método Execute debe tener éxito e indicar el resultado usando un parámetro "out".

Aquí está el problema ... ¿cómo veo una "excepción interna"? ¡es una interfaz GUI sin forma de recorrer el código! Incluso intenté setting up logging - simplemente registra el mismo mensaje de error inútil.

Microsoft no tiene información de este código de error en sus documentos de referencia (que pude encontrar).

Después googleing el código de error, vi que otros tienen este código de error junto con los mensajes que tienen que ver con los usuarios, roles, y la creación de ellos.

• hago doble comprobado que tengo derechos de administrador de sistemas en ambos servidores, y
  inicios de sesión en ambos.
• Probé la misma tarea Transferir bases de datos de cada servidor a sí mismo (con changeing nombre de base de datos) y que trabajaron bien para tanto por sí mismos.
• Intenté ambas opciones, DatabaseOnline y DatabaseOffline. (Mismo error en ambos sentidos)
• He intentado hacer una tarea "Transferir inicios de sesión" antes de hacer la tarea de base de datos de transferencia, que trabajó tarea, pero no la tarea de transferencia de bases de datos. Luego comenzó a arrojar errores diciendo que las bases de datos no existen, lo que implica que necesito transferir los inicios de sesión DESPUÉS de transferir las bases de datos.

Aquí están mis ajustes:

¿Qué estoy haciendo mal? O ¿cómo puedo obtener el mensaje de "excepción interna"?

Además, siga mi mensaje a los foros de Microsoft aquí: http://social.technet.microsoft.com/Forums/en-US/sqlintegrationservices/thread/cda53c80-8da6-4ed1-898a-9f3ff8464ae2

Answer 1

Esta respuesta me hace mal del estómago ... espero salvar a otra persona esta molestia. El problema era este:

1. Lo primero y más importante: el mensaje de error no era lo suficientemente descriptivo. El error debe ser entregado a la interfaz.
2. En "Editar" en una tarea "Transferir base de datos", las rutas del archivo de destino se "completan automáticamente" con las rutas de archivos de la base de datos de origen. Miran directamente al primer vistazo (y segundo, y tercero ...). Tras una inspección adicional , las rutas del archivo estaban equivocadas. Esto tiene sentido si va de una versión a otra: las carpetas se nombran con sutiles diferencias según la versión (MSSQL.1 frente a MSSQL11.<instanceName>).

En resumen, el error fue causado por la carpeta que no existe porque la ruta fue establecida incorrectamente. Imagino que otras excepciones de bajo nivel como este también son consumidas por la interfaz con el mismo mensaje de error críptico.

Answer 2

"which implies that I need to transfer logins AFTER I transfer databases."

no realmente, los inicios de sesión están en un servidor (instancia) de nivel para que pueda transferir los inicios de sesión y luego la base de datos. Debería preocuparse por los usuarios más tarde, por supuesto

un punto aquí, no creo que SSIS esté preparado para transferir 2005 -> 2012. Quiero decir, no tendría sentido "omitir" una versión. Dijiste que estás usando VS 2012, por lo que sería SSIS 2012. Cree que solo puede leer bases de datos de 2008. El hecho de que haya probado en el mismo servidor y funcionó también fortalece este punto.

Answer 3

Nos encontramos con esto donde alguien nos dijo que una fecha válida siempre existiría en la columna en una base de datos MySQL y descubrimos más tarde que había fechas como '0000-00-00 00:00:00' y '0001-01-01 00:00:00'.

lo manejamos en la consulta que tira de los datos mediante una declaración de caso para convertir la mala cita en una SSIS fecha puede utilizar:

CASE WHEN Product.PurchaseDate < '1900-01-01 00:00:00' THEN '1900-01-01 00:00:00' ELSE Product.PurchaseDate END AS PurchaseDate 

Por supuesto, se puede establecer a null también, su elección.

Answer 4

También he tenido este mismo problema y resultó ser un problema de acceso. Intente darles acceso a la carpeta donde desembarcarán los archivos mdf e ldf: NT Service \ MSSQLSERVER, Owner Creator, System

Answer 5

Esto es antiguo, pero me topé con el mismo mensaje críptico con SSMS 17.2. Intenté y verifiqué todas las sugerencias anteriores sin ningún resultado. En mi caso, el problema estaba relacionado con la propiedad TargetServerVersion del proyecto SSIS en Visual Studio 2017. De manera predeterminada, esto se estableció en SQL Server 2017, mientras que mi servidor local era SQL Server 2014; una vez cambiada a la misma, todo transcurrió sin problemas.