Mensaje enviado por Ginez Javier <JGinez@sancorseg.com.ar>

Hola a todos!

Aquí les transcribo el artículo que comenté tiempo atrás, donde se hablaba acerca de la migracion de BD Access a SQL. Perdonen la demora.

Está extraído de la revista "Access-VB-SQL Advisor" de Enero de 2000. Autor: Stephen Forte.

El artículo es una guía a través de las pantallas del Asistente para exportacion de Access 2000, el cual dice estar mejorado y con menos errores que el de Access 97. Este asistente se instala si se elige una instalación completa de Access.

Pantalla inicial
Solicita si deseamos exportar a una DB SQL Server existente o a una nueva, para lo cual tendremos que proporcionar los datos necesarios según nuestra elección.

Pantalla 2
Solicita nombre del servidor, ID de usuario, y la clave para conectarse a la BD SQL a la que deseamos migrar

Pantalla 3
Solicita que seleccionemos las tablas que deseamos migrar

Pantalla 4
La más importante. Elegimos si deseamos migrar los índices, reglas de validacion y valores por defecto a SQL Server, como también las relaciones.
Pero aquí está la principal diferencia entre una BD Access (Jet) y SQL server. El motor Jet soporta actualizaciones y eliminaciones en cascada por medio de las relaciones desde la version 2.0. Pero en SQL server no se puede usar la Integridad Referencial Declarativa (DRI en inglés) para especificar actualizaciones y eliminaciones en cascada. Para preservarlas, en SQL debemos usar disparadores o triggers.
En esta pantalla también pregunta si deseamos agregar campos timestamp a nuestras tablas. La mejor opción es dejar que el asistente decida. Y por último nos pide si deseamos migrar solamente el esquema y no los datos.

Pantalla 5
Nos pide qué deseamos hacer con la actual aplicación de BD Access. Si elegimos "No cambiar la aplicación" el asistente migrará solo las tablas, dejando la BD Access intacta. Si elegimos "Vincular las tablas SQL Server a la aplicación existente", el asistente migra las tablas y las vincula al archivo MDB, creando consultas si fueran necesarias para que los formularios y reportes sigan trabajando. Y la opcion más poderosa, "Crear una aplicación cliente/servidor", migra las tablas y consultas para crear una nueva aplicación, preservando los formularios, reportes, páginas de acceso a
datos, macros y módulos.
Seleccionando Terminar, el asistente sigue su curso y al terminar crea un reporte de la migración. Este reporte muestra todas las acciones que al asistente le fue posible realizar, incluyendo detalles acerca de los nombres de las tablas, propiedades, etc. Algunos nombres de objetos en Access, especialmente los índices, son renombrados. Se recomienda imprimir este reporte pues no se puede grabar.

Temas importante a considerar cuando se migran tablas y consultas.
Comunmente no existen problemas a menos que se fuercen las actualizaciones o eliminaciones en cascada. Los nombres de tablas o campos de Access y que son ilegales en SQL, el asistente los encierra entre corchetes. Por lo tanto se recomienda dar un vistazo a las 199 palabras reservadas de SQL 7.0 para que no existan en la BD Access.

Los tipos de datos de los campos también son cambiados por el asistente. Se suministra una lista con las equivalencias. Existen tipos de datos en Access que no son soportados en SQL, como por ejemplo el hipervínculo. En resumen, los nuevos tipos de datos en SQL pueden comportarse levemente diferente de los que lo hacían en Access. Un ejemplo es el tipo de datos autonumérico en Access, el cual se traslada a un tipo de datos entero como identity.

En cuando a las consultas, todos los select no parametrizados son migrados como vistas. Las funciones definidas por usuarios no son migradas. Las funciones IIF y expresiones intrínsecas el asistente las resuelve creando vistas y procedimientos (stored procedures) con el prefijo "ut_". La tablas cruzadas o uniones no se migran. Todas las acciones o consultas parametrizadas son migradas a procedimientos almacenados (stored procedures)

La mayor cualidad del asistente es la de convertir las consultas en stored procedures.

Para finalizar, se recomienda analizar el por qué se desea migrar a SQL, pues después de migrar a SQL, las reglas cambian y nuestra aplicación no volverá a ser la misma. Mientras SQL nos brinda mayor poder y escalabilidad, esto tiene un precio: hay mayor administración, más programación, y una arquitectura totalmente diferente.
Como regla general se recomienda migrar a SQL cuando:
- Se necesita escalar a más de 50 usuarios concurrentes con una pesada carga de transacciones.
- Se necesita backups más robustos y seguimiento de las transacciones.
- Se desea usar una arquitectura basada en componentes
- Se necesita distribuir la aplicación a más de un lugar.

Espero les sirva.

Saludos!
--------------------------------
Javier E. Ginez
Analista de Sistemas
Sancor Coop. de Seguros Ltda.
JGinez@sancorseg.com.ar
Te:(03493)428500 - Interno: 1898