database - microsoft - Front-End para la migración de MS Access?
microsoft access download mac (11)
Fondo
Trabajo para una gran organización que tiene miles de aplicaciones MS Access flotando. No escribí ninguno de estos, de hecho, la mayoría de los autores originales abandonaron la empresa hace mucho tiempo, pero de vez en cuando aparece otra aplicación de Access en mi escritorio para obtener ayuda. Me encantaría reemplazar el acceso con una solución diferente.
Requisito
Sé que hay varias buenas alternativas para la parte de la base de datos de MS Access (la base de datos Jet), como SQLite, MySQL, VistaDB, etc.
Lo que me gustaría saber es: ¿hay algo que reemplace la parte frontal de MS Access?
Es decir, algo que se puede usar para crear formularios, escribir scripts y consultas simples, etc.
¿Por qué?
@BracC preguntó "¿por qué reemplazar el acceso?" - Una buena pregunta de hecho.
Quiero deshacerme del acceso porque:
- oculta la lógica, lo que lleva a aplicaciones difíciles de admitir. La lógica puede estar en muchos lugares diferentes, ninguno de los cuales proporciona o fomenta ninguna estructura:
- macros
- módulos
- consultas
- formularios
- su propia naturaleza alienta a los usuarios a crear aplicaciones "pequeñas" que se convierten en "aplicaciones no tan pequeñas". Luego el usuario se va y tengo que apoyar un montón de espagueti. Sé que el acceso no es el único culpable, pero es el líder de mi organización, y me encantaría deshacerme de él por completo.
Para crédito extra
Lo que realmente me gustaría encontrar es algo que pueda leerse en un archivo MDB y generar algo como C #, que reproduce la funcionalidad. (O cualquier idioma, no exigente).
Espero que esto esté todo claro. De lo contrario, publique un comentario y volveré a escribir / agregar detalles.
Actualizar
@GuinnessFan hace algunos puntos que me parecen interesantes. He agregado mis comentarios para discutir esos puntos.
Lo que hemos hecho desde que hice la pregunta:
- Conseguimos que los usuarios nos den una lista definitiva de las aplicaciones de acceso que usan y necesitan. (El entendimiento es que cualquier archivo MDB que no esté en la lista se puede eliminar, ¡hurra!).
- Analizó los BMD en la lista y llegó a las siguientes conclusiones:
- La mayoría de las "aplicaciones" consisten en una única consulta codificada o una única tabla vinculada.
- Muchas son una pequeña cantidad de consultas con, quizás, un parámetro de fecha o similar.
- muy pocos (si los hay) tienen una lógica verdaderamente compleja.
- Ahora estamos trabajando en la lista, convirtiendo la mayoría de las aplicaciones a paquetes SSRS (SQL Server Reporting Services).
- Cualquier cosa que no pueda ser replicada usando SSRS se convertirá en una aplicación web hecha a mano. Sin embargo, no hay muchos de estos.
Permítanme agradecer a todos los que me han dado respuestas útiles.
¿Hay algo que reemplace la parte frontal de MS Access?
Tal vez Kexi ?
@BradC
No recomiendo MicroTools. Hace un tiempo trabajé para una empresa donde tuvimos el mismo problema. A menos que MicroTools haya realizado mejoras significativas en su producto, escupe la basura la última vez que verifiqué.
Lo que descubrimos fue que prácticamente cualquier ruta de actualización requerirá cantidades significativas de cambios de codificación. Todas estas herramientas son buenas para mantener una GUI similar a la aplicación original. Su código no tenía estructura de objeto, solo un conjunto de funciones de utilidad que se descargaban en cada página para simular la forma en que Access proporciona la navegación de registros. Si tiene una gran cantidad de formularios, extraer su solución e implementar la suya requiere algo de trabajo y una tonelada de operaciones de búsqueda y reemplazo.
Estábamos tan decepcionados con el rendimiento de MicroTools que comenzamos a escribir nuestro propio convertidor. Estábamos extrayendo mejores formularios ASP.NET que después de una semana de codificación.
Cambié el back-end en una aplicación de MSacces a MSSQL hace unos años. Mantuvo el front-end, porque funcionó bien, y no encontré nada tan fácil de usar / modificar.
Nunca he visto un traductor de MSAccess -> C #. Sin embargo, es posible que pueda encontrar un traductor de MSAccess to VB6 (sus sintaxis son más o menos similares), y desde allí hay traductores VB6-> VB.Net (e incluso traductores VB.Net -> C #).
De los miles de archivos Access, ¿a cuántos se le ha pedido que respalde? Supongo que menos de 100. ¿Por qué reconstruir una aplicación que A) nadie usa B funciona bien tal como es?
Debe comenzar una política que sea una práctica aceptable para una organización grande para desarrollar aplicaciones personalizadas en un entorno robusto, escalable y confiable, yadda yadda yadda. Identifique las aplicaciones de Access que considere críticas o que ya no funcionen y solo trabaje en ellas.
Esté preparado para manejar la expectativa de obtener sus aplicaciones pequeñas rápidas y sucias en un cambio rápido. Tendrás que mostrarles los beneficios de tus nuevas aplicaciones.
Creo que solo necesita ser un experto residente y enseñar a estos usuarios cómo mejorar su aplicación o recibir su opinión desde el principio para comenzar bien. Los requisitos para convertir todos estos archivos serían abrumadores.
Entonces, aparte del disgusto personal, ¿por qué reemplazar el front-end de Access? Puede ser fácil de hacer para algunas bases de datos (simples), pero la mayoría de las aplicaciones de acceso en el mundo real tienen mucha complejidad.
Muchas razones para actualizar el back-end, por supuesto (escalabilidad, rendimiento, corrupción de db, bloqueo de usuario). Access incluso tiene una herramienta incorporada de "asistente de actualización" que le permite dividir los formularios y la lógica de los datos, y actualizar los datos al servidor MS SQL. Si lo desea, utilice este asistente para actualizar el programa de fondo a SQL Express y luego migrarlo manualmente a otra plataforma db.
Espero que esto no sea demasiado fuera de tema, pero a veces todo lo que necesitas hacer con Access es:
Actualice el back-end (como ya hemos discutido)
Siempre asegúrese de que los frontales estén bloqueados (solo lectura)
Si es necesario, cree diferentes interfaces para diferentes roles de usuario (como una forma de seguridad).
Si es posible, haga que los frontales se copien localmente en cada estación de trabajo, por motivos de rendimiento. Es posible que deba tener una secuencia de comandos de red para comprobar si hay nuevas versiones del front-end.
No tengo ninguna experiencia directa con él, pero encontré una herramienta de conversión de Access to ASP.Net llamada "Access Whiz" en http://www.microtools.us/
Microtools ofrece Access Whiz, un conjunto de herramientas de conversión de acceso. Consiste en los convertidores ASP .NET (VB / C #), el convertidor Access to VB6, los convertidores Access For WinForms (VB .NET / C #) y el convertidor Access to Crystal Reports. Se puede encontrar más información y demostraciones de prueba en http://www.microtools.us/ .
No encontrará un motor de clase servidor que también tenga las herramientas de diseño de interfaz de escritorio adjuntas. Los grandes motores de servidor esperan que uses algo como C ++, C #, Java o PHP para construir tu interfaz.
A mí también me encantaría ver una herramienta de actualización para el acceso que escupiría algunos formularios básicos de C # y hablaría con una base de datos SQL Server equivalente. Parece que sería un gran generador de dinero para Microsoft porque podrían usarlo como una forma de vender a los clientes a un servidor SQL completo.
IIRC, podría haber una forma de decirle a un front end de Access que hable con un SQL Server, o cambiar las tablas utilizadas por un front end para que realmente se vinculen las tablas con un SQL Server, o algo así, pero nunca tuve que usar la función yo mismo.
Puede consultar Oracle Application Express . Es gratis y está dirigido a desarrolladores de Access.
También tiene un asistente de migración que ejecuta su base de datos de Access, procesa los datos y los formularios, migra todo a una base de datos Oracle (esto funciona con la base de datos gratuita, Oracle XE, y viene instalado por defecto) y crea formularios web para su base de datos de Access.
Así que, al final, tendrá sus bases de datos de Access en la web, sus datos en Oracle y una interfaz web algo agradable para ampliarlos.
En lo que respecta a Oracle, la herramienta no es tan mala. Puede registrarse para obtener una instancia gratuita para jugar here .
Aquí está el documento que explica cómo migrar bases de datos de acceso.
Tengo una perspectiva diferente para que consideres. Su problema principal es que oculta la lógica y hay datos y aplicaciones dispersos a través de la organización.
Lamentablemente, no conozco una herramienta RAD (desarrollo rápido de aplicaciones) que sea tan fácil como Access para crear formularios funcionales.
Sin embargo, recomendaría que se concentre más en la posibilidad de centrar la lógica de sus datos y lógica, y aún así permitir el acceso como una interfaz. Admito un producto de base de datos llamado Advantage Database Server que admite reglas de RI (integridad refferencial), procedimientos almacenados, desencadenadores, etc. que pueden administrarse en un servidor central, trayendo toda la lógica a usted. Estos frontales de acceso podrían vincularse al back-end de datos usando ODBC u OLEDB. Si cambia a una solución como esta, más adelante tendrá flexibilidad para escribir otras aplicaciones como .NET, PHP, JDBC, etc. que se relacionen con los mismos datos mientras se eliminan los front end de acceso.
Un buen comienzo sería detener el nuevo desarrollo de Access a menos que estén utilizando este tipo de back-end de datos.
Usamos una aplicación interna basada en MS Access como interfaz para una base de datos MySQL. Nos encontramos con muchos problemas y, finalmente, reescribimos toda la aplicación en CodeGear Delphi 2007 para Win32 . Esto ha sido un gran éxito, aunque la migración costó bastante esfuerzo (capacitar / contratar a un par de programadores de Delphi, comprar algunas herramientas de terceros). Sin embargo, puedo recomendar sinceramente a Delphi. Y AFAIK, la integración con un back-end de MS Access es ciertamente posible --- ¡Una vez escribí una aplicación Delphi que hace precisamente eso, y solo me costó un par de días obtener una versión completa!
Me doy cuenta de que esta es una solución de programación completa, por lo que definitivamente perdería algo de la facilidad de uso de MS Access para construir front-ends. Por otra parte, puede armar una aplicación de base de datos en Delphi en 10 minutos sin escribir demasiado código, ¡no es broma! Y desde el lanzamiento de 2009, el lenguaje se está volviendo cada vez más corriente de nuevo ...