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. Por lo tanto, cuando llegue el momento de que la 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 ofrece un comienzo sin problemas para su viaje de SQL Server, ayuda a conservar las soluciones front-end de Access que ha creado y, con suerte, le motiva a usar Access para futuras soluciones de base de datos. El Asistente para cambiar el tamaño se quitó de Access en Access 2013, por lo que ahora puede usar el Asistente Microsoft SQL Server migración (SSMA). Para migrar correctamente, siga estas fases.

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

Antes de empezar

En las secciones siguientes se proporciona información de fondo y otra información que le ayudará a empezar.

Acerca de bases de datos divididas

Todos los objetos de base de datos de Access pueden estar en un archivo de base de datos o pueden almacenarse 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ñado para facilitar el uso compartido en un entorno de red. El archivo de base de datos back-end solo debe contener tablas y relaciones. El archivo front-end solo debe contener todos los demás objetos, incluidos 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 ese SQL Server actúa como un nuevo back-end para los datos que se encuentran ahora en un servidor.

Como resultado, puede mantener la base de datos de Access front-end con tablas vinculadas a las tablas SQL Server usuario. De forma eficaz, puede obtener las ventajas del desarrollo rápido de aplicaciones que proporciona una base de datos de Access, junto con la escalabilidad de SQL Server.

SQL Server beneficios

¿Todavía necesita algo de convencimiento para migrar a SQL Server? Estas son algunas ventajas adicionales en las que pensar:

  • 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, de 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 SQL Server base de datos suele tener un mejor rendimiento que una base de datos de Access, especialmente con una base de datos grande de tamaño terabyte. Además, SQL Server las consultas de forma mucho más rápida y eficiente procesando consultas en paralelo, usando varios hilos nativos dentro de un solo proceso para administrar 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 a la base de datos, empleando lo mejor de ambos sistemas de seguridad. Esto hace que sea mucho más fácil administrar esquemas de seguridad complejos. SQL Server es el almacenamiento ideal para información confidencial, como números de la Seguridad Social, datos de tarjetas de crédito y direcciones confidenciales.

  • Recuperabilidad inmediata     Si el sistema operativo se bloquea o la energía se bloquea, 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    Access y redes privadas virtuales (VPN) no se llevan bien. Sin embargo, SQL Server usuarios remotos pueden usar la base de datos front-end de Access en un escritorio y el back-end de SQL Server situado detrás del 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 SQL Server Azure

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

  • Base de datos única/grupos elásticos    Esta opción tiene su propio conjunto de recursos administrados a través de un SQL base de datos. Una única base de datos es como una base de datos contenida 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 mediante el SQL base de datos. Las características más usadas SQL Server están disponibles con copias de seguridad integradas, revisiones y recuperación. Pero no hay ningún tiempo de mantenimiento exacto garantizado y la migración desde SQL Server puede ser difícil.

  • Instancia administrada    Esta opción es una colección de bases de datos de usuario y sistema con un conjunto compartido de recursos. Una instancia administrada es como una instancia de la SQL Server base de datos que es altamente 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 SQL Server características que no están disponibles y no se garantiza el 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 SQL Server y una ruta de migración sencilla. Pero necesita administrar las copias de seguridad, revisiones y 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 SQL Server en Azure.

Primeros pasos

Hay algunos problemas que puede solucionar por adelantado 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 requiere que una tabla vinculada tenga una clave principal si se puede actualizar la tabla.

  • Comprobar relaciones de clave principal/externa    Asegúrese de que estas relaciones se basan en campos con tipos y tamaños de datos coherentes. SQL Server no admite columnas unidas 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 Datos adjuntos.

Antes de ejecutar SSMA, siga los primeros pasos siguientes.

  1. Cierre la base de datos de Access.

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

  3. Si la base de datos tiene el formato de archivo .mdb,quite la seguridad de nivel de usuario.

  4. Hacer 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 la posibilidad de instalar Microsoft SQL Server Express edition en el escritorio, que admite hasta 10 GB y es una forma gratuita y fácil de ejecutar y comprobar la migración. Al conectarse, use LocalDB como instancia de base de datos.

