Acceso ADP - Por/¿Contra?

Question

Se me ha encomendado tomar una aplicación Access 97 y mover los datos back-end a SQL Server mientras muevo la interfaz a Access 2003 (usando Access Data Projects). En el proceso de esta migración, las estructuras de datos back-end se cambiarán significativamente para admitir nuevas funcionalidades.

Si tuviera mi deseo, no estaríamos usando Access como interfaz. Creo que nuestra aplicación sería mucho mejor servida por WinForms, WPF o una aplicación web. Tenemos el tiempo necesario para planificar correctamente una capa de lógica de negocios e implementar una solución excelente, pero los poderes superiores a mí quieren permanecer con Access porque eso es lo que les resulta familiar.

Lo que podría usar para ayudarme son los pros/contras de continuar por este camino de desarrollo de acceso. ¿Cuáles son algunos argumentos legítimos a favor y en contra de usar Access 2003? Esto es lo que se me ocurrió hasta ahora.

Pro Acceso:

1. ya posee acceso licencias 2003 el desarrollo
2. Fácil GUI
3. informes se ven bien

contra el acceso

1. tener que utilizar VBA (Visual Básico para Aplicaciones)
2. ADO vs DAO. ¿Microsoft no cambió las cosas de Access 2002 a Access 2003?
3. no vinculadas a Access tiempo de ejecución
4. elección en extremo frontal (WPF, WinForms, ASP.NET)
incluso
5. mantenibilidad
6. verdadera separación de la lógica de la interfaz de usuario no es posible
7. ¿Microsoft sigue apoyando ADP del acceso?

Quizás haya otros problemas que desconozco tanto a favor como en contra del acceso para el desarrollo de aplicaciones. Intento mantener la mente abierta y al mismo tiempo tratar de mantener la cordura.

He estado usando C# desde que se lanzó .NET y la idea de volver a VBA durante seis meses me daña la cabeza. ¿Especialmente cuando siento que puedo ofrecer mucho más si me permiten desarrollarme con idiomas y herramientas modernas?

Answer 1

Los ADP están construidos alrededor de una interfaz, ADO Classic (una envoltura alrededor de OLEDB), que se ha quedado huérfana y que no va a seguir desarrollándose. En A2007 y A2010, los ADP no se modificaron, lo que indica que es probable que MS esté evaluando si hacer o no lo que se hizo con las Páginas de acceso a datos (DAP), es decir, después de dos versiones sin cambios (A2002/A2003), eliminar ellos completamente (A2007).

Sin embargo, también es posible que MS haga algo con los ADP, ya que el equipo de Access solicitó comentarios a los usuarios de SQL Server sobre lo que se podría cambiar en Access para facilitar su uso con SQL. Servidor. Esa retroalimentación entrará en una de las próximas versiones de Access (ya sea la que sigue a A2010 o la siguiente). Esto puede tomar la forma de un desarrollo revivido de ADP, o puede tomar una forma completamente diferente. Esperaría lo último, ya que el equipo de Access está firmemente comprometido con la integración de Access con Sharepoint (para un gran efecto, podría agregar), y dado que Sharepoint está construido sobre SQL Server, esperaría un sistema basado en Sharepoint. solución al "problema" de SQL Server.

Pero no tengo ninguna información interna aquí en absoluto.

En su caso actual, ya tiene un MDB ya desarrollado. Transportar un MDB existente a ADP realmente no es un proceso simple; no se puede simplemente hacer un SAVE AS, ni hay una rutina de conversión. Esto se debe a que los ADP y los MDB son animales completamente diferentes. Un MDB es una base de datos Jet, mientras que un ADP es un archivo contenedor que no usa Jet. Los objetos en un ADP no tienen necesariamente las mismas propiedades y comportamientos que en un MDB, por ejemplo, por lo que no puede importarlos.

Por lo tanto, "convertir" a ADP requiere una reescritura casi completa, y el nivel de dificultad es, en mi opinión, dentro del mismo orden de magnitud que la migración a WinForms o alguna plataforma completamente diferente (aunque he nunca usé ADP o WinForms, así que podría estar equivocando aquí). Lo que sí sé es que los ADP y los MDB son lo suficientemente diferentes como para que el hecho de que ambos sean accesos falsos sugiera que son de alguna manera compatibles entre sí o convertibles, ¡no lo son!

Dado el futuro incierto del Access ADP, no recomendaría embarcarse en un nuevo desarrollo en ese formato, y mucho menos convertir una aplicación MDB existente a ADP.

Para mí, es obvio: conviértalo en A2003 y termine con poco o nada de tiempo dedicado al proceso.

Solo consideraría el puerto si el resultado es grande, pero no ha dado ninguna lista de deficiencias en la aplicación de Access en sí; todo lo que ha indicado es lo que no le gusta del modelo de desarrollo de Access. Puede extender la línea de tiempo un poco más y considerar cuál es la duración de esta aplicación.También debe familiarizarse con las nuevas capacidades de Access 2010 integradas con Sharepoint 2010 y sus Servicios de acceso, que le permiten desarrollar una interfaz en Access y ejecutarla en el navegador web. Eso elimina la necesidad del tiempo de ejecución, lo cual es de gran ayuda.

