Está en la página 1de 8

Cómo cargar datos de Excel en

SSIS: 32 bits frente a 64 bits


Supongamos que está desarrollando un paquete SSIS en su cuadro de
desarrollo para cargar datos de un archivo de Excel a SQL Server. Para este
ejemplo, supongamos que su cuadro dev es Windows 7 de 64 bits con SQL
Server 2012, y la versión de Excel está por encima de 2007 (lo que significa
que está utilizando un archivo "xlsx").
Entonces, inicia las Herramientas de datos de SQL Server, crea un nuevo
proyecto de SQL Server Integration Services y arrastra una Tarea de flujo de
datos en el área de diseño de flujo de control. A continuación, vaya al área de
diseño de flujo de datos y arrastre el componente Fuente de Excel. Usted crea
un nuevo administrador de conexión de Excel que apunta al archivo de Excel,
elige "Tabla o Vista" como el modo de acceso a datos, y luego desea elegir la
tabla u hoja dentro del archivo de Excel.
Pero el único elemento en la lista es "No se pueden cargar tablas o vistas", y
también recibirá un mensaje de error que se ve así:

De acuerdo con el mensaje de error, el administrador de conexión no pudo


conectarse a la fuente. Así que echemos un vistazo al administrador de
conexión:
No hay mucho que hacer aquí ... Entonces, ¿cuál es el problema?
Si me preguntas, el primer problema aquí es que el mensaje de error no es
claro y no proporciona ninguna información útil sobre la causa del problema o
cómo tratarlo. Aquí hay un buen truco para obtener un mejor mensaje de error
de la herramienta. Regrese al editor fuente de Excel, elija "Comando SQL"
como el modo de acceso a datos y escriba una consulta en el cuadro "Texto de
comando SQL", como este:

Ahora cuando haces clic en "Aceptar", recibes el siguiente mensaje de error:


Esta es mejor. Es feo, pero proporciona información más útil, y tenemos alguna
pista sobre el siguiente paso.
Entonces, ¿qué está pasando?
El administrador de conexión de Excel está intentando utilizar el proveedor
ACE OLE DB para acceder al archivo Excel cuando la versión está por encima
de 2007 (xlsx). De acuerdo con este mensaje, este proveedor no está
registrado en su cuadro de desarrollo, por lo que no puede usarlo, y esta es la
razón por la cual falla.
Entonces, el siguiente paso es descargar e instalar el proveedor de ACE OLE
DB. Está incluido en el "redistribuible de Microsoft Access Database Engine
2010", que puede descargar aquí . Cuando hace clic en "Descargar", se le
presentan dos descargas opcionales: una para el tiempo de ejecución de 32
bits y la otra para el tiempo de ejecución de 64 bits.

Como está utilizando un cuadro de 64 bits, elige la versión de 64 bits de la


descarga. Tiene sentido, ¿verdad? Usted descarga e instala el proveedor, e
intenta elegir la tabla de Excel dentro del Editor de origen de Excel, pero
obtiene el mismo error. ¿Ahora que?
Ahora es el momento de explicar lo que está pasando ...
Aunque su caja es de 64 bits, está usando SQL Server Data Tools, que es una
aplicación de 32 bits. No hay una versión de 64 bits para SSDT, por lo que no
tiene otra opción aquí. Por cierto, esto es cierto para cualquier aplicación de
Visual Studio, no solo SSDT. Cuando diseña su paquete dentro de SSDT, está
utilizando un proceso de 32 bits, que solo puede usar proveedores de 32
bits. Cuando intenta elegir la tabla en el archivo Excel, el administrador de
conexión necesita acceder a la versión de 32 bits del proveedor ACE OLE DB,
pero este proveedor no está registrado en su máquina, solo está instalada la
versión de 64 bits.
Continúe y descargue la versión de 32 bits de "Microsoft Access Database
Engine 2010 Redistributable". Cuando intente instalarlo, recibirá el siguiente
mensaje de error:

No se preocupe, no necesita desinstalar Office por completo, solo la versión de


