Problemas al usar MS Access como front-end de un back-end de base de datos MySQL?

Question

Dos usuarios querían compartir la misma base de datos, originalmente escrita en MS Access, sin entrar en conflicto entre sí en un solo archivo MDB.

Moví las tablas de una base de datos simple de MS Access a MySQL usando su Migration Toolkit (que funciona bien, por cierto) y configuré el Acceso para vincular esas tablas a través de ODBC.

Hasta ahora, me he encontrado lo siguiente:

• No puede insertar/actualizar/eliminar filas en una tabla sin una clave principal (no hay sorpresa).
• campos Autonumérico en MS Access debe ser la clave principal o simplemente va a terminar como columnas de tipo entero en MySQL (natch, ¿por qué no sería el PK?)
• Las tablas se han migrado al tipo de tabla InnoDB de MySQL , pero las relaciones de acceso no se convirtieron en restricciones de clave externa MySQL.

Una vez que la base de datos está en uso, ¿puedo esperar algún otro problema? ¿Particularmente cuando ambos usuarios están trabajando en la misma mesa?

Answer 1

Tenía una aplicación que funcionaba de la misma manera: una interfaz MS Access a un back-end MySQL. Fue un gran dolor que terminara escribiendo un frontend Win32 en su lugar.Desde la parte superior de mi cabeza, me encontré con los siguientes problemas:

• El desarrollo del enlace ODBC parece haber cesado hace mucho tiempo. Hay varias versiones diferentes flotando alrededor, muy confusas. El enlace ODBC no es compatible con Unicode/UTF8, y recuerdo que también hubo otros problemas (aunque algunos podrían superarse con una configuración cuidadosa).
• Es probable que desee modificar manualmente su esquema db para que sea compatible con MS Access. Veo que ya descubrió las claves sustitutivas necesarias (es decir, claves principales int) :-)
• Debe tener en cuenta que es posible que necesite utilizar consultas de paso para realizar manipulaciones de SQL más sofisticadas de la base de datos MySQL.
• Tenga cuidado al usar muchos VBA, ya que eso puede dañar el archivo de su interfaz. Comprimir regularmente la base de datos (usando el menú principal, Herramientas | Utilidades de base de datos | Comprimir y restaurar, o algo así --- estoy usando la versión holandesa) y hacer lotes de copias de seguridad es necesario.
• El acceso tiende a causar mucho tráfico de red. Como, lotes realmente grandes. No he podido encontrar una solución para eso. ¡Se recomienda utilizar un monitor de red si desea vigilarlo!
• El acceso insiste en almacenar booleanos como 0/-1. En mi humilde opinión, 0/+ 1 tiene más sentido, y creo que es la forma predeterminada de hacer las cosas en MySQL también. No es un gran problema, pero si sus casillas de verificación no funcionan, definitivamente debe verificar esto.

Una posible alternativa sería poner el backend (con los datos) en una unidad compartida. Recuerdo que esto está bien documentado, también en la ayuda. Es posible que desee echar un vistazo a some general advice on splitting into a frontend and a backend y code that automatically reconnects to the backend on startup; También puedo enviarle más código de muestra o publicarlo aquí.

De lo contrario, también puede considerar MS SQL. No tengo experiencia con eso, pero supongo que funciona junto con MS Access mucho más agradablemente.

Answer 2

Sé que esto no responde su pregunta directamente, pero podría valer la pena mirar el SQL Server 2005 migration tool for Access. Nunca utilicé la herramienta, pero podría valer la pena utilizarla con SQL Server 2005 Express Edition para ver si existen los mismos problemas que tuvo con MySQL

Answer 3

Si solo son dos usuarios, entonces Access debería funcionar bien si pones el .mdb en una unidad compartida.

Lo ha intentado primero en lugar de solo asumir que será un problema.

Creo que los usuarios concurrentes máximos recomendados para Access son 5, pero en ocasiones lo he superado y nunca me despega.

Por otro lado, una vez utilicé Access como interfaz para MySQL en un único entorno de usuario (me). Fue una experiencia singularmente desagradable, no me puedo imaginar que sería más agradable con dos usuarios.

Answer 4

En general, depende :)

no he tenido un montón de problemas cuando el lado de la aplicación acaba de ser la actualización de los datos a través de los formularios. Puede recibir advertencias/errores cuando la misma fila ha sido actualizada por más de un usuario; pero Access parece actualizar constantemente sus conjuntos de registros en vivo todo el tiempo.

Pueden ocurrir problemas si Alice ya está trabajando con el registro 365, y Bob lo actualiza, y luego Alice intenta actualizarlo con sus cambios. Según recuerdo, Alice recibirá un mensaje de error críptico. Sería más fácil para los usuarios atrapar estos errores y al menos darles un mensaje de error más amigable.

Tuve más problemas cuando editaba registros en el código VB a través de RecordSets, especialmente cuando se combinaba con la edición de los mismos datos en formularios. Eso no es necesariamente un problema multiusuario; sin embargo, tiene casi la misma situación porque tiene un usuario con múltiples conexiones a los mismos datos.

Answer 5

Gareth Simpson opinó:

Si se trata de sólo dos usuarios, entonces el acceso debe hacer muy bien si se pone el .mdb en una unidad compartida.

