Pregunta

Tengo un producto diseñado para ser un producto de escritorio utilizando el archivo de MS Access como base de datos.

Ahora, algunos usuarios necesitan para instalar en algunas PC (digamos 2 o 3) y compartir la base de datos.

pensé para colocar el archivo de MS Access en una carpeta compartida y acceder a él desde el PC, pero ... el motor Jet está diseñado para el acceso de múltiples usuarios?

Cualquier consejo o cosas a tener en cuenta de hacer esto?

EDIT: La aplicación es una .NET uno, utilizando la base de datos como de almacenamiento (no utilizando la base de datos como frontend)

¿Fue útil?

Solución

Hay tanta información errónea en las respuestas en este hilo que no sé por dónde empezar. Acabo de pasar 4 puntos en la reputación de votación las respuestas con información engañosa y el mal en ellos.

  1. el motor de base de datos Jet (que es todo lo que se trata aquí, como el OP aclarado con una edición) es por defecto multiusuario -. Que fue construido desde el principio para ser de esa manera

  2. compartir un almacén de datos Jet es muy fiable cuando la red no es deficiente. Esto no significa una WAN y no sin cables, debido a que el ancho de banda tiene que ser suficiente para Jet para mantener el archivo de LDB (para el bloqueo multi-usuario), lo que significa un ping por ejemplo de su PC local del motor de base de datos Jet vez por segundo (con ajustes por defecto), y porque Jet no puede recuperarse de una caída de la conexión (que es bastante común en un entorno inalámbrico).

  3. la situación en la que se cae de acceso es cuando se comparte una aplicación de acceso front-end MDB (que no es el caso para este cartel). La razón de que no se debe a que está compartiendo las cosas que no pueden ser compartidos de forma fiable y no tienen ninguna razón para ser compartida. Debido a la forma en objetos de Access se almacenan en un archivo MDB (todo el proyecto de Access se almacena en un solo campo BLOB en un registro en una de las tablas del sistema), es muy propenso a la corrupción si varios usuarios abren. En mi opinión, compartiendo un extremo frontal de acceso (o un MDB sin dividir con las tablas y formularios / informes / etc., Todo en un MDB) es la fuente para el 99,99% de corrupciones de archivos / Jet de acceso.

Mi respuesta básica a la pregunta de la OP es que, sí, Jet sería un gran almacén de datos para una aplicación de ese tamaño. Sin embargo, si hay alguna posibilidad en absoluto para la población de usuarios crezca por encima de 25, entonces podría ser mejor empezar desde cero con un motor de base de datos que es más robusto en las poblaciones de usuarios más altos.

Otros consejos

Es perfectamente factible hacer esto; pero debe dividir la base de datos en un extremo delantero (con formularios, consultas de código) y un extremo posterior (sólo datos). Cada usuario tiene que tener la parte delantera en su propio ordenador, que une al extremo posterior compartida.

Será lento como Jet genera una tonelada de tráfico de la red. Microsoft también está deprecating gradualmente Access como una herramienta de desarrollo. Access 2007, por ejemplo, tiene un modelo de seguridad mucho menos sofisticado que el acceso 2003.

Como desarrollador de largo tiempo de acceso estoy alejando gradualmente de acceso.

No hacerlo ... la base de datos Jet afirma ser capaz de soportar múltiples usuarios, pero es muy fácil de usar el Asistente para convertir para convertir el archivo de acceso a una base de datos SQL Express. Ese archivo de base de datos podría convertirse fácilmente bloqueado por un usuario o administrador, y todos sus usuarios sería incapaz de utilizar la base de datos.

SQL Express está libre . Su ruta de actualización desde allí a una instancia completa de SQL Server o alguna otra base de datos comercial es simple.

Con 2 o 3 usuarios en una red local fiable que debe estar bien, siempre y cuando se de vuelta la unidad de red a menudo.

Evitar cualquier campo de bit / bool en las tablas -. Jet tiene algunos problemas de corrupción desagradables con acceso múltiple a ellos

También hay que tener en cuenta que todo el bloqueo en el acceso es optimista:. Obtendrá lecturas sucias en ocasiones

MS Access está diseñado para pequeñas oficinas escenarios como este:. Uso no crítico oficina de la luz que se pueden establecer con el mínimo de programación

Esperamos que el archivo de datos para obtener corrompido de vez en cuando -. Copias de seguridad con regularidad

El motor ACE / Jet es una gran pieza de software, pero, si bien era diseñada para soportar múltiples usuarios, en realidad el apoyo a múltiples usuarios en la práctica no es uno de sus puntos fuertes. La última gota para mí es donde entonces la seguridad a nivel de usuario eliminado (ULS) del motor: supongo que puedo imaginar una situación simple base de datos donde todos los usuarios tendrán los mismos privilegios (es decir, acceso de administrador a todos base de datos objetos), pero la OMI que no está apoyando a varios usuarios, así, en comparación con, por ejemplo, MS SQL Server.

