Uso de Excel como interfaz de acceso a la base de datos (con VBA)

Question

Estoy creando una pequeña aplicación para un amigo y les gustaría poder usar Excel como interfaz. (la interfaz de usuario será básicamente formas de usuario en Excel). Tienen un montón de datos en Excel que les gustaría poder consultar, pero no quiero utilizar Excel como base de datos ya que no creo que sea adecuado para ese propósito y estoy considerando usar Access. [Por cierto, sé que Access tiene sus deficiencias, pero no hay presupuesto disponible y Access ya está en la PC de un amigo]

En resumen, estoy considerando descargar un montón de datos en Access y luego usar Excel como interfaz para consultar el base de datos y resultados de visualización en un entorno de estilo de forma de usuario.

Preguntas:

1. ¿Es fácil de enlace para acceder desde Excel con ADO/DAO? ¿Es bastante limitado en términos de funcionalidad o puedo ser creativo?
2. ¿Pago una penalización de rendimiento (en lugar de utilizar formularios en Access como interfaz de usuario)?
3. Suponiendo que la base de datos siempre se actualizará usando comandos ADO/DAO desde Excel VBA, ¿significa eso que puedo tener múltiples usuarios de Excel usando esa única base de datos de Access y no tener problemas de simultaneidad, etc.?
4. ¿Alguna otra cosa que deba tener en cuenta?

Tengo fuertes habilidades de Excel VBA y creo que puedo superar Access VBA bastante rápido, pero nunca he hecho el enlace de Excel/Access antes. Podría calzar los datos en Excel y usarlos como una base de datos pero eso parece más doloroso de lo que vale (y no una solución robusta a largo plazo)

Cualquier consejo apreciado.

Alex

Answer 1

Si el usuario final tiene acceso, puede ser que sea más fácil de desarrollar todo el asunto en el acceso. Access tiene incorporadas algunas herramientas de diseño de formularios WYSIWYG.

Answer 2

Solo omita la parte de Excel - los formularios de usuario de Excel son solo una versión pobre de los formularios de acceso más robustos. También Access VBA es idéntico a Excel VBA; solo tiene que aprender el modelo de objetos de Access. Con una aplicación simple, no necesitará escribir mucho VBA de todos modos porque en Access puede conectar cosas fácilmente.

Answer 3

Estoy seguro de que obtendrás un montón de respuestas de "no hagas esto", y debo decir que hay una buena razón. Esta no es una solución ideal ...

Habiendo dicho esto, he pasado por este camino (y otros similares) antes, principalmente porque el trabajo lo especificaba como un requisito difícil y no podía hablar eso.

Aquí están algunas cosas a tener en cuenta con este:

¿Es fácil de enlace para acceder desde Excel con ADO/DAO? ¿Es bastante limitado en términos de funcionalidad o puedo ser creativo?

Es bastante sencillo. Eres más limitado de lo que harías con otras herramientas, ya que los formularios VBA y Excel son un poco más limitantes que la mayoría de los lenguajes de programación completos, pero no hay nada que sea un impedimento para el espectáculo. Funciona, a veces es un poco feo, pero funciona.En mi última compañía, a menudo tenía que hacer esto, y de vez en cuando obtenía datos de Access y Oracle a través de VBA en Excel.

¿Pago una penalización de rendimiento (contra el uso de formularios en Access como interfaz de usuario)?

Mi experiencia es que definitivamente hay una perf. pena al hacer esto. Nunca me importó (en mi caso de uso, las cosas eran lo suficientemente pequeñas como para que fuera razonable), pero yendo a Excel < -> El acceso es mucho más lento que solo trabajar en Access directamente. Parte de esto depende de lo que quieras hacer ...

En mi caso, lo que parecía ser el más lento (y el más doloroso) era tratar de rellenar las hojas de cálculo de Excel según los datos de Access. Esto no fue divertido, y a menudo fue muy lento. Si tiene que ir por este camino, asegúrese de hacer todo con Excel oculto/invisible, o el redibujado definitivamente lo matará.

Suponiendo que la base de datos siempre será actualizado mediante ADO/DAO comandos desde Excel VBA, ¿significa que puedo tener múltiples usuarios de Excel usando una base de datos Access que sola no surge algún problemas de concurrencia etc.?

Está prácticamente usando Excel como cliente, del mismo modo que usaría una aplicación WinForms o cualquier otra herramienta. Los clientes ADO/DAO para Access son bastante buenos, por lo que probablemente no se encontrará con problemas de simultaneidad.

Dicho esto, Access NO escala bien. Esto funciona muy bien si tiene 2 o 3 (o incluso 10) usuarios. Si vas a tener 100, probablemente tengas problemas. Además, tendía a encontrar que Access necesitaba mantenimiento regular para no tener problemas de corrupción. Las copias de seguridad regulares de Access DB son obligatorias. Compactar periódicamente la base de datos de acceso ayudará a evitar la corrupción de la base de datos, en mi experiencia.