Er, no. No hay una aplicación de acceso multiusuario para la cual cada usuario no debe tener una copia dedicada de la interfaz. Eso significa que cada usuario debe tener un MDB en su estación de trabajo. ¿Por qué? Debido a que los objetos en los frontales no se comparten bien (no tan bien como en las tablas de datos de Jet, aunque no hay ninguno en este escenario usando MySQL como back-end).

Gareth Simpson continuó:

Creo que los máximos usuarios concurrentes recomendados para el acceso es 5, pero en ocasiones He presionado que más allá de este y nunca se despegan.

No, esto es completamente incorrecto. El límite teórico para los usuarios de un MDB es 255. Eso no es realista, por supuesto, ya que una vez que llegue a unos 20 usuarios, debe programar su aplicación de Access para que funcione bien (aunque las cosas que necesita hacer en un Access-to- La aplicación Jet es el mismo tipo de cosas que harías para que cualquier aplicación de base de datos del servidor sea eficiente, por ejemplo, recuperando los conjuntos de datos utilizables más pequeños).

En este caso, dado que cada usuario debe tener una copia individual del MDB front-end, los límites multiusuario de Access/Jet simplemente no son relevantes en absoluto.

Answer 6

No olvide poner un tipo de sello de hora/fecha en cada registro. a veces el acceso ms pensará que "otro usuario ha cambiado o eliminado el registro" y no le permitirá realizar ningún cambio. Descubrí esto por el camino difícil.

Answer 7

Sé que este tema no es demasiado dulce, pero sólo algunas explicaciones adicionales:

Si desea utilizar Microsoft Access con eficacia, sobre todo con grande, las bases de datos multiusuario, haga lo siguiente:

• divida su MDB en archivos de aplicaciones frontend y backend (solo datos); entonces tendrá dos archivos MDB separados.

• migrar todas las tablas con datos y estructura en la base de datos externa. Puede ser: MySQL (funciona muy bien, sin limitaciones de tamaño de la base de datos, requiere más habilidades ya que no es tecnología MS, pero es una buena opción en muchos casos; además, puedes escalar tu backend con más RAM y CPU adicionales, así que todo depende de sus necesidades y capacidades de hardware); Oracle (si tiene suficiente dinero o algún tipo de licencia corporativa) o Oracle 10g XE (si esto no es un problema, el tamaño de la base de datos está limitado a 4 GB y siempre usará 1 GB de RAM y 1 CPU), MS SQL Server 2008 (es un gran par tener interfaz MS Access y back-end MS SQL Server en todos los casos, pero tienes que pagar por la licencia! - las ventajas son: estrecha integración, ambas tecnologías son del mismo proveedor; MS SQL Server es muy fácil de mantener efectivo al mismo tiempo) o Express Edition (la misma historia que con Oracle XE, casi las mismas limitaciones).

• Vuelva a conectar su MS Access frontend con base de datos back-end. Si seleccionó MS SQL Server para el back-end, será tan fácil como usar el asistente de MS Access. Para MySQL, debe usar controladores ODBC (es simple y funciona muy bien). Para Oracle, no use los controladores ODBC de Microsoft. Estos de Oracle harán su trabajo mucho mejor (puede comparar el tiempo necesario para ejecutar la consulta SQL desde MS Access a Oracle a través de Oracle ODBC y MS Oracle ODBC drivers). En este punto, tendrá un sólido backend de base de datos y una interfaz MS Access completamente funcional - archivo MDB.

• compile su frontend MDB a MDE - le dará mucha velocidad. Además, es la única forma razonable de distribuir la aplicación MS Access a sus usuarios finales.

• para el trabajo diario: utilice el archivo MDE con interfaz MS Access. Para un posterior desarrollo de frontend de MS Access, use el archivo MDB.

• no utilice componentes ActiveX mal escritos para mejorar las capacidades de la interfaz MS Access. Es mejor que los escriba usted mismo o compre los adecuados.

• no cree en los mitos de que hay un montón de problemas con MS Access: este es un gran producto que puede ayudar en ocasiones. El problema es que mucha gente asume que es un juguete o que MS Access es en general simple. Usualmente generan muchos errores y problemas por sí mismos y su falta de conocimiento y experiencia. Para tener éxito con MS Access, es importante entender esta herramienta: esta es la misma regla, como con cualquier otra tecnología.

te puedo decir que estoy usando bastante avanzado de MS Access afrontó a motor MySQL y estoy muy satisfecho (como desarrollador que está manteniendo esta solicitud).Mis amigos, los usuarios también están satisfechos, ya que se sienten muy cómodos con la GUI (frontend), la velocidad (MySQL), no tienen problemas con el bloqueo de registros o el rendimiento de la base de datos.

Además, es importante leer mucho sobre buenas prácticas y experiencias de otras personas. Diría que, en muchos casos, MS Access es una buena solución. Conozco muchos sistemas dedicados y personalizados que comenzaron como un experimento en forma de base de datos privada de MS Access (archivo MDB) y evolucionaron a: MS Access dividido (MDE - frontend, MDB - backend) y finalmente a: interfaz MS Access (MDE) y backend de bases de datos "serias" (principalmente MS SQL Server y MySQL). También es importante que siempre puedas usar tu solución de MS Access como prototipo funcional: estás listo para utilizar el backend en tu base de datos (MySQL, supongamos) y puedes reescribir el frontend con la tecnología que prefieras (¿solución web? Tal vez el escritorio C# aplicación - ¡lo que necesita!).

Espero haber ayudado a algunos de ustedes considerando el trabajo con MS Access.

Saludos, Wawrzyn http://dcserwis.pl