Sí, es compatible con el acceso de múltiples (es decir, un pequeño grupo de trabajo, tamaño, número) de los usuarios en un recurso compartido de archivos de red. Sin embargo, la arquitectura compartido de archivos no es simplemente ideal para apoyar la escritura simultánea en un archivo de múltiples usuarios. Un sistema de base de datos cliente / servidor (SQL Server, etc.) por lo general proporciona un mejor rendimiento, seguridad y fiabilidad.

Como un administrador de sistemas, por favor no utilice el acceso para cualquier cosa multiusuario. Haz lo que sugiere Jeff Fritz y utilizar una base de datos que está diseñado para el acceso de múltiples usuarios. Usted puede pensar que su pequeña aplicación sólo va a ser compartida entre unas pocas personas, pero te garantizo que va a tener un centenar de usuarios y cincuenta nuevas características para el final del año. Y si esos son todos los accesos, en lugar de VB / SQL Express, tu jefe de operaciones gente va a entrar en su casa una noche y se cortó la garganta.

El acceso no es una aplicación cliente-servidor, y ofrece muy poco en el camino de copia de seguridad / restauración, o cualquier automatización en absoluto. Por no hablar de la interfaz y el PP se acoplan muy bien ... así que si alguna vez desea convertir esto en una aplicación web, o hacer cualquier cambio grave, su mundo se llena de dolor.

Se ha hecho tantas veces por tantos ingenieros de software genérico, donde hemos visto un .mdb ir corrupta en una situación de múltiples usuarios. Si tantos experimentados desarrolladores de acceso especializadas que pueden hacer las cosas bien, como estoy inclinado a creer, entonces generalistas deben estar haciendo algo mal y que algo debe ser bastante fundamental sin embargo, no es evidente para muchos de nosotros para huir de la cosa gritando '¡Nunca más!' Así que si usted se considera ser un desarrollador de acceso especialista con experiencia (o usted sabe cómo encontrar uno) y luego ir por ella. Pero si usted es un usuario generalista o casual en busca de una parte final de peso ligero, te sugiero que busques en otro lugar (SQL Server es buena OMI).

Si los usuarios pueden esperar el doble de tiempo para una aplicación con la mitad de las características que desean, entonces no utilizar el acceso.

Jet no tiene la lógica de bloqueo sofisticada necesaria para soportar escenarios multiusuario. Usted puede conseguir lejos con su uso si su aplicación es en su mayoría lee y bajo contención.

sitios web

que he visto apoyan muchos usuarios, pero recomendaría SQL Express a menos que tenga una razón de peso para elegir Jet.

Te puedo decir por experiencia dolorosa que Jet 3 / 3.5 no era fiable. Vi que choque con frecuencia con una carga ligera y cuando hubo accidentes que corría el riesgo de corrupción de datos. Lo que solía ser extremadamente sensibles a los problemas de alimentación, cualquier cliente de chocar contra ella (incluso la interfaz de usuario vinculado a la MDB), y cualquier problema de LAN. Las versiones más recientes de Jet podría ser mejor, pero el cambio a SQL Server es claramente el camino a seguir en mi opinión para que no sea la entrada de datos triviales con un pequeño número de usuarios de nada. SQL Express es gratuito y que en realidad no pierde nada, especialmente si usted es la interfaz de usuario está en .Net, en lugar de acceso.

EDIT:. Microsoft no cree que se debe confiar en Jet 4 o bien

a partir de: http://support.microsoft.com/kb/303528

Microsoft Jet no está diseñado para su uso con aplicaciones de alta tensión servidor, aplicaciones de servidores de alta concurrencia, o 24 horas al día, siete días a la semana aplicaciones de servidor. Esto incluye aplicaciones de servidor, como las aplicaciones Web, aplicaciones de comercio electrónico, aplicaciones transaccionales y aplicaciones de servidor de mensajería. Para este tipo de aplicaciones, la mejor solución es cambiar a un verdadero sistema de base de datos cliente / servidor basado en, por ejemplo, Microsoft Data Engine (MSDE) o Microsoft SQL Server. Cuando se utiliza Microsoft Jet en aplicaciones de alta tensión, como Microsoft Internet Information Server (IIS), puede experimentar cualquiera de los siguientes problemas: la corrupción de base de datos problemas de estabilidad, tales como choques o bloqueo de IIS fallo repentino o el fracaso persistente del controlador para conectarse a una base de datos válida que requiere re-iniciar el servicio IIS

acaba de comprobar si el archivo de bloqueo db (como .ldb) está allí o no. Si está allí, alguien está accediendo a ese archivo. Si no está allí, en la actualidad no existe un acceso a ese archivo y se puede proceder. De lo contrario, esperar a que cuando ese archivo (.ldb) ya no está vigente.

Si utiliza un servidor de terminales, el rendimiento es muy bueno. Tenemos más soluciones hasta 50 usuarios en un MDB de acceso. El desarrollo es muy rápido y fácil implementación.

Problemas:

  • todo el mundo puede copiar los datos MDB
  • No hay derechos de acceso
  • procedimientos
  • tienda limitada
  • Optimizar (comprimir y reparación) sólo es posible con ninguna base de datos el uso de datos
  • límite de 2 GB!
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top