¿Alguna otra cosa que deba tener en cuenta?

Lo estás haciendo de la manera difícil. Usar Excel para acceder a Access va a ser mucho más trabajo que simplemente usar Access directamente.

Recomiendo examinar la API Access VBA, la mayoría es igual a Excel, por lo que tendrá una pequeña curva de aprendizaje. Las partes que son diferentes simplemente lo hacen más fácil. También tendrá todas las ventajas de los informes y formularios de Access, que están mucho más orientados a los datos que los de Excel. Los informes pueden ser excelentes para cosas como esta, y tener las Macros e Informes te facilitará la vida a largo plazo. Si el usuario va a usar formularios para administrar todo, hacer los formularios en Access será muy, muy similar a hacerlo en Excel, y se verá casi idéntico, pero hará que todo sea más rápido y sencillo.

Answer 4

A menos que exista una gran ventaja al ejecutar su formulario de usuario en Excel, entonces iría con una solución de 100% de acceso que exportaría los informes y datos a Excel de forma ad-hoc.

De lo que usted describe, Acceso parece ser el candidato más fuerte, ya que está construido para trabajar con datos:
que tendría mucho más herramientas a su disposición para resolver cualquier problema de datos que tiene que ir en torno a las limitaciones de Excel y calzador en convertirse en Access ...

En cuanto a sus preguntas:

1. muy fácil. Hubo algunas otras preguntas sobre SO sobre ese tema.
   Ver por ejemplo this one y that one.

2. No lo sé, pero supongo que podría haber una pequeña penalización.
   La mayor dificultad que veo es tratar de obtener todas las funcionalidades que Access le brinda y volver a crear algunas de ellas en Excel.

3. Sí, puede tener múltiples usuarios de Excel y una única base de datos de Access.
   Aquí de nuevo, usar Access como front-end y mantener los datos en una base de datos de Access vinculada en su red tendría más sentido y es fácil, incluso hay un asistente en Access para ayudarlo a hacerlo: it's just 1 click away.

Realmente, como la mayoría de otras personas han dicho, echar un poco de tiempo para familiarizarse con el acceso, que le ahorrará un montón de tiempo y problemas.
Puede que conozca Excel mejor, pero si ya ha avanzado un 80% si conoce VBA y está familiarizado con el modelo de objetos de Office.

Otras ventajas de hacerlo en el acceso: Access 2007 runtime is free, lo que significa que si se va a desplegar en aplicación a 1 o 30 PC que le costaría la misma: nada.
Solo necesita una versión completa de Access para su trabajo de desarrollo (el Runtime no tiene los diseñadores).

Answer 5

Hago esto todo el tiempo. Si está utilizando ADO, realmente no está usando Access, sino Jet, la base de datos subyacente. Eso significa que cualquiera con Excel puede usar la aplicación: no se requiere acceso. Oh, debería mencionar, el lugar donde trabajo compró un montón de licencias de Office Small Business, sin acceso. Antes de trabajar aquí, habría supuesto que cualquiera que tuviera Excel también tendría acceso. No tan.

Creo una clase para cada tabla en Access. Raramente ejecuto consultas a través de ADO, en cambio guardo esa lógica en los módulos de clase. Leo con una instrucción SELECT y escribo y ACTUALIZO o INSERT usando el método Execute del objeto ADODB.Connection.

Ver http://www.dailydoseofexcel.com/archives/2008/12/21/vba-framework-ii/

si quieres ver cómo puedo configurar mi código.

Para responder a sus preguntas: Será una pequeña curva de aprendizaje para usted si ya conoce Excel VBA, pero habrá algo que aprender a hacer; pagará una penalización de rendimiento por hacerlo todo en Access, pero no es tan malo y solo usted puede decidir si vale la pena; y puede tener varias personas accediendo a la base de datos.

Answer 6

Dada la facilidad de uso de Access, no veo un motivo convincente para usar Excel en absoluto que no sea exportar datos para el cálculo numérico. El acceso está diseñado para crear fácilmente formularios de datos y, en mi opinión, serán órdenes de magnitud más fáciles y consumirán menos tiempo que el uso de Excel. Unas horas para aprender el modelo de objetos de Access se amortizarán muchas veces en términos de tiempo y esfuerzo.

Answer 7

Realmente depende de la aplicación.Para un proyecto normal, recomendaría usar solo Access, pero a veces, las necesidades son específicas y una hoja de cálculo de Excel podría ser más apropiada.

