sql-server - pasos - migrar access a sql server 2005

Aplicación MS Access-Convertir el almacenamiento de datos de Access a SQL Server (8)

Aquí hay una técnica en la que he escuchado hablar a un desarrollador. Esto es si realmente quieres algo así como una aplicación Cliente-Servidor.

Cree archivos frontend .mdb / .mde distribuidos a cada usuario (Verá por qué).
Para cada tabla que necesitan para realizar un CRUD, tenga una copia local en el archivo en el # 1.
Los formularios permanecen vinculados a las tablas locales.
Escriba el código VBA para manejar el CRUD desde las tablas locales a la base de datos de SQL Server.
Los informes pueden basarse en tablas temporales creadas desde SQL Server (no creo que pueda crear tablas temporales en archivos mde, no creo).

Una vez que decida cómo quiere hacer esto con un solo formulario, no es demasiado difícil aplicar la misma técnica al resto. Lo bueno de trabajar con el formulario en una tabla local es que puede mantener una gran cantidad de la funcionalidad existente como la aplicación existente (que es la razón por la que utilizaron y continúan usando Access, espero). Solo necesita enviar y recibir datos en SQL Server.

Puede seguir teniendo tablas vinculadas y luego eliminarlas gradualmente con esta técnica según lo dicten las necesidades de tiempo y rendimiento.

Como cada usuario tiene su propio archivo local, puede trabajar en su copia local de los datos. Solo el mínimo requerido para realizar su tarea debe ser copiado localmente. Ejemplo: si están actualizando un solo registro, la tabla solo tendrá ese registro. Cuando un usuario agrega un nuevo registro, observará que el campo de ID para el registro es Nulo, por lo que se necesita una declaración de inserción.

Supongo que la tabla local actúa como un conjunto de datos en .NET? Estoy seguro de que de alguna manera esta es una analogía imperfecta.

Tenga en cuenta que no soy un gurú de acceso. Soy competente con SQL Server y .Net framework. Aquí está mi situación:

Una gran aplicación de MS Access 2007 fue construida para mi empresa por un contratista.

La aplicación se ha dividido en dos niveles POR ACCESO; hay una parte de front-end que contiene todos los formularios de Ms Access, y luego en la parte de back-end, que son tablas de acceso, consultas, etc., que se almacenan en una computadora en la red.

Bueno, por supuesto, hay una necesidad de convertir la porción de almacenamiento de datos a SQL Server 2005 manteniendo todos estos formularios de GUI que se crearon en Ms Access. Aquí es donde entro.

He leído un poco y he descubierto que puede vincular los formularios o incluso las tablas de acceso a las tablas de SQL Server, pero todavía no estoy seguro de qué se puede hacer exactamente y cómo hacerlo.

¿Alguien ha hecho esto? Comente cualquier capacidad, limitaciones, consideraciones sobre tal empresa. ¡Gracias!

Esta es su opción de menor costo. Deberá configurar una conexión ODBC para sus clientes de Access que apuntan a su servidor SQL. A continuación, puede usar la opción (creo) "Importar" para "vincular" una tabla con el servidor SQL a través de la fuente ODBC. Migre sus datos de las tablas de acceso a SQL Server y tenga sus datos en SQL Server en un formulario que puede administrar y realizar una copia de seguridad. Importante, las consultas se pueden escribir en SQL Server como vistas y presentarlas en Access db como tablas vinculadas también.

Las tablas de acceso enlazado funcionan bien, pero solo las he usado con ODBC y otras bases de datos (Firebird, MySQL, Sqlite3). La información en claves primarias o extranjeras no estaba pasando. También hubo problemas con la interpretación del tipo de datos: una fecha en MySQL no es lo mismo que en Access VBA. Supongo que estos problemas no son tan malos cuando se usa SQL Server.

