Visual Basic.NET - No se pudo usar;" el archivo ya esta en uso

   
Vista:

No se pudo usar;" el archivo ya esta en uso

Publicado por Jeimar Arias (7 intervenciones) el 30/08/2008 15:22:31
Se tiene un sistema que debe funcionar en red, desarrollado en Visual
Studio.Net 2003, con base de datos access 2000. Versión del .NET Framework 1.1

El programa funciona bien en un computador con un usuario. Cuando hay varias
sesiones abiertas (4, 5, inclusive de dos en adelante), y también desde varias
estaciones de trabajo, se presentan errores, debido a posibles bloqueos en la
base de datos o a tablas de la base de datos, posiblemente porque pueden
estar accediendo al tiempo a la misma tabla o incluso a la base de datos.

Además pone lenta la red. Algunas veces el usuario windows bloquea toda la
base en modo exclusivo.

Complementando lo anterior, esta es la cadena de conexión:

<add key="CadenaConexion" value="Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=\PC1EmprexEmprex.mdb" />

Si alguien me puede orientar en la solución le agradezco de antemano.

Jéimar
Valora esta pregunta
Me gusta: Está pregunta es útil y esta claraNo me gusta: Está pregunta no esta clara o no es útil
0
Responder

RE:No se pudo usar;

Publicado por qarthadasht (4 intervenciones) el 30/08/2008 18:26:01
No te va a gustar lo que voy a decirte; pero voy a decírtelo igual.

Primera parte del problema : TODAS las bases de datos bloquean páginas de bytes cuando se accede a un registro o a un grupo de registros durante una actualización de datos. Esto habitualmente sucede con los UPDATE o con los DELETE. Mientras eso sucede, ningún usuario puede acceder a esos datos, como es lógico, hasta que el motor de base de datos libera el bloqueo. El problema se agrava exponencialmente si haces actualizaciones o borrados en cascada, porque el motor necesita comprobar que los datos que va a manipular no están comprometidos en otros procesos y debe actualizar los índices correspondientes.

Segunda parte del problema : Por mi experiencia con bases de datos Access en red, este tipo de bases de datos son la peor opción para trabajar porque los bloqueos se hacen en páginas de 4 kilobytes o más. 4 kilobytes bloqueados en un momento dado te pueden paralizar el funcionamiento de 40 registros o más, con lo que eso significa.

Tercera parte (y última) del problema : Si la manera en que la aplicación está programada es mediante conexiones síncronas (es decir, abro la base de datos cuando entro en la aplicación y no me desconecto hasta que salgo de la aplicación), usando los controles de acceso a datos del Visual, realmente tienes un problema. Mientras la conexión está abierta, la red debe soportar el tráfico contínuo de datos entre el servidor y cada terminal sólo para asegurarse de qué datos están comprometidos y por quién y notificárselo al resto de los usuarios conectados.

Aquí viene lo que no te va a gustar (nosotros aplicamos un sistema de bloqueos y acceso a datos que te resolvería el problema pero que no te ayudaría en la situación en la que te encuentras ahora, por lo que te lo ahorro).

La solución más lenta de implementar pero que seguro te soluciona el problema es que te conectes a la base de datos de modo asíncrono. Es decir, mandas una petición a la base de datos con lo que quieres hacer, la base de datos te devuelve los datos, y tú cierras la conexión con la base de datos y manejas la información en el lado del cliente. En ese momento, la red no tiene carga de datos que vayan de una lado a otro y el servidor está desocupado para atender otras peticiones.

El único problema grave a solventar aquí son los bloqueos. Yo te recomendaría una tabla que se llame "bloqueos" que guarde el nombre del usuario que está editando el dato, y la hora y la fecha en que se hizo. Cuando tomas los datos para editarlos, primero compruebas que esos mismos datos no estén ya bloqueados. Si no lo están, registras al usuario en "bloqueos" y te "llevas" los datos para manejarlos, dejando tu rastro en la tabla "bloqueos" para que otras peticiones sepan que no pueden usar esos mismos datos. Cuando termines de editar la información, la actualizas sin problemas (abres conexión, escribes en la base de datos, cierras conexión) y borras el registro de "bloqueos" que habías hecho previamente.

Esto funciona sin problemas en el 100% de las bases de datos, independientemente del número de usuarios y del tipo de conexión que se haga, local o remota.

Creo que me ha salido una respuesta muy larga y no estoy seguro de que te haya podido ayudar. De todos modos, si tu duda persiste, házmelo saber y veré en qué puedo ayudarte.

Saludos.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

RE:No se pudo usar;

Publicado por Jéimar Arias V (7 intervenciones) el 01/09/2008 16:14:40
Muchas gracias qarthadasht.

Efectivamente, esperaba que la solución fuera mas sencilla y de pronto corta. Pero algo así me suponia que tenía que hacer. La otra opción que estoy a punto de optar es migrar mi aplicación a SQL Express, porque la suya me demanda mucha programación, dado que el sistema tiene algo cercano a 100 funciones (programas).

Saludos.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar