Como ya tiene asp.net con alguna lógica comercial, puede abrirla para acceder como servicio web (archivos asmx). Busque en Google el kit de herramientas de servicios web de Microsoft Office para su versión de acceso (xp/2003, etc.) y escriba las clases proxy de vba para que pueda llamar al servicio web. Puede vincular los datos del servicio web a los formularios a través del código (vba para leer y escribir en los controles) o crear tablas temporales locales con datos del servicio web y usar el enlace de acceso regular.
Dependiendo de con qué se sienta más cómodo (código/tsql) puede poner la lógica en procedimientos almacenados o en una capa de lógica de negocios o híbrido (ambos). Me resulta más fácil probar el código que los procedimientos almacenados y me gusta no estar vinculado al servidor sql para la lógica empresarial, es decir, si desea cambiar la base de datos o desea desarrollar/probar componentes fuera de línea sin una base de datos. Las nuevas características de .NET como LINQ tienen un rendimiento bastante bueno, por lo que no tiene que depender de procedimientos almacenados para las actividades de la base de datos.
Mantenga la interfaz de usuario de acceso frontal hasta que haya reajustado toda la lógica de su negocio/acceso a datos a servicios web. A continuación, puede crear una aplicación asp.net que consuma los servicios web o una aplicación winform si lo desea. (Manténgase alejado de WPF, como una interfaz de usuario, por el momento, ya que es una curva de aprendizaje empinada y todavía no tiene una cuadrícula de datos que se puede comparar a la vista de acceso Hoja de datos.)
Informes
Los informes de acceso se pueden ampliar a los servicios de informes del servidor sql (vba en los informes no se actualiza y es mejor escribir algunos tsql en los procedimientos almacenados). Si no tiene el producto servidor sql completo, puede usar el control reportviewer para escribir informes (consulte http://www.gotreportviewer.com/) en asp.net (o winform con la versión estándar o posterior de Visual Studio) vinculante para conjuntos de datos ado.net.
Otras opciones: Puede escribir .net dlls y usar com interop. Este enfoque le permite comenzar a escribir la funcionalidad gradualmente. No use .net ui, p. Ej. un winform, ya que no funcionará muy bien con el acceso ui. Puede escribir lógica comercial o lógica de acceso a datos y luego llamar a estas clases desde vba. A continuación, puede mover este código a asp.net o servicios web si es necesario.
Cosas que descartar:
no me gusta el enfoque de escribir una nueva aplicación con codo con versiones secundarios. Como desarrollador único, tienes suficiente de qué preocuparte. Probablemente terminará agregando características en ambas versiones y depurando dos versiones en lugar de una.
La interpo de formularios vb6 no funciona para el acceso.
ADP como se indica es bastante muerto. (Nunca me gustaron, ya que a menudo uso tablas locales para optimizar el rendimiento y solo se pueden llamar mediante código y no están vinculadas)
Puede convertir sus módulos vba y módulos de clase a vb.net utilizando The Visual Basic Asistente de actualización (en Visual Studio) pero no mejora todo (p. Ej., Código dao/ado a ado.net) y no crea código optimizado para .net y puede no ser fácil escribir pruebas unitarias dependiendo de el diseño del código vba. Recomiendo volver a escribir el código (prueba Test Driven Development si te tomas en serio las pruebas para ver si te gusta).
YES, utilizo Test-Driven Development exclusivamente (llevando lentamente nuestro sitio web de spaghetti bajo control). Me complace escuchar acerca de la conversión de informes y me gusta la idea de interoperabilidad de com para al menos tener el bit complejo bajo control. – Gilligan