Punto importante: si vincula las tablas en Access to SQL Server, entonces CADA tabla debe tener una clave principal definida (¿Contratista? Acceso? La experiencia dice que probablemente algunas tablas no tengan PK). Si no se define una PK, los formularios de acceso no podrán actualizar e insertar filas, lo que hará que las tablas sean de solo lectura.

Tiene un par de opciones, el asistente de conversión hace un trabajo decente (ish) al mover la estructura y los datos del acceso a Sql. A continuación, puede configurar tablas vinculadas para que su aplicación ''debería'' funcionar más o menos como lo hace ahora. Desafortunadamente, el dialecto Sql utilizado por Access es diferente del servidor Sql, por lo que si hay alguna instrucción ''raw sql'' en el código, es posible que deba cambiarse.

Como ha vinculado a las tablas a través de todas las demás características de Access, QBE, formularios, etc. deben funcionar como se esperaba. Ese es el enfoque más simple y, probablemente, el mejor.

Otra forma de abordar el problema sería migrar los datos como se indicó anteriormente, y luego, en lugar de utilizar tablas vinculadas, utilizar ADO desde el acceso. Ese enfoque es más o menos familiar si estás acostumbrado a otros entornos de desarrollo / idiomas, pero es un enfoque equivocado. El acceso viene con muchas cosas integradas que hacen que trabajar con datos sea realmente sencillo, si vuelves a utilizar ADO / Sql, entonces perderás muchos de esos beneficios.

Sugiero comenzar con una pequeña parte de la aplicación, datos no esenciales, y migrar algunas tablas para ver cómo funciona. Por supuesto que copias todo todo primero.

Buena suerte

No use el asistente de conversión desde Access:

Primero, no funcionará con SQL Server 2008.
En segundo lugar, hay una herramienta mucho mejor para el trabajo:
SSMA, el Asistente de migración de SQL Server para acceso que Microsoft proporciona de forma gratuita.

Hará mucho por ti:

mover sus datos desde Access a SQL Server
Vincular automáticamente las tablas de vuelta a Access
darle mucha información sobre posibles problemas debido a las diferencias en las dos bases de datos
realiza un seguimiento de los cambios para que pueda mantenerlos sincronizados a lo largo del tiempo hasta que se complete su migración.

Escribí una entrada en el blog sobre esto recientemente.

Otros sugirieron que se actualice el back-end Jet a SQL Server y se vincule a través de ODBC. En un mundo ideal, la aplicación funcionará maravillosamente sin necesidad de cambiar nada.

En el mundo real, encontrará que algunos de sus objetos de front-end que fueron diseñados para ser eficientes y rápidos con un back-end de Jet en realidad no funcionan muy bien con una base de datos de servidor. A veces Jet adivina mal y envía algo realmente ineficiente al servidor. Este es el caso particular de las actualizaciones masivas de registros: para no acaparar los recursos del servidor (algo bueno), Jet enviará una sola instrucción UPDATE para cada registro (lo cual es malo para su aplicación, ya que es mucho, mucho más lento que una sola instrucción UPDATE).

Lo que tienes que hacer es evaluar todo lo que hay en tu aplicación después de que hayas mejorado y, cuando haya problemas de rendimiento, mover parte de la lógica al servidor. Esto significa que puede crear algunas vistas del lado del servidor, o puede usar consultas de paso (para entregar toda la declaración SQL a SQL Server y no dejar que Jet se preocupe por eso), o puede necesitar crear procedimientos almacenados en el servidor ( especialmente para las operaciones de actualización).

Pero, en general, es bastante seguro suponer que la mayor parte funcionará bien sin cambios. Es probable que no sea tan rápido como la antigua aplicación Access / Jet, pero ahí es donde puede usar SQL Profiler para descubrir qué es el holdup y volver a diseñar las cosas para que sean más eficientes con el servidor SQL Server.

