¿Cómo migrarías cientos de bases de datos de MS Access a un servicio central?

Question

Tenemos literalmente cientos de bases de datos de Access flotando en la red.Algunos con uso ligero y otros con uso bastante intenso, y otros sin uso alguno.Lo que nos gustaría hacer es centralizar estas bases de datos en una base de datos administrada y conservar la mayor cantidad posible de informes y formularios dentro de ellas.

Los beneficios de hacer esto serían tener algún tipo de seguimiento de uso y también la capacidad de prestar más atención a algunos de los datos descentralizados importantes que se almacenan en estas aplicaciones.

No existen restricciones reales en RDBMS (Oracle, servidor MS SQL) o en la pila en la que se ejecutaría (LAMP, ASP.net, Java) y obviamente no habrá una solución milagrosa para esto.Nos gustaría algo que pueda eliminar el trabajo duro inicial de forma automatizada.

Answer 1

Actualizar una aplicación de Access no es una solución mágica.Puede ser que algunas cosas sean más rápidas, pero algunos tipos de operaciones serán verdaderos perros.Eso significa que una aplicación ampliada debe probarse minuciosamente y abordarse los cuellos de botella de rendimiento, generalmente moviendo la lógica de recuperación de datos al lado del servidor (vistas, procedimientos almacenados, consultas de paso).

Sin embargo, en realidad no es una respuesta a la pregunta.

No creo que haya ninguna respuesta automática al problema.De hecho, yo diría que se trata de un problema de personas y no de programación en absoluto.Alguien tiene que inspeccionar la red y determinar la propiedad de todas las bases de datos de Access y luego entrevistar a los usuarios para descubrir qué se utiliza y qué no.Luego, se debe evaluar cada aplicación para determinar si debe integrarse o no en una aplicación/almacén de datos para toda la empresa, o si su implementación original como una aplicación pequeña para unos pocos usuarios fue el mejor enfoque.

Esa no es la respuesta que desea escuchar, pero es la respuesta correcta precisamente porque es un problema de personas/administración, no una tarea de programación.

Answer 2

Convertimos (ya sea usando el asistente de conversión o manualmente) a los usuarios al servidor SQL.Suele ser bastante sencillo.Reemplace todas las tablas de acceso con tablas vinculadas al servidor SQL y mantenga todos los formularios/informes/macros en acceso.La inversión en acceso no se pierde y los usuarios pueden seguir funcionando como de costumbre.Obtiene confiabilidad del servidor SQL y copias de seguridad centralizadas.Tenga en cuenta que hemos hecho esto para unas pocas bases de datos de acceso grandes, no para cientos.Haría un piloto de unas pocas docenas y vería cómo funciona.

ACTUALIZAR:Acabo de encontrar esto, el asistente de migración del servidor SQL, podría valer la pena echarle un vistazo:http://www.microsoft.com/sql/solutions/migration/default.mspx

Actualizar:Sí, será necesaria alguna refactorización para bases de datos mal diseñadas.¿En cuanto a cómo manejar la expansión del acceso?Me he encontrado con esto en empresas con muchos usuarios técnicos (especialmente los ingenieros, son los peores para esto...y sobresale la expansión).Hicimos una auditoría: (después de hacer una copia de seguridad) eliminamos todas las bases de datos que no habían sido tocadas en más de un año.Los "propietarios" se asignaron según la ubicación y/o los datos de la base de datos.Si la base de datos estaba en "S:\quality est_dept", entonces el gerente de calidad y el ingeniero jefe de pruebas tenían que tomar posesión de ella o la eliminamos (nuevamente después de hacer una copia de seguridad).

Answer 3

Oracle tiene un banco de trabajo de migración para portar sistemas MS Access a Oracle Application Express, que valdría la pena investigar.

http://apex.oracle.com

Answer 4

¿Entonces?Dedica un servidor a tus bases de datos de Access.

Ahora tiene el beneficio de algún tipo de seguimiento de uso y también la capacidad de prestar más atención a algunos de los datos descentralizados importantes que se almacenan en estas aplicaciones.

Esto es lo que ibas a hacer de todos modos, sólo que querías usar un motor de base de datos diferente en lugar de NTFS.

Y ahora tienes que forzar a los usuarios a ingresar a tu servidor.

Bueno, puedes animarlos diciéndoles que ya no vas a sobrescribir sus datos con copias de seguridad antiguas, porque ahora serás el propietario de los datos y ya no lo harás más.

Además, puede decirles que sus aplicaciones se ejecutarán más rápido ahora, porque excluirá la carpeta del análisis de virus en el acceso (no hace eso con sus otras bases de datos, razón por la cual están llenas de inyección SQL). malware, pero estas bases de datos no estarán expuestas a Internet) y planea desactivar la firma de paquetes (no lo necesitará en un servidor dedicado:es sólo para personas que ponen sus archivos compartidos en su servidor de dominio).

Ruta de actualización sencilla, servicio mejorado para los usuarios, mayor centralización y control para TI.Todos son ganadores.

Answer 5

Además de los comentarios de David Fenton

Su regla administrativa será algo como esto:

Si los datos que están en la base de datos solo los utiliza un usuario, para su propio trabajo (solo), entonces puede conservarlos en su propia red compartida.

Si los datos que están en la base de datos son para ser utilizados por más de una persona (incluso si son solo dos), entonces esa base de datos debe ir a un servidor central y estar bajo la administración de TI (copias de seguridad, cambios de esquema, interfaces, etc.). ).Esto se debe a que alguien con experiencia necesita coordinar todo el espectáculo o arriesgaremos el tiempo y los recursos del siguiente tipo.