Sugerencia    Si es posible, use una versión independiente de Access. Si solo puede usar Microsoft 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 Microsoft Access Database Engine 2010 Redistributable.

Ejecutar SSMA

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

Nota    El proceso de migración puede tardar algún tiempo en función del 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 adecuada de 32 o 64 bits para el 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 para 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 Herramientas de revisión > Configuración del proyecto > General.

    El campo rowversion ayuda a evitar conflictos de registro. Access usa este campo rowversion en una SQL Server tabla vinculada 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 registrar escenarios de eliminación que pueden ocurrir cuando Access detecta resultados diferentes del envío original, como puede ocurrir con tipos de datos de número de punto flotante y desencadenadores que modifican columnas. Sin embargo, evite usar el campo rowversion en formularios, informes o código VBA. Para obtener más información, vea rowversion.

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

  5. Para establecer tipos de datos precisos, seleccione Herramientas de revisión > 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 los objetos de Access SQL Server objetos, pero no copia los objetos inmediatamente. SSMA proporciona una lista de los siguientes objetos para migrar para que pueda decidir si desea moverlos a SQL Server base de datos:

  • Tablas y columnas

  • Seleccione Consultas sin parámetros.

  • Claves principales y externas

  • Índices y valores predeterminados

  • Comprobar restricciones (propiedad de columna de longitud cero, regla de validación de columna, validación de tabla)

Como procedimiento recomendado, use el informe de evaluación de SSMA, que muestra los resultados de la conversión, incluidos errores, advertencias, mensajes informativos, estimaciones de tiempo para realizar la migración y pasos de corrección de errores individuales que debe realizar antes de mover realmente los objetos.

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

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

Sugerencia    Una vez que haya migrado correctamente la base de datos de Access, guarde el archivo de proyecto para su uso posterior, de modo que pueda migrar los datos de nuevo para realizar pruebas o la migración final.

Vincular tablas

Considere la posibilidad de instalar la última versión de SQL Server controladores OLE DB y ODBC en lugar de usar los controladores SQL Server nativos que se envían con Windows. Los controladores más recientes no solo son más rápidos, sino que admiten nuevas características en Azure SQL que los controladores anteriores no lo hacen. Puede instalar los controladores en cada equipo donde se usa la base de datos convertida. Para obtener más información, vea Controlador OLE DB de Microsoft 18 para SQL Server y Controlador ODBC de Microsoft 17 para SQL Server.

Después de migrar las tablas de Access, puede vincular a las tablas de SQL Server que hospedan ahora 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 SQL Server complejas.  Puede consultar y editar datos vinculadosen función de los permisos configurados por el administrador SQL Server base de datos.

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

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

Sugerencia   No olvide usar el Administrador de tablas vinculadas en Access para actualizar y volver a vincular tablas de forma cómoda. Para obtener más información, vea Administrar tablas vinculadas.

Probar y revisar

En las secciones siguientes se describen los problemas comunes que puede encontrar durante la migración y cómo tratarlos.

Consultas

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

Tipos de datos

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

Número grande    El tipo de datos Número grande almacena un valor numérico no monetario y es compatible con el tipo SQL datos bigint. Puede usar este tipo de datos para calcular de forma eficiente 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 64 bits de Access. Para obtener más información, vea Usar el tipo de datos Número grande y Elegir entre la versión de 64 bits o 32 bits de Office.

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

Fecha y hora    Hay varias consideraciones de fecha y 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 Tabla vinculada de Access a SQL-Server base de datos devuelve #deleted.

  • Use el tipo de datos Fecha y hora de Access para asignarlo al tipo de datos datetime. Use el tipo de datos Fecha y hora extendida de Access para asignarse al tipo de datos datetime2 que tiene un intervalo de fecha y hora más grande. Para obtener más información, vea Usar el tipo de datos Fecha y hora extendida.

  • Al consultar fechas en SQL Server, tiene en cuenta la hora, así como la fecha. Por ejemplo:

    • FechaOrdenada Entre el 1/1/19 y el 31/19 puede no incluir todos los pedidos.

    • DateOrdered Between 1/1/19 00:00:00 AM And 1/31/19 11:59:59 PM does include all orders.

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

