Migrar una base de datos de Access a SQL Server

Migrar una base de datos de Access a SQL Server

Todos tenemos límites y una base de datos de Access no es una excepción. Por ejemplo, una base de datos de Access tiene un límite de tamaño de 2 GB y no puede admitir más de 255 usuarios simultáneos. Así, cuando sea el momento de que su base de datos de Access vaya al siguiente nivel, puede migrar a SQL Server. SQL Server (ya sea local o en la nube de Azure) admite grandes cantidades de datos, más usuarios simultáneos y tiene mayor capacidad que el motor de base de datos JET/ACE. Esta guía le da un comienzo suave a su viaje de SQL Server, ayuda a conservar las soluciones front-end de Access que ha creado y, afortunadamente, le motiva a usar Access para futuras soluciones de bases de datos. El Asistente para convertir a SQL Server se ha quitado de Access en Access 2013, por lo que ahora puede usar el Asistente para la migración de Microsoft SQL Server (SSMA). Para migrar correctamente, siga estas fases.

Las fases de la migración de la base de datos a SQL Server

Antes de empezar

En las siguientes secciones se proporciona información general y otra información para ayudarle a comenzar.

Acerca de las bases de datos divididas

Todos los objetos de base de datos de Access pueden estar en un archivo de base de datos o se pueden almacenar en dos archivos de base de datos: una base de datos front-end y una base de datos back-end. Esto se denomina dividir la base de datos y está diseñada para facilitar el uso compartido en un entorno de red. El archivo de base de datos back-end debe contener solo tablas y relaciones. El archivo front-end debe contener todos los demás objetos, como formularios, informes, consultas, macros, módulos VBA y tablas vinculadas a la base de datos back-end. Al migrar una base de datos de Access, es similar a una base de datos dividida en la que SQL Server actúa como un nuevo back-end para los datos que se encuentran ahora en un servidor.

Como resultado, aún puede mantener la base de datos front-end de Access con tablas vinculadas a las tablas de SQL Server. De manera eficaz, puede obtener los beneficios de la programación rápida de aplicaciones que proporciona una base de datos de Access, junto con la escalabilidad de SQL Server.

Ventajas de SQL Server

¿Aún necesita algo convincente para migrar a SQL Server? A continuación se muestran algunos beneficios adicionales que debe considerar:

  • Más usuarios simultáneos    SQL Server puede controlar muchos más usuarios simultáneos que Access y minimiza los requisitos de memoria cuando se agregan más usuarios.

  • Mayor disponibilidad    Con SQL Server, puede realizar una copia de seguridad dinámica, ya sea incremental o completa, en la base de datos mientras está en uso. Por consiguiente, no es necesario que los usuarios salgan de la base de datos para hacer una copia de seguridad de los datos.

  • Alto rendimiento y escalabilidad    La base de datos de SQL Server generalmente funciona mejor que una base de datos de Access, especialmente con una base de datos grande de terabytes. Además, SQL Server procesa las consultas de forma mucho más rápida y eficaz al procesar las consultas en paralelo, con varios subprocesos nativos dentro de un único proceso para controlar las solicitudes de usuario.

  • Seguridad mejorada    Con una conexión de confianza, SQL Server se integra con la seguridad del sistema Windows para proporcionar un único acceso integrado a la red y la base de datos, lo que emplea lo mejor de ambos sistemas de seguridad. Esto facilita mucho más la administración de esquemas de seguridad complejos. SQL Server es el almacenamiento ideal para información confidencial, como números de la seguridad social, datos de la tarjeta de crédito y direcciones confidenciales.

  • Capacidad de recuperación inmediata    Si el sistema operativo se bloquea o se enciende el suministro eléctrico, SQL Server puede recuperar automáticamente la base de datos a un estado coherente en cuestión de minutos y sin intervención del administrador de la base de datos.

  • Uso de VPN    El acceso y las redes privadas virtuales (VPN) no se conseguirán. Pero con SQL Server, los usuarios remotos pueden usar aún la base de datos front-end de Access en un equipo de escritorio y el back-end de SQL Server ubicado tras el Firewall VPN.

  • Azure SQL Server    Además de las ventajas de SQL Server, ofrece escalabilidad dinámica sin tiempo de inactividad, optimización inteligente, escalabilidad global y disponibilidad, eliminación de costos de hardware y administración reducida.

Elegir la mejor opción de Azure SQL Server