Si la aplicación de Access ya se diseñó de manera eficiente (por ejemplo, los formularios nunca están vinculados a tablas completas, sino a fuentes de registros con cláusulas WHERE restrictivas que solo devuelven 1 o algunos registros), es probable que funcionen bastante bien. Por otro lado, si utiliza muchas de las malas prácticas observadas en las bases de datos y plantillas de muestra de Access, podría encontrarse con grandes problemas.

En mi opinión, todas las aplicaciones de Access / Jet deben diseñarse desde el principio con la idea de que algún día se actualizará para usar un servidor de back-end. Esto significa que la aplicación Access / Jet en realidad será bastante eficiente y rápida, pero también que cuando realice una mejora, causará un mínimo de dolor.

Eche un vistazo a esta herramienta de migración de Access to SQL Server. Puede ser una de las pocas, si no la ÚNICA, verdadera herramienta de migración de igual a igual o de servidor a servidor que se ejecuta como una aplicación web pura. Utiliza principalmente ASP 3.0, XML, el Objeto del Sistema de Archivos, el Objeto del Diccionario de Datos, ADO, ADO Extensions (ADOX), los Objetos de Scripting de Diccionario y algunas otras técnicas y tecnologías ordenadas de Microsoft. Si tiene la tabla de acceso a la fuente en un servidor y el servidor SQL de destino en otro servidor o incluso el mismo servidor y desea ejecutar esto como una solución de Internet por Internet, este es el producto para usted. Este ejemplo analiza el carrito de compras VPASP, pero funcionará para CUALQUIER versión de Access y para CUALQUIER versión de SQL Server de SQL 2000 a SQL 2008.

Estoy terminando el desarrollo de un proceso genérico de Conversión de actualización de base de datos que implica la conversión automática de Access Table, View e Index Estructures en un VPASP Shopping o cualquier otro sistema de acceso a sus SQL Server 2005/2008 equivalentes. Funciona directamente desde su servidor sin la necesidad de asistencia externa por parte de personal externo o consultores.

Después de crear un clon de sus tablas de acceso, índices y vistas en SQL Server, esta rutina de migración de datos migrará selectivamente todos los datos de sus tablas de Access a sus nuevas tablas de SQL Server 2005/2008 sin tener que dar a conocer su base de datos de acceso real o la Contenido de la tabla o sus contraseñas a cualquier persona.

Aquí está la parte de ingeniería inversa del proceso ejecutándose contra un sistema con casi 200 tablas y casi 300 índices y vistas que se está realizando como una prueba de aceptación del sistema. Todavía es un trabajo en progreso, pero las piezas principales están en su lugar.

http://www.21stcenturyecommerce.com/SQLDDL/ViewDBTables.asp

Hago ingeniería inversa automática de los DDL de la tabla de acceso (lenguaje de definición de datos) y los convierto en sentencias DDL equivalentes SQL, porque las estructuras de tablas e incluso las tablas adicionales pueden ser ligeramente diferentes para cada cliente VPASP y para cada versión de VP-ASP. .

Estoy terminando la rutina de conversión de datos real que migraría los datos de Access a SQL Server después de que se hayan creado estas nuevas tablas SQL, incluidas las vistas o los índices. Está escrito completamente en ASP, con VB Scripting, el objeto de sistema de archivos (FSO), el objeto de diccionario, XML, DHTML, JavaScript en este momento y se ejecuta bastante rápido como se verá en una base de datos de SQL Server 2008 solo por el bien de una ejemplo.

Se requieren unos 15-20 segundos para realizar ingeniería inversa en casi 500 objetos de base de datos diferentes. Puede haber un total de más de 2,000 columnas involucradas en este ejemplo para las 170 tablas y 270 índices involucrados.

Incluso he encontrado una forma de ejecutar ambos sistemas VPASP en paralelo usando 2 archivos diferentes de conexión de base de datos en el mismo servidor solo para asegurar que los pedidos ingresados en el Sistema de acceso y el sistema SQL Server produzcan los mismos resultados antes de la transición real a la producción.

John (a / k / a The SQL Dude) [email protected] (Este es un sitio de demostración VP-ASP)