tablas - ¿Cómo migrar de MS Access a SQL Server 2005?

microsoft sql server migration assistant v6 0 for access (5)

Tengo una aplicación de Windows VB.NET que extrae información de una base de datos de MS Access. La función principal de la aplicación es extraer información de los archivos de Excel en varios formatos, estandarizar el diseño del archivo y escribirlo en archivos csv. La aplicación usa MS Access como fuente para las claves y los archivos de referencia cruzada.

La aplicación de Windows usa conjuntos de datos tipeados para gran parte de la interacción del usuario entre la base de datos. La estandarización se realiza en la máquina de cada cliente. La aplicación no es ... ¿cómo puedo decir esto ... RÁPIDO :-).

Pregunta: ¿Cuál es la mejor manera de migrar el DB y la aplicación a SQL Server 2005. Estoy pensando que sería una buena idea escribir el código para la estandarización en y los paquetes de SSIS.

¿Cuál es la forma adecuada de llevar a cabo esta migración?

La aplicación extrae datos de 250 archivos de Excel cada semana y aproximadamente 800 archivos cada mes con un promedio de aproximadamente 5000 filas por archivo. Hay 13 formatos de archivo diferentes que están estandarizados y distribuidos en 3 formatos estándar diferentes. La aplicación tarda entre 25 min. y 40 minutos para ejecutar dependiendo de qué datos ejecutemos. El 95% de la aplicación es el proceso de estandarización. Todo lo que hace el usuario es elegir algunos parámetros y luego comenzar la ejecución.

Asegurándose de que el alcance sea claro:

Use un programa .NET para
conducir un front-end de base de datos Access que le permite
Extraiga datos de varias hojas de cálculo de Excel,
Masajear los datos de manera apropiada, y
Guarde el resultado en un archivo CSV.

¿De qué tipo de volúmenes estamos hablando? ¿Cuántos clientes, cuántas hojas de cálculo por cliente, cuántas filas por hoja de cálculo (creo que sería 32767 máximo para una sola hoja de cálculo, ¿verdad? ¿Y de cuánto tiempo estamos hablando?

Parece que hay muchas partes móviles. Y Access generalmente es una herramienta bastante buena (con VBA) para hacer este tipo de cosas por sí misma.

No parece que haya suficiente volumen para proporcionar un receptor de tiempo importante para una base de datos de acceso bien diseñada de acceso directo a Excel para llevar a cabo todo el proceso utilizando VBA. Si su alternativa implica la instalación y el funcionamiento de SQL Server (en lugar de Access) en cada cliente, me sorprendería que la administración y los gastos generales operativos no aumenten.

El asistente de ampliación de Access se puede utilizar como punto de partida.

Es posible que pueda cambiar el servidor para que sea SQL Server con tablas vinculadas en Access sin cambiar su interfaz. Luego, puede modificar la interfaz para ir directamente a SQL Server a voluntad.

A menos que esté accediendo mucho a Access, dudo que sea su cuello de botella.

En cuanto a la lectura de los archivos de Excel, SSIS puede hacerlo, pero podría no ser tan confiable como el mecanismo que está utilizando en VB.NET en este momento, si su código VB.NET tiene mucha lógica inteligente para manejar un grado. de variación en los archivos de entrada

En cuanto a escribir datos en CSV, SSIS está bien, y he encontrado que SSIS es un buen actor.

Si pudiera dar más detalles sobre el flujo de trabajo y cuánto interactúa el usuario con la base de datos en comparación con la configuración de extracción del programa, podría ser más fácil ayudar con su arquitectura.

SSIS es muy configurable sobre la marcha (el paquete se configura un poco mientras se ejecuta), y en muchos casos podría programarse para leer una variedad de archivos de Excel y convertirlos a CSV, pero no es tan configurable sobre la marcha como una mano sistema codificado También es posible usar el modelo de objetos SSIS para generar paquetes programáticamente y luego ejecutarlos; esto no tiene algunas de las limitaciones de un paquete que se configura a sí mismo, pero el modelo de objetos es bastante complejo.

Es posible que desee ejecutar su aplicación a través de un generador de perfiles para asegurarse de que Access DB es realmente lo que está desacelerando su aplicación, y no algo más. Sería una pena hacer todo el trabajo para convertirlo a servidor SQL y no tener nada que mostrar.

Microsoft proporciona una herramienta gratuita para migrar una base de datos de acceso a SQL Server. Una vez que haya actualizado debería poder cambiar su cadena de conexión para apuntar a SQL Server.

So Weekly, por cliente: 250 archivos a los 25 minutos = 10 archivos / minuto o 6 segundos por archivo.

Mensualmente, por cliente: 800 archivos a 40 minutos = 20 archivos / minuto o 3 segundos por archivo.

Mi expectativa sería menos de 1 segundo. por archivo (5000 filas) ida y vuelta incluyendo:
a. Importar o adjuntar xls a mdb,
segundo. Transformar a través de Access SQL
do. Exportar a csv

La única explicación que me viene a la mente es que quizás la aplicación .NET está leyendo, transformando y guardando una fila a la vez. Es ese posiblemente el caso?

Si convierte a SSIS, probablemente eso obsoleto la aplicación .NET, porque SSIS querrá manejar el ETL (y guardar). Entonces, básicamente, volverás a escribir el software. Pero puede tener mejores recursos para SSIS que para Access. Pero me parece excesivo. BUt entonces .NET en vez de VBA también es quizás excesivo; y la reescritura en VBA también es trabajo. El menor esfuerzo sería para ver si puede hacer todo el ETL (y guardar) usando Access SQL para la mayor parte, y usando VBA solo para scripting, para iterar a través de archivos de entrada en un directorio o algo así.

Creo que al menos podría prototipar los casos de uso básicos y averiguar si puede averiguar rápidamente dónde se está gastando el tiempo ahora (como lo sugirieron las respuestas anteriores). Pero eso valdría la pena averiguarlo antes de comprometer recursos de desarrollo dirigidos al la parte equivocada del problema Si puede expandirse un poco en esas áreas, probablemente podría dirigirlo más. Pero Access es muy adecuado para este tipo de cosas, en (IMHO) un TCO menor que SQL Server + SSIS + .NET.

Sin mencionar que me sorprendería si los archivos csv son el verdadero punto final, lo que puede jugar un papel en la decisión. ¿Acaso los datos de Excel realmente no terminan en el camino?

Finalmente, ¿qué tan objetable es un proceso de 25-40 minutos que, presumiblemente, es desatendido, puede pasar el receso del almuerzo y, básicamente, funciona bien?

Notas:

Per week Excel Files 250 Minutes 25 Minutes/File 0.1 Sec/File 6 Per month Excel files 800 Minutes 40 Minutes/File 0.05 Sec/File 3