Por ejemplo, en un proyecto que tuve que desarrollar para un antiguo empleador, la necesidad era dar acceso a diferentes personas en formularios (rellenar con algunos datos, diferentes para cada persona) y hacer que los completen, luego volver a importar los datos.

Dado que el formulario utilizaba un gran número de crujidos, tenía más sentido crearlo en Excel.

Los libros de Excel para las diferentes personas se crearon a partir de una plantilla usando VBA, luego se guardaron en una ubicación adecuada, con los derechos de acceso en la carpeta.

Todos los libros de trabajo se adjuntaron como tablas Externas a los libros de trabajo, utilizando rangos con nombre. Podría consultar los libros de trabajo desde la aplicación de acceso. Todo el material administrativo se realizó desde el db, pero los usuarios finales solo tenían acceso a su libro de trabajo respectivo.

Desarrollar una aplicación de Excel/Access de esta manera fue una experiencia agradable y la interfaz de usuario fue más fácil de usar de lo que hubiera sido con el uso de Access.

Debo decir que, en este caso, habría llevado mucho más tiempo hacerlo en Access de lo que me llevó usar Excel. Además, el Modelo de objetos de aplicación parece mejor en Excel que en Access.

Si planea usar Excel como front-end, no olvide bloquear todas las celdas, pero las editables y no tener miedo de usar filas y columnas enmascaradas (para construir tablas de salida para la base de datos de acceso) , para realizar cálculos intermedios, etc.).

También debe desactivar el autocalculado al importar datos.

Answer 8

Conectar Excel a Access usando VBA es muy útil. Lo uso en mi profesión todos los días. La cadena de conexión que uso está de acuerdo con el programa que se encuentra en el siguiente enlace. El programa se puede automatizar para realizar múltiples conexiones o tareas en el disparo, pero el código de conexión básico tiene el mismo aspecto. ¡Buena suerte!

http://vbaexcel.eu/vba-macro-code/database-connection-retrieve-data-from-database-querying-data-into-excel-using-vba-dao

Answer 9

Depende la cantidad de funcionalidad que usted está esperando por Excel < - la solución> Acess. En muchos casos en los que no tiene presupuesto para obtener una solución de aplicación completa, estas pequeñas utilidades funcionan. Si el alcance del proyecto es limitado, buscaría esta solución, ya que Excel le da flexibilidad para diseñar hojas de cálculo de acuerdo con sus necesidades y luego puede usar esas hojas prediseñadas para que las use el usuario. Diseñar una hoja de cálculo como formulario en Access consume más tiempo y es más difícil, y requiere algo de ActiveX. Puede que el objeto no solo maneje los datos sino que se presente en formatos de hoja de cálculo, entonces esta solución debería funcionar con un alcance limitado.

Answer 10

Puede intentar algo como XLLoop. Esto le permite implementar funciones de Excel (UDF) en un servidor externo (se proporcionan implementaciones de servidor en muchos idiomas diferentes).

Por ejemplo, podría utilizar una base de datos MySQL y un servidor web Apache y luego escribir las funciones en PHP para entregar los datos a sus usuarios.

Por cierto, trabajo en el proyecto así que avíseme si usted tiene alguna pregunta.

Answer 11

Es bastante fácil y eficiente utilizar Excel como herramienta de informes para acceder a los datos. Un enfoque rápido de "no programación" es establecer una lista o una tabla dinámica, vinculada a su fuente de datos externos.Pero eso está fuera del alcance de Stackoverflow.
Un enfoque programático puede ser muy simple:

strProv = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & SourceFile & ";" 
Set cnn = New ADODB.Connection 
cnn.Open strProv 
Set rst = New ADODB.Recordset 
rst.Open strSql, cnn 
myDestRange.CopyFromRecordset rst 

eso es todo!

Answer 12

Lo hice en un proyecto mío. Usé MDB para almacenar los datos sobre facturas y usé Excel para representarlos, lo que le da al usuario la posibilidad de adaptarlo.

En este caso, la mejor solución es:

1. No utilizar ninguno de ADO/DAO en Excel. Implementé todo como funciones públicas en módulos MDB y los llamé directamente desde Excel. Puede devolver incluso objetos de datos complejos, como matrices de cadenas, etc. llamando a las funciones de MDB con los argumentos necesarios. Esto es similar a la arquitectura de cliente/servidor de las aplicaciones web modernas: su aplicación web simplemente hace que la representación y la interacción del usuario, la base de datos y el nivel intermedio estén en el lado del servidor.

2. Utilice formularios de Excel para la interacción del usuario y la visualización de datos.

3. Normalmente tengo una última hoja con algunos nombres regiones para la configuración: la ruta a los archivos MDB, algunos ajustes (usuario actual, contraseña si es necesario, etc.) para que pueda adaptar fácilmente su implementación de Excel a diferentes ubicaciones de su "back-end" de datos.