Si va a migrar a Azure SQL Server, hay tres opciones entre las que elegir, cada una con diferentes beneficios:

  • Base de datos única/grupos elásticos    Esta opción tiene su propio conjunto de recursos administrados a través de un servidor de base de datos SQL. Una única base de datos es como una base de datos independiente en SQL Server. También puede Agregar un grupo elástico, que es una colección de bases de datos con un conjunto compartido de recursos administrados a través del servidor de base de datos SQL. Las características de SQL Server más usadas están disponibles con copias de seguridad, revisiones y recuperación integradas. Sin embargo, no hay un tiempo de mantenimiento exacto garantizado y la migración de SQL Server puede ser difícil.

  • Instancia administrada    Esta opción es una colección de bases de datos de usuario y de sistema con un conjunto de recursos compartido. Una instancia administrada es como una instancia de la base de datos de SQL Server que es muy compatible con SQL Server local. Una instancia administrada tiene copias de seguridad integradas, revisiones, recuperación y es fácil migrar desde SQL Server. Sin embargo, hay un pequeño número de características de SQL Server que no están disponibles y no tienen garantizado un tiempo de mantenimiento exacto.

  • Máquina Virtual de Azure    Esta opción le permite ejecutar SQL Server dentro de una máquina virtual en la nube de Azure. Tiene control total sobre el motor de SQL Server y una sencilla ruta de migración. Pero necesita administrar las copias de seguridad, los parches y la recuperación.

Para obtener más información, vea elegir la ruta de migración de la base de datos a Azure y elegir la opción de SQL Server correcta en Azure.

Primeros pasos

Hay algunos problemas que puede solucionar y que pueden ayudar a simplificar el proceso de migración antes de ejecutar SSMA:

  • Agregar índices de tabla y claves principales    Asegúrese de que cada tabla de Access tiene un índice y una clave principal. SQL Server requiere que todas las tablas tengan al menos un índice y que una tabla vinculada tenga una clave principal si la tabla se puede actualizar.

  • Comprobar las relaciones entre claves principales y externas    Asegúrese de que estas relaciones se basan en campos con tipos de datos y tamaños coherentes. SQL Server no admite columnas combinadas con diferentes tipos de datos y tamaños en restricciones de clave externa.

  • Quitar la columna datos adjuntos    SSMA no migra las tablas que contienen la columna de datos adjuntos.

Antes de ejecutar SSMA, realice los siguientes pasos.

  1. Cierre la base de datos de Access.

  2. Asegúrese de que los usuarios actuales conectados a la base de datos también cierran la base de datos.

  3. Si la base de datos está en formato de archivo. mdb, Quite la seguridad de nivel de usuario.

  4. Haga una copia de seguridad de la base de datos. Para obtener más información, vea proteger los datos con procesos de copia de seguridad y restauración.

Sugerencia    Considere instalar Microsoft SQL Server Express Edition en su escritorio, que admite hasta 10 GB y es una forma gratuita y más fácil de realizar y comprobar la migración. Cuando se conecte, use LocalDB como instancia de base de datos.

Sugerencia    Si es posible, use una versión independiente de Access. Si solo puede usar Office 365, use el motor de base de datos de Access 2010 para migrar la base de datos de Access al usar SSMA. Para obtener más información, vea motor de base de datos de Microsoft Access 2010redistribuible.

Ejecute SSMA

Microsoft proporciona el Asistente de migración de Microsoft SQL Server (SSMA) para facilitar la migración. SSMA migra principalmente las tablas y las consultas de selección sin parámetros. Los formularios, informes, macros y módulos VBA no se convierten. El explorador de metadatos de SQL Server muestra los objetos de base de datos de Access y los objetos de SQL Server, lo que le permite revisar el contenido actual de ambas bases de datos. Estas dos conexiones se guardan en el archivo de migración en caso de que decida transferir más objetos en el futuro.

