para - odbc data source mysql

¿Problemas al usar MS Access como front-end de una base de datos MySQL? (7)

Sé que esto no responde su pregunta directamente, pero podría valer la pena revisar la herramienta de migración de SQL Server 2005 para 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 tenía con MySQL

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

Moví las tablas de una base de datos simple de MS Access a MySQL usando su kit de herramientas de migración (que funciona bien, por cierto) y configuré el acceso para vincular esas tablas a través de ODBC.

Hasta ahora, me he encontrado con lo siguiente:

No puede insertar / actualizar / eliminar filas en una tabla sin una clave primaria (no es sorprendente).
Los campos Autonuméricos en MS Access deben ser la clave principal o simplemente terminarán como columnas enteras en MySQL (naturalmente, ¿por qué no sería PK?)
Las tablas se migraron al tipo de tabla InnoDB de MySQL, pero las relaciones de acceso no se convirtieron en restricciones de clave externa de 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?

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

Lo has probado 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 despego.

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

En general, depende :)

No he tenido muchos problemas cuando el lado de la aplicación acaba de actualizar 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 surgir 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.

Tenía una aplicación que funcionaba de la misma manera: una interfaz MS Access para un back-end MySQL. Fue un dolor tan grande que terminé escribiendo una interfaz Win32 en su lugar. Desde lo alto de mi cabeza, encontré 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 SQL más sofisticadas de la base de datos MySQL.
Tenga cuidado al usar muchos VBA, ya que eso tiende a dañar su archivo de frontend. 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 muchas 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!
Access 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 algunos consejos generales sobre la división en una interfaz y un back - end y un código que se reconecta automáticamente con el backend en el inicio ; También puedo enviarle más código de muestra o publicarlo aquí.

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

No te olvides de 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.

Gareth Simpson opinó:

Si solo son dos usuarios, Access debería funcionar bien si coloca el archivo .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 usuarios concurrentes máximos recomendados para Access son 5, pero en ocasiones lo he superado y nunca me despego.

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.

Sé que este tema no es muy reciente, solo algunas explicaciones adicionales:

Si desea utilizar MS Access de manera efectiva, especialmente con bases de datos multiusuario más grandes, 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 una 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 hay 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 vincular su interfaz MS Access con la 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.
compila tu frontend MDB a MDE - te 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: use el archivo MDE con la interfaz MS Access. Para un posterior desarrollo de frontend de MS Access, use el archivo MDB.
no use componentes ActiveX mal escritos para mejorar las capacidades frontend de MS Access. Es mejor que los escriba usted mismo o compre los adecuados.
no creas en los mitos de que hay muchos 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.

Puedo decirte que estoy usando MS Access bastante avanzado con MySQL back-end y estoy muy satisfecho (como desarrollador que mantiene esta aplicación). 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 las buenas prácticas y las 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