ms-access - ejemplos - conectar base de datos access visual basic 2010
Las operaciones de la base de datos VB6 se ralentizan cuando varios usuarios se conectan a la base de datos (3)
Esa es la forma en que MS Access funciona. Si bien es compatible con varios usuarios, y es un poco compatible con colocar el DB en un recurso compartido de archivos para que varias PC puedan acceder a él, tampoco lo hace realmente bien. Y si está haciendo ambas cosas (multiusuario y en una red para compartir archivos), entonces siento por su dolor.
La respuesta es ejecutar el asistente de actualización y convertirlo a una instancia de MS SQL Server. La edición MS SQL Server Express es una buena opción para reemplazar Acess en el caso. Tenga en cuenta que todavía puede conservar todos sus códigos e informes, etc. que tiene en Access, solo los datos deben ser movidos.
Para tener en claro las diferencias, en MS Access cuando lee datos de la base de datos, el programa lee todos los datos necesarios para realizar su consulta , no se realiza ningún procesamiento en el lado del servidor . Si esos datos residen en una red, usted está extrayendo esos datos a través de su red. Si hay varios usuarios, tiene una sobrecarga adicional de bloqueo. El programa / proceso de cada usuario establece un diálogo efectivo con el programa / proceso de los otros usuarios a través de la E / S de archivo (escribiendo información de bloqueo en el archivo o archivos en red). Y si la E / S de la red expira o tiene otros problemas, esos archivos pueden dañarse.
En SQL Server, es el motor de SQL Server el que administra las solicitudes de datos y solo devuelve los datos requeridos. También administra los bloqueos y puede detectar cuándo un cliente se desconectó o se agotó el tiempo de espera para realizar la limpieza, lo que reduce los problemas causados por varios usuarios en una red.
Actualmente estoy usando VB6 para conectarme a un MS access DB usando DAO y estoy experimentando una reducción de velocidad muy notable cuando un segundo usuario se conecta a la base de datos.
Estos son los pasos para reproducirse:
Abra la base de datos desde la computadora A iniciando sesión en el software
Agregue registros a la base de datos a través del software (toma aproximadamente .4 segundos)
Un segundo usuario inicia sesión en el software (Computadora B), es decir: esto abre la base de datos, muestra las transacciones de hoy, pero el usuario no hace nada más
En la computadora A, repita la operación de agregar registros, ahora la operación tarda aproximadamente 6 segundos
Informacion adicional…
la operación continúa tardando aproximadamente 6 segundos, incluso después de que Computer B cierra la sesión del software
si cierra y vuelve a abrir la aplicación desde la Computadora A, ¡la operación vuelve a tardar solo .4 segundos en ejecutarse!
¡Cualquier ayuda sería muy apreciada!
¡Gracias!
Como usted señaló que obtiene un rendimiento decente con un usuario en el sistema, obviamente su aplicación por naturaleza no está extrayendo demasiados datos a través de la red, y no podemos culpar a la velocidad de la red aquí.
De hecho, lo que está ocurriendo es que el sistema de intercambio de archivos de Windows está cambiando del modo de compartir archivos individuales al modo de archivos de varias comparticiones. Este modo de cambio de archivo causa un retraso significativo. Y esto también significa que el segundo o más usuarios deben intentar descubrir y configurar bloqueos en el archivo.
Para eliminar este retraso notable, simplemente al inicio de su aplicación, abra lo que llamamos una conexión persistente. Una conexión persistente es simplemente algo que obliga a la conexión de red a permanecer abierta en todo momento y, por lo tanto, se elimina este retraso significativo en el cambio entre dos modos de archivo para compartir archivos. Ahora encuentra que el rendimiento con dos usuarios debe ser el mismo que uno (suponiendo que un usuario esté inactivo y no aumente la carga de la red). Por lo tanto, en el momento de inicio de la aplicación, abra una tabla de fondo a una var global y MANTENGA esa tabla abierta en todo momento.
Tuvimos este problema con nuestra aplicación VB3 / Jet DB 2.5 cuando hicimos la transición al uso de servidores de archivos más nuevos.
El problema es el "bloqueo oportunista": http://support.microsoft.com/kb/296264?wa=wsignin1.0
Albert probablemente está describiendo lo mismo; el servidor permitirá el acceso exclusivo de un cliente a un archivo, pero cuando otro se presente, este acceso exclusivo se "interrumpe" entre ellos, causando retrasos ya que el cliente con el bloqueo descarga todo su caché local al servidor antes de que el otro cliente pueda acceder el archivo.
Esta también puede ser la razón por la que está obteniendo un buen rendimiento con un cliente: si se requiere un bloqueo, puede almacenar en caché todos los datos localmente.
Esto también puede causar daños desagradables si uno de sus clientes sufre un corte de energía o se desconecta de la red, ya que este enjuague de la caché local al servidor puede interrumpirse.
Usted solía ser capaz de desactivar esto (en el cliente , por lo que necesita dar servicio a TODOS los clientes) en Windows 2000 y XP según el artículo, pero después de Vista SP2 parece ser imposible.
Los comentarios sobre no usar Access / JetDB como una base de datos multiusuario son esencialmente correctos, no es una buena opción arquitectónica, especialmente a la luz de lo anterior. DAO es también una biblioteca obsoleta, incluso en el VB6 obsoleto. ADODB es una mejor opción para VB6, y debería permitirle cierta medida de la independencia de la base de datos dependiendo de cómo esté escrita su aplicación.