Nota    El proceso de migración puede llevar algún tiempo según el tamaño de los objetos de la base de datos y la cantidad de datos que se deben transferir.

  1. Para migrar una base de datos con SSMA, primero Descargue e instale el software haciendo doble clic en el archivo MSI descargado. Asegúrese de instalar la versión de 32 o 64 bits adecuada para su equipo.

  2. Después de instalar SSMA, ábralo en el escritorio, preferiblemente desde el equipo con el archivo de base de datos de Access.

    También puede abrirlo en un equipo que tenga acceso a la base de datos de Access desde la red en una carpeta compartida.

  3. Siga las instrucciones iniciales de SSMA para proporcionar información básica, como la ubicación de SQL Server, la base de datos y los objetos de Access que se van a migrar, la información de conexión y si desea crear tablas vinculadas.

  4. Si va a migrar a SQL Server 2016 o posterior y desea actualizar una tabla vinculada, agregue una columna rowversion seleccionando revisar herramientas > configuración del proyecto > General.

    El campo rowversion ayuda a evitar conflictos de registro. Access usa este campo rowversion en una tabla vinculada de SQL Server para determinar cuándo se actualizó por última vez el registro. Además, si agrega el campo rowversion a una consulta, Access lo usa para volver a seleccionar la fila después de una operación de actualización. Esto mejora la eficiencia al ayudar a evitar errores de conflicto de escritura y los escenarios de eliminación de registros que pueden ocurrir cuando Access detecta resultados diferentes de la presentación original, por ejemplo, con tipos de datos de números de punto flotante y desencadenadores que modifican columnas. Sin embargo, evite usar el campo rowversion en formularios, informes o código de VBA. Para obtener más información, vea rowversion.

    Nota    Evite confundir rowversion con las marcas de hora. Aunque la marca de hora de la palabra clave es un sinónimo de rowversion en SQL Server, no puede usar rowversion como una forma de marcar una entrada de datos.

  5. Para establecer tipos de datos precisos, seleccione revisar herramientas > la configuración del proyecto > asignación de tipos. Por ejemplo, si solo almacena texto en inglés, puede usar el tipo de datos VARCHAR en lugar de nvarchar .

Convertir objetos

SSMA convierte objetos de Access en objetos de SQL Server, pero no copia los objetos inmediatamente. SSMA proporciona una lista de los siguientes objetos para migrar, de modo que pueda decidir si desea moverlos a la base de datos de SQL Server:

  • Tablas y columnas

  • Seleccione consultas sin parámetros.

  • Claves principales y externas

  • Índices y valores predeterminados

  • Restricciones check (permitir propiedad de columna longitud cero, regla de validación de columna, validación de tabla)

Como práctica recomendada, use el informe de evaluación de SSMA, que muestra los resultados de la conversión, incluidos errores, advertencias, mensajes informativos, cálculos de tiempo para realizar la migración y pasos de corrección de errores individuales antes de mover realmente el objeto.

La conversión de objetos de base de datos toma las definiciones de objeto de los metadatos de Access, los convierte en Sintaxis Transact-SQL (T-SQL)equivalente y, después, carga esta información en el proyecto. A continuación, puede ver los objetos de SQL Server o SQL Azure y sus propiedades con SQL Server o el explorador de metadatos de SQL Azure.

Para convertir, cargar y migrar objetos a SQL Server, siga esta guía.

Sugerencia    Una vez que haya migrado correctamente su base de datos de Access, guarde el archivo de proyecto para su uso posterior, de modo que pueda volver a migrar los datos para realizar pruebas o migraciones finales.

Vincular tablas

Considere la posibilidad de instalar la última versión de los controladores OLE DB y ODBC de SQL Server en lugar de usar los controladores de SQL Server nativos que se distribuyen con Windows. No solo son más rápidos los drivers más recientes, pero admiten nuevas características de Azure SQL que los drivers anteriores no. Puede instalar los drivers en cada equipo en el que se use la base de datos convertida. Para obtener más información, consulte controlador Microsoft OLE DB 18 para SQL Server y Microsoft ODBC driver 17 para SQL Server.

Después de migrar las tablas de Access, puede establecer un vínculo a las tablas de SQL Server que ahora hospedan los datos. Vincular directamente desde Access también le proporciona una forma más sencilla de ver los datos en lugar de usar las herramientas de administración de SQL Server más complejas.  Puede consultar y modificar datos vinculados en función de los permisos configurados por el administrador de la base de datos de SQL Server.

Nota    Si crea un DSN de ODBC al vincular a la base de datos de SQL Server durante el proceso de vinculación, puede crear el mismo DSN en todos los equipos que usen la nueva aplicación o usar la cadena de conexión almacenada en el archivo DSN mediante programación.

Para obtener más información, vea vincular a datos o importar datos desde una base de datos de Azure SQL Server e importar o vincular a datos en una base de datos de SQL Server.

Sobre   No olvide usar el administrador de tablas vinculadas en Access para actualizar y volver a vincular las tablas de forma conveniente. Para obtener más información, vea administrar tablas vinculadas.

Probar y revisar