64 bits de "Microsoft Access Database Engine 2010 Redistributable", que
instaló previamente. La versión de 64 bits y la versión de 32 bits no pueden
vivir juntas en el mismo host, por lo que deberá desinstalar (a través de
"Programa y características") e instalar la otra si desea cambiar entre ellas.
Una vez que termine de desinstalar la versión de 64 bits e instalar la versión de
32 bits del proveedor, se resuelve el problema y finalmente puede elegir la
tabla dentro del archivo de Excel. El administrador de conexión de Excel ahora
puede usar el proveedor de ACE OLE DB (versión de 32 bits) para acceder al
archivo de Excel. ¡Estupendo!
Ahora puede arrastrar un destino OLE DB, configurarlo para conectarse a una
tabla de SQL Server, conectarse entre el origen y el destino, asignar las
columnas correctamente y su paquete está listo.
Pero cuando intenta ejecutar el paquete, el componente Fuente de Excel falla
...
Puede ver todos los errores en la pestaña Progreso. El error es similar a lo que
hemos visto antes, diciendo que el proveedor ACE OLE DB no está
registrado. ¿Pero no nos hemos ocupado ya de ese problema? Instalamos la
versión de 32 bits del proveedor y vimos que el administrador de conexión
podía acceder al archivo de Excel. Entonces, ¿cuál es el problema ahora?
Mientras que el diseñador dentro de SSDT solo puede trabajar con un
proveedor de versiones de 32 bits (siendo una aplicación de 32 bits), puede
elegir ejecutar el paquete desde SSDT en modo de 64 bits. En realidad, este es
el valor predeterminado en una máquina de 64 bits. ¿Cómo haces eso? En el
menú Proyecto, haga clic en las propiedades de su proyecto y luego vaya a la
pestaña Depuración (en "Propiedades de configuración"). Una de las
propiedades que puede configurar es "Run64BitRuntime".
Cuando esta propiedad se establece en "True" y ejecuta un paquete en este
proyecto desde SSDT, el paquete se ejecuta en modo de 64 bits. Cuando se
establece en "False" y ejecuta un paquete, se ejecuta en modo de 32 bits. Esta
es una característica importante, ya que le permite probar su paquete en su
caja de desarrollo de la forma en que se ejecutará en producción, incluso si su
cuadro de desarrollo no está configurado de la misma manera, e incluso si su
entorno de desarrollo (SSDT) ) es una aplicación de 32 bits.
El problema ahora es que está intentando ejecutar el paquete en modo de 64
bits, pero solo tiene la versión de 32 bits del proveedor ACE OLE DB en su
máquina. Este es el mismo problema que antes, pero desde la otra
dirección. Si cambia la propiedad "Run64BitRuntime" a "False", podrá ejecutar
el paquete correctamente.

Eso es genial, pero no es lo suficientemente bueno. Como mencioné


anteriormente, si su entorno de producción es de 64 bits, entonces debe probar
su paquete en un entorno de 64 bits. Actualmente se sabe que el paquete se
ejecuta correctamente en un entorno de 32 bits, pero no necesariamente
significa que se ejecutará sin problemas en un entorno de 64 bits. Entonces,
¿cómo puedes probar tu paquete en un entorno de 64 bits?
Una forma es implementar el paquete en una máquina de 64 bits (también
puede ser su caja de desarrollo) y ejecutar el paquete en modo de 64 bits (no
desde SSDT). Este método le asegurará que su paquete se está ejecutando (o
no), pero no tendrá ninguna capacidad de depuración como la que tiene en
SSDT. Entonces, ¿cómo podemos ejecutar el paquete en modo de 64 bits
desde SSDT? La respuesta es simple. Ahora que hemos terminado con el
diseño del paquete, ya no necesitamos la versión de 32 bits del proveedor ACE
OLE DB (al menos por ahora), así que podemos cambiar a la versión de 64 bits
del proveedor nuevamente (desinstalar e instalar, ¿recuerdas?).
Tan pronto como tenga instalada la versión de 64 bits del proveedor, debe
cambiar la propiedad "Run64BitRuntime" a "True", y debería estar listo para
continuar. Bueno, casi ... Ahora recibes el siguiente mensaje de error de
validación del paquete:
¿Ahora que?
Esto es complicado. Cada vez que se ejecuta un paquete, primero pasa por
una fase de validación antes de que comience la ejecución real. El objetivo de
esta validación es verificar que todo esté configurado correctamente antes de
intentar ejecutar el paquete para evitar un error en el tiempo de
ejecución. Dado que esta validación se produce antes de que se ejecute el
paquete, se realiza mediante SSDT, que se ejecuta en modo de 32 bits,
independientemente del valor de "Run64BitRuntime", que solo afecta al entorno
de la ejecución del tiempo de ejecución. Como actualmente solo tiene la
versión de 64 bits del proveedor ACE OLE DB y no la versión de 32 bits, SSDT
no puede usar el proveedor y la validación falla.
Si lo piensas, estás atrapado. Si instala la versión de 32 bits del proveedor ACE
OLE DB, puede pasar la validación, pero no podrá ejecutar el paquete en modo
de 64 bits. Por otro lado, si instala la versión de 64 bits del proveedor, entonces
puede (teóricamente) ejecutar el paquete en modo de 64 bits, pero no puede
llegar a ese punto, porque no pasa la validación ...
La forma de evitar este problema es utilizar la propiedad "DelayValidation" de la
tarea de flujo de datos. El valor predeterminado de esta propiedad es "False",
lo que significa que la tarea se valida antes de que el paquete comience su
ejecución (como se describe arriba). Si cambia esta propiedad a "Verdadero",
la tarea se validará solo en tiempo de ejecución, justo antes de que se
ejecute. Como la validación ahora ocurre en el tiempo de ejecución, es
realizada por el proceso que ejecuta el paquete, que es controlado por la
propiedad "Run64BitRuntime". Entonces, esta validación ocurre en un entorno
de 64 bits y puede usar el proveedor de 64 bits.

¡Victoria al fin!
La propiedad "DelayValidation" tiene muchos otros usos. Además, no hemos
cubierto la ejecución del paquete fuera de SSDT (por ejemplo, desde un trabajo
de SQL Server Agent) en un entorno de 32 bits frente a un entorno de 64
bits. Estos temas están más allá del alcance de esta publicación.
Si desea obtener más información sobre estos temas o cualquier otro tema
relacionado con SSIS, asista a mi curso sobre SSIS a partir del 6 de marzo. Es
un curso integral de cinco días que cubre todo lo que necesita saber para sacar
el máximo provecho de esta plataforma. Puede encontrar más información
sobre el curso aquí .