Pregunta Acceder a ADP - ¿Por / contra? [cerrado]


Se me ha encomendado tomar una aplicación Access 97 y mover los datos de fondo 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 de back-end se cambiarán significativamente para admitir nuevas funcionalidades.

Si tuviera mi deseo, no usaríamos Access como la 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.

Con lo que podría necesitar ayuda es con las ventajas y desventajas de continuar por este camino de desarrollo de Access. ¿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.

Acceso profesional:

  1. Ya posee licencias de Access 2003
  2. Fácil desarrollo de GUI
  3. Los informes se ven bien

Contra el acceso

  1. Tener que usar VBA (Visual Basic para Aplicaciones)
  2. ADO vs DAO. ¿Microsoft no cambió las cosas de Access 2002 a Access 2003?
  3. No vinculado al tiempo de ejecución de Access
  4. Elección en la parte frontal (WPF, WinForms, incluso ASP.NET)
  5. Mantenibilidad
  6. La verdadera separación de la lógica de la IU no es posible
  7. ¿Microsoft sigue siendo compatible con Access ADP?

Quizás haya otros problemas que no conozco tanto a favor como en contra de Access para el desarrollo de aplicaciones. Estoy tratando de mantener una mente abierta al mismo tiempo que trato de mantener mi 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 podría ofrecer mucho más si se me permite desarrollar con lenguajes y herramientas modernos?


5
2018-05-03 19:39


origen


Respuestas:


Los ADP están construidos alrededor de una interfaz, ADO Classic (una envoltura alrededor de OLEDB), que está huérfana y no va a ver un mayor desarrollo. En A2007 y A2010, los ADP se mantuvieron sin cambios, lo que indica que es probable que MS esté evaluando si les hizo 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 completamente (A2007).

Sin embargo, también es posible que MS haga algo con respecto a los ADP, ya que el equipo de Access recientemente consultó en su blog solicitando comentarios de los usuarios de SQL Server sobre qué se podría cambiar en Access para que sea más fácil de usar con SQL Server. 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. Espero lo último, ya que el equipo de Access está firmemente comprometido con la integración de Access con Sharepoint (para un gran efecto, debo agregar), y dado que Sharepoint está construido sobre SQL Server, esperaría un centrado 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. Portar un MDB existente a ADP realmente no es un proceso simple: no se puede hacer simplemente GUARDAR COMO, 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 utiliza 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.

Entonces, "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 otra plataforma completamente diferente (aunque nunca he usado 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 sean accesos falsos sugiere que sean de alguna manera compatibles entre sí o convertibles, ¡no lo son!

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

Para mí, es una obviedad: conviértase a A2003 y termine con poco o ningún tiempo dedicado al proceso.

Solo consideraría el puerto si la recompensa es grande, pero no ha dado ninguna lista de deficiencias en la aplicación de Access en sí; todo lo que ha descrito 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 Access, que le permiten desarrollar un front-end en Access y ejecutarlo 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, hay un verificador de compatibilidad que puede decirle qué funciona y qué no, por lo que es una opción que no está del todo sin algunas ruedas de entrenamiento para guiarlo en la conversión.

Tenga en cuenta el panorama general de la aplicación y su vida útil, 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 completamente alguna forma de integración .NET en alguna 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 qué dirección tomará MS con Access de 5 a 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 ligado con la integración de Sharepoint. Sabiendo eso, puede llegar a una conclusión diferente sobre el equilibrio relativo de los pros y los contras.


6
2018-05-03 22:16



Cuando intente cambiar las herramientas de desarrollo de una empresa, mírelo desde la perspectiva de la empresa. Quizás haya un par de gerentes que trabajaban 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, pero nadie más en la corporación tiene experiencia en las herramientas de desarrollo, a la corporación le va peor que a la mejor, porque no tienen más de un desarrollador que pueda saltar y algo salga mal. alguien se enferma, etc.

Estoy de acuerdo con HLGLM en que debería 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 la configuración nativa (control de versiones) de Access es un fuerte argumento en contra de Access.


1
2018-05-03 22:35



Los ADP aún son compatibles, 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, en sentido ascendente, el servidor de SQL Server 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.

Adicional No agregue funcionalidades mientras esté elevando el tamaño de la base de datos. Haz que funcione sin problemas primero.

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

Si tuviera que permanecer en Access, agregaría pieza a pieza la nueva funcionalidad. Poner estas actualizaciones a disposición de los usuarios cada semana aproximadamente. O más a menudo, que es lo que hago.


1
2018-05-04 20:39



En lo que a mí respecta, la única razón para permanecer con Access (y una versión más nueva) es si no va a realizar ningún cambio en la funcionalidad de la interfaz y está en un horario extremadamente ajustado. Pero si está reestructurando la base de datos y rehaciendo parte de la funcionalidad, no tiene sentido para mí permanecer con Access. El solo hecho de que el servidor SQL de back-end no solucione los problemas de rendimiento, debe convertirse a usar procs almacenados en lugar del motor Access Jet.

¿Puede vender la idea de utilizar lo que está familiarizado con la programación como un ahorro de costos en el vicio del proyecto que se remonta a aprender a acceder? Tal vez si puede tomarse un par de meses de la estimación de tiempo, será motivo suficiente para evitar Access.

Si está atascado con Access, al menos pídales que compren una nueva licencia y utilicen 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 muéstreles lo agradables que pueden ser. La implementación de los 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 ingresando en mi memoria aquí). Terminas en el infierno DDL si no recuerdo mal. Motivo suficiente para evitarlo. Con una aplicación basada en web (tienen una Intranet, ¿no?), La implementación es instantánea y todos los usuarios se implementan a la vez y todo funciona sin tener que pasar días intentando que una máquina falsa funcione cuando la versión de todos los demás. Tampoco tiene a nadie que trabaje con una versión obsoleta de la interfaz, otro problema clásico de Access.

Muéstrales un elegante prototipo de una aplicación web con un panel de control como Access no puede hacer. Haga que ellos quieran la funcionalidad que pueden obtener si abandonan Access.


0
2018-05-03 19:55



Estoy muy retrasado en esto, así que es solo para el registro: ADP no le permite estar conectado a más de 1 servidor. Eso puede ser un showstopper!


0
2018-05-02 13:45