En las siguientes secciones, se describen los problemas comunes que pueden surgir durante la migración y cómo solucionarlos.

Consultas

Solo se convierten las consultas de selección; otras consultas no son, incluidas las consultas de selección que toman parámetros. Es posible que algunas consultas no se conviertan completamente y SSMA informe de errores de consulta durante el proceso de conversión. Puede editar manualmente los objetos que no se convierten mediante la sintaxis T-SQL. Los errores de sintaxis también pueden requerir la conversión manual de funciones específicas de Access y tipos de datos en SQL Server. Para obtener más información, vea comparación de Access SQL con SQL Server TSQL.

Tipos de datos

Access y SQL Server tienen tipos de datos similares, pero tenga en cuenta los siguientes posibles problemas.

Número grande    El tipo de datos número grande almacena un valor numérico no monetario y es compatible con el tipo de datos BIGINT de SQL. Puede usar este tipo de datos para calcular eficazmente números grandes pero requiere usar el formato de archivo de base de datos. accdb de Access 16 (16.0.7812 o posterior) y funciona mejor con la versión de Access de 64 bits. Para obtener más información, vea usar el tipo de datos número grande y elegir entre la versión de 64 o 32 bits de Office.

Sí/No    De forma predeterminada, una columna sí/no de Access se convierte en un campo de bits de SQL Server. Para evitar el bloqueo de registros, Asegúrese de que el campo de bits está establecido en no permitir valores NULOs. EN SSMA, puede seleccionar la columna bit para establecer la propiedad permitir valores nulos en no. En TSQL, use las instrucciones CREATE TABLE o ALTER TABLE .

Fecha y hora    Hay varias consideraciones acerca de la fecha y la hora:

  • Si el nivel de compatibilidad de la base de datos es 130 (SQL Server 2016) o superior, y una tabla vinculada contiene una o más columnas datetime o datetime2, la tabla puede devolver el mensaje #deleted en los resultados. Para obtener más información, vea la tabla vinculada de Access a la base de datos de SQL Server devuelve #deleted.

  • Use el tipo de datos datetime2 , que tiene un intervalo de fechas mayor que DateTime.

  • Al consultar fechas en SQL Server, tenga en cuenta la hora, además de la fecha. Por ejemplo:

    • Es posible que DateOrdered entre 1/1/19 y 1/31/19 no incluya todos los pedidos.

    • DateOrdered entre 1/1/19 00:00:00 A.M. y 1/31/19 11:59:59 P.M. incluye todos los pedidos.

Datos adjuntos   El tipo de datos datos adjuntos almacena un archivo en una base de datos de Access. En SQL Server, tiene varias opciones que puede tener en cuenta. Puede extraer los archivos de la base de datos de Access y, a continuación, considerar almacenar vínculos a los archivos de la base de datos de SQL Server. Como alternativa, puede usar FILESTREAM, FileTables o el almacén remoto de BLOBs (RBS) para mantener los datos adjuntos almacenados en la base de datos de SQL Server.

Hipervínculo    Las tablas de Access tienen columnas de hipervínculos que SQL Server no admite. De forma predeterminada, estas columnas se convierten en columnas nvarchar (Max) en SQL Server, pero puede personalizar la asignación para elegir un tipo de datos más pequeño. En su solución de Access, aún puede usar el comportamiento de hipervínculo en formularios e informes si establece la propiedad HYPERLINK para el control en true.

Campo multivalor    El campo multivalor de Access se convierte en SQL Server como un campo ntext que contiene el conjunto delimitado de valores. SQL Server no admite un tipo de datos multivalor que modele una relación de varios a varios, por lo que podrían hacer falta trabajos de conversión y diseño adicionales.

Para obtener más información sobre la asignación de tipos de datos de Access y SQL Server, vea comparar tipos de datos.

Nota    Los campos multivalor no se convierten y ya no se usan en Access 2010.

Para obtener más información, vea tipos de fecha y hora, cadenas y tipos binarios, y tipos numéricos.

Visual Basic

Aunque VBA no es compatible con SQL Server, tenga en cuenta los siguientes problemas posibles:

Funciones de VBA en consultas    Las consultas de Access admiten funciones de VBA en los datos de una columna de consulta. Pero las consultas de Access que usan funciones de VBA no se pueden ejecutar en SQL Server, por lo que todos los datos solicitados se pasan a Microsoft Access para su procesamiento. En la mayoría de los casos, estas consultas deben convertirse en consultas de paso a través.