Pero no hay una conversión fácil de una aplicación de acceso de cliente existente a una aplicación de acceso web. Sin embargo, existe un comprobador de compatibilidad que puede indicarle qué funciona y qué no, por lo que es una elección no del todo sin algunas ruedas de entrenamiento que lo guiarán en la conversión.

Tenga en cuenta la visión general de la aplicación y su duración, así como el futuro de Access y Sharepoint, y puede llegar a un conjunto de respuestas completamente diferente.

También tenga en cuenta que es probable que Access no esté ligado a VBA para siempre. Espero alguna forma de integración de .NET alguna vez en una de las siguientes dos versiones de Access después de A2010. Por otro lado, con las nuevas macros (que ahora tienen manejo de errores y estructuras completas de ramificación), es posible que MS elimine cualquier lenguaje de scripts ad hoc de Access y proporcione solo las macros reforzadas para la programación.

Es imposible saber con certeza a qué dirección irá MS con Access 5-10 años, pero sí sabemos que ha habido una gran inversión en Access en las últimas dos versiones, y el futuro de Access ahora está íntimamente relacionado con Integración de Sharepoint. Sabiendo eso, puede llegar a una conclusión diferente sobre el equilibrio relativo de los pros y los contras.

Answer 2

Por lo que a mí respecta, la única razón para quedarse con Access (y una versión más nueva) es si no va a realizar ningún cambio en la funcionalidad de front-end y tiene un calendario muy apretado. Pero si está reestructurando la base de datos y rehaciendo parte de la funcionalidad, no tiene sentido para mí permanecer con Access. Simplemente haciendo que el servidor SQL de servidor tampoco resuelva los problemas de rendimiento, debe convertir a usar procs almacenados en lugar del motor Access Jet.

¿Se puede vender la idea de utilizar lo que está familiarizado con la programación como un ahorro de costes en el proyecto viceversa para volver a acceder a Access? Tal vez si puede tomarse un par de meses de la estimación de tiempo, será motivo suficiente para evitar Access.

Si tiene problemas con Access, obtenga al menos que compre una nueva licencia y use la última versión. Es tonto "actualizar" a una versión desactualizada.

En cuanto a los informes que se ven bien, SQl Server tiene una herramienta de informes que también hace muy buenos informes. Genere algunos informes en SSRS y demuéstreles lo buenos que pueden ser. La implementación de cambios es más fácil en una aplicación basada en la web: estoy bastante seguro de que la versión anterior de Access es miserable de implementar (estoy volviendo a dragar en mi memoria aquí). Terminas en el infierno DDL si no recuerdo mal. Motivo suficiente para evitarlo. Con una aplicación basada en la web (tienen una Intranet, ¿no?) La implementación es muy fácil y todos los usuarios se implementan a la vez y todo funciona sin pasar días intentando que funcione una máquina deshonesta cuando funciona la versión de todos los demás. Tampoco tiene a nadie trabajando con una versión obsoleta de la interfaz, otro problema clásico de acceso.

Muéstreles un prototipo elegante de una aplicación web con un tablero como Access no puede hacer. Haga que deseen la funcionalidad que pueden obtener si abandonan Access.

Answer 3

Cuando intente cambiar las herramientas de desarrollo de una empresa, mire desde la perspectiva de la compañía. Tal vez hay un par de gerentes que solían trabajar en Access. En un apuro, podrían saltar y solucionar problemas, etc. La capacidad de mantenimiento solo tiene sentido para la corporación, no para usted personalmente. Si escribes una aplicación web de éxito, pero nadie más en la corporación tiene experiencia en las herramientas de desarrollo, la corporación no está en una situación mejor, porque no tienen más de un desarrollador que puede saltar en algo que sale mal, alguien se enferma, etc.

Estoy de acuerdo con HLGLM en que debe actualizar a la última versión de Access en lugar de 2003. Dado que el tiempo de ejecución no cuesta nada, el último (2010) no costaría mucho.

Si alguna vez va a haber más de un desarrollador, entonces la falta de administración de configuración nativa de Access (control de versiones) es un fuerte argumento en contra de Access.

Answer 4

Los ADP todavía se admiten pero no han tenido mejoras significativas para varias versiones. Por lo tanto, le sugiero que actualice la aplicación a Access 2003 o posterior y que funcione en las estaciones de trabajo cliente utilizando el tiempo de ejecución. Tenga en cuenta que el tiempo de ejecución de Access 2007 es gratuito.

Luego, por detrás, el servidor SQL mantiene la base de datos de Access en formato MDB. Cree las vistas y los procedimientos almacenados necesarios para eliminar los cuellos de botella en Access y mejorar el rendimiento. Querrá esas vistas y procedimientos almacenados sin importar en qué dirección vaya.

Agregado No agregue funcionalidad mientras está creando la base de datos. Haz que funcione sin problemas primero.

En este momento usted y los poderes pueden decidir en qué dirección desea ir.

Si se quedara en Access, agregaría la nueva funcionalidad, pieza por pieza. Poniendo estas actualizaciones a disposición de los usuarios cada semana más o menos. O más a menudo, que es lo que hago.

Answer 5

Estoy muy atrasado en esto, por lo que es solo para el registro: ADP no le permite estar conectado a más de 1 servidor. ¡Eso puede ser sorprendente!