Hipervínculo    Las tablas de Access tienen columnas de hipervínculo SQL Server no son compatibles. De forma predeterminada, estas columnas se convertirán en columnas nvarchar(max) en SQL Server, pero puede personalizar la asignación para elegir un tipo de datos más pequeño. En la solución de Access, puede seguir utilizando el comportamiento de hipervínculo en formularios e informes si establece la propiedad Hipervínculo para el control en true.

Campo multivalor    El campo multivalor de Access se convierte en SQL Server como un campo de texto n 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 cómo asignar access y SQL Server tipos de datos, vea Comparar tipos de datos.

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

Para obtener más información, vea Tipos de fecha y hora, Cadena y tipos binariosy 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. Sin embargo, 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 se deben convertir 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 formulario o informe, orígenes de datos de cuadros combinados y cuadros de lista en formularios, informes y campos de tabla, y expresiones de regla de validación o predeterminadas. SQL Server puede ejecutar estas funciones definidas por el usuario. Es posible que deba rediseñar manualmente estas funciones y convertirlas en procedimientos almacenados en SQL Server.

Optimizar el rendimiento

Con diferencia, la forma más importante de optimizar el rendimiento con las nuevas aplicaciones back-end SQL Server decidir cuándo usar consultas locales o remotas. Al migrar los datos a SQL Server, también se está moviendo de un servidor de archivos a un modelo de base de datos cliente-servidor de informática. Siga estas directrices generales:

  • Ejecute pequeñas consultas 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 necesita.

Optimizar el rendimiento en el modelo de base de datos del servidor cliente

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

Las siguientes son instrucciones recomendadas adicionales.

Poner lógica en el servidor     La aplicación también puede usar vistas, funciones definidas por el usuario, procedimientos almacenados, campos calculados y desencadenadores para centralizar y compartir lógica de aplicación, reglas y directivas empresariales, consultas complejas, validación de datos y código de integridad referencial en el servidor, en lugar de en el cliente. Pregúntese, ¿puede realizar esta consulta o tarea en el servidor cada vez 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 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 informes, use una vista SQL como origen de registros. Sin embargo, cree una vista independiente para cada informe, de modo que pueda actualizar más fácilmente un informe específico, sin afectar a otros informes.

Minimizar la carga de datos en un formulario o informe    No muestre datos hasta que el usuario lo solicite. Por ejemplo, mantenga la propiedad recordsource en blanco, haga que los usuarios seleccionen un filtro en el formulario y, después, rellenen la propiedad recordsource con el filtro. O bien, use la cláusula where de DoCmd.OpenForm y DoCmd.OpenReport para mostrar los registros exactos que necesita el usuario. Considere la posibilidad de desactivar la navegación de registros.

Tenga cuidado con las consultas heterogéneos   Evite ejecutar una consulta que combine una tabla local de Access y SQL Server tabla vinculada, a veces denominada consulta híbrida. Este tipo de consulta todavía requiere que Access descargue todos los datos SQL Server en el equipo local y, después, 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 rara vez cambian, como la lista de estados o provincias de un país o región. Las tablas estáticas se usan a menudo para filtrar y pueden tener un mejor rendimiento en el front-end de Access.

Para obtener más información, vea Asesor de optimización del motor de base de datos ,Usar el Analizador de rendimiento para optimizar una base de datos de Accessy Optimizar Microsoft Office aplicaciones de Access vinculadas a SQL Server.

Vea también

Guía de migración de base de datos de Azure

Blog de migración de

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

Formas de compartir una base de datos de escritorio de Access

¿Necesita más ayuda?

Ampliar sus conocimientos
Explorar los cursos
Obtener nuevas características primero
Unirse a Microsoft Office Usuarios de Insider

¿Le ha sido útil esta información?

¿Cuál es tu grado de satisfacción con la calidad de la traducción?
¿Qué ha afectado a tu experiencia?

¡Gracias por sus comentarios!

×