Funciones definidas por el usuario en consultas    Las consultas de Microsoft Access admiten el uso de funciones definidas en módulos de VBA para procesar los datos que se les pasan. Las consultas pueden ser consultas independientes, instrucciones SQL en orígenes de registros de formularios o informes, orígenes de datos de cuadros combinados y cuadros de lista de formularios, informes y campos de tabla, y expresiones de regla de validación o predeterminadas. SQL Server no puede ejecutar estas funciones definidas por el usuario. Es posible que tenga que volver a diseñar manualmente estas funciones y convertirlas en procedimientos almacenados en SQL Server.

Optimizar el rendimiento

Por el momento, la manera más importante de optimizar el rendimiento con su nuevo SQL Server back-end es decidir cuándo usar consultas locales o remotas. Al migrar los datos a SQL Server, también está cambiando de un servidor de archivos a un modelo de base de datos cliente-servidor de Computing. Siga estas pautas generales:

  • Ejecute consultas pequeñas y de solo lectura en el cliente para obtener acceso más rápido.

  • Ejecute consultas largas, de lectura y escritura en el servidor para aprovechar la mayor potencia de procesamiento.

  • Minimice el tráfico de red con filtros y agregación para transferir solo los datos que necesite.

Optimizar el rendimiento en el modelo de base de datos cliente Server

Para obtener más información, vea crear una consulta de paso a través.

A continuación se muestran directrices recomendadas adicionales.

Incluir lógica en el servidor    Su aplicación también puede usar vistas, funciones definidas por el usuario, procedimientos almacenados, campos calculados y desencadenadores para centralizar y compartir la lógica de la aplicación, las reglas y directivas empresariales, las consultas complejas, la validación de datos y el código de integridad referencial en el servidor, en lugar de hacerlo en el cliente. Pregúntese, ¿se puede realizar esta consulta o tarea en el servidor mejor y más rápido? Por último, pruebe cada consulta para garantizar un rendimiento óptimo.

Usar vistas en formularios e informes    En Access, haga lo siguiente:

  • Para los formularios, use una vista SQL para un formulario de solo lectura y una vista indizada de SQL para un formulario de lectura y escritura como origen de registros.

  • Para los informes, use una vista SQL como origen de registros. Sin embargo, cree una vista independiente para cada informe, de modo que pueda actualizar fácilmente un informe específico sin afectar a otros informes.

Minimizar la carga de datos en un formulario o informe    No Mostrar datos hasta que el usuario lo pida. Por ejemplo, mantenga la propiedad OrigenDelRegistro en blanco, haga que los usuarios seleccionen un filtro en el formulario y, a continuación, rellene la propiedad OrigenDelRegistro con el filtro. O bien, use la cláusula WHERE de DoCmd. OpenForm y DoCmd. OpenReport para mostrar los registros exactos necesarios para el usuario. Considere desactivar la navegación de los registros.

Tenga cuidado con las consultas heterogéneas   Evite ejecutar una consulta que combine una tabla de Access local y una tabla vinculada de SQL Server, a veces denominada consulta híbrida. Este tipo de consulta aún requiere que Access descargue todos los datos de SQL Server a la máquina local y, a continuación, ejecute la consulta, no ejecuta la consulta en SQL Server.

Cuándo usar tablas locales    Considere la posibilidad de usar tablas locales para datos que raramente modifica, como la lista de Estados o provincias de un país o una región. Las tablas estáticas se usan a menudo para filtrar y pueden funcionar mejor en el front-end de Access.

Para obtener más información, vea Asistente para la optimización del motor de base de datos, usar el analizador de rendimiento para optimizar una base de datos de Accessy optimizar aplicaciones de Microsoft Office Access vinculadas a SQL Server.

Vea también

Guía de migración de Azure Database

blog de migración de datos de Microsoft

Microsoft Access para la migración, conversión y conversión de SQL Server

Formas de compartir una base de datos de escritorio de Access

Nota:  Esta página se ha traducido mediante un sistema automático y es posible que contenga imprecisiones o errores gramaticales. Nuestro objetivo es que este contenido le resulte útil. ¿Podría decirnos si la información le resultó útil? Aquí puede consultar el artículo en inglés.

Ampliar sus conocimientos de Office
Explorar los cursos
Obtener nuevas características primero
Únase a los participantes de Office Insider

¿Le ha sido útil esta información?

¡Gracias por sus comentarios!

Gracias por sus comentarios. Quizá le interese ponerse en contacto con uno de nuestros agentes de soporte de Office.

×