Bloqueos de tablas trabajando desde Access contra SQL

09/07/2004 - 00:50 por CarCar | Informe spam
Hola:

Entorno de trabajo: Access 97 trabajando con una base de
datos SQL Server 2000 por medio de ODBC y DAO.

Hace hoy una semana presenté un problema que se había
presentado en una empresa cliente, el problema consistía
en que se quedaban bloqueadas tablas sin razones
aparentes, el intento de modificación de registros o el
intento de crear nuevos registros bloqueaba las tablas
para cualquier otro usuario que intentara acceder a ellas.

A pesar de que en su momento pensamos que se había
solucionado el problema e incluso lo comenté aquí, este no
llegó a solucionarse realmente, pues al día siguiente
estábamos otra vez con las mismas y hasta ayer no
conocimos el origen y la causa del problema y, ahora sí,
la solución.

El origen del problema fue el aumento desmesurado del
número de registros de la base de datos en los últimos
días, tablas que contenían 4.000 registros pasaron a tener
30.000 y tablas con 30.000 a tener 500.000.

Después de cambiar los chips de memoria de los servidores,
de cambiar hasta a 3 servidores diferentes la base de
datos, para descartar cualquier problema de Hardware, ayer
nos pusimos en contacto con Microsoft y de allí llegó la
solución, cuando un técnico de Access de Microsoft France,
nos comentó:

"When you open a form which is based on an ODBC linked
table, Access 97 requests some locks to the SQL SQL Server
if the form only loads the first records of the table.
This can happen if the table contains several thousands of
records.

If this happens, you should see some IS (Intent Shared)
locks on the SQL Server by using the SQL Server Enterprise
Manager.

These locks can stay on the tables for several minutes if
the "locking end-user" does not use the Access interface."

Que, en versión "muy libre", viene a decir que cuando las
tablas tienen muchos registros el ODBC puede producir
bloqueos en las tablas.

En el mismo correo, viene la siguiente solución:

"Create one table named "MSysConf" (in your SQL Server
database SubVenDat) to control how fast Access fetches
rows of a query during idle time.

By setting the fetch delay high, network traffic is
reduced, but read locks are left on pages longer.

By setting delay lower, locking is reduced, and moving to
the last record in a datasheet is speeded, but network
traffic increases.

The chunk size option provides an ever finer level of
control. For example, you can try to set the number of
rows on each background chunk fetch to 30000 (or even
more) instead of 100 (which is the default value when
the "MSysConf" table does not exist)

You can also reduce the delay (in seconds) between each
background chunk fetch to only one second instead of the
default value (10 seconds when the "MSysConf" table does
not exist).

For further information about how to create the MSysConf
table, please read the document which is included in the
file Rjwpv3.exe

That you can download the file Rjwpv3.exe at the following
address:

http://download.microsoft.com/downl...hitep5/1/W
98/EN-US/Rjwpv3.exe "

Que también, en versión "muy libre" viene a decir... los
parámetros que, por defecto, usa ODBC para comunicarse con
SQL Server, son valores pensados para las redes de 1.995,
valores que están superados actualmente. Para variar estos
valores por defecto hay que crear una tabla llamada
MSysConf en la base de datos SQL Server y dónde ODBC por
defecto dice recupera 100 registros, pongamos 30.000 y
donde ODBC por defecto dice 10 segundos, pongamos 1.

De momento parece que el programa, por fin, vuelve a
funcionar.

Un cordial saludo a todos.
CarCar
MVP-Access

PD: El problema es exactamente el mismo con Access XP, a
dónde migramos previamente ya que Microsoft ya no da
soporte a Access 97.
 

Leer las respuestas

#1 MAXI
09/07/2004 - 02:32 | Informe spam
Hola Carcar, gracias por la colaboracion!! en resumen:
No usar Access con Sql no ;-)




Maxi

Buenos Aires - Argentina

Desarrollador .NET 3 Estrellas

Mail: Maxi_accotto[arroba]speedy.com.ar

MSN:


"CarCar" escribió en el mensaje
news:2a04d01c4653d$f1020b70$
Hola:

Entorno de trabajo: Access 97 trabajando con una base de
datos SQL Server 2000 por medio de ODBC y DAO.

Hace hoy una semana presenté un problema que se había
presentado en una empresa cliente, el problema consistía
en que se quedaban bloqueadas tablas sin razones
aparentes, el intento de modificación de registros o el
intento de crear nuevos registros bloqueaba las tablas
para cualquier otro usuario que intentara acceder a ellas.

A pesar de que en su momento pensamos que se había
solucionado el problema e incluso lo comenté aquí, este no
llegó a solucionarse realmente, pues al día siguiente
estábamos otra vez con las mismas y hasta ayer no
conocimos el origen y la causa del problema y, ahora sí,
la solución.

El origen del problema fue el aumento desmesurado del
número de registros de la base de datos en los últimos
días, tablas que contenían 4.000 registros pasaron a tener
30.000 y tablas con 30.000 a tener 500.000.

Después de cambiar los chips de memoria de los servidores,
de cambiar hasta a 3 servidores diferentes la base de
datos, para descartar cualquier problema de Hardware, ayer
nos pusimos en contacto con Microsoft y de allí llegó la
solución, cuando un técnico de Access de Microsoft France,
nos comentó:

"When you open a form which is based on an ODBC linked
table, Access 97 requests some locks to the SQL SQL Server
if the form only loads the first records of the table.
This can happen if the table contains several thousands of
records.

If this happens, you should see some IS (Intent Shared)
locks on the SQL Server by using the SQL Server Enterprise
Manager.

These locks can stay on the tables for several minutes if
the "locking end-user" does not use the Access interface."

Que, en versión "muy libre", viene a decir que cuando las
tablas tienen muchos registros el ODBC puede producir
bloqueos en las tablas.

En el mismo correo, viene la siguiente solución:

"Create one table named "MSysConf" (in your SQL Server
database SubVenDat) to control how fast Access fetches
rows of a query during idle time.

By setting the fetch delay high, network traffic is
reduced, but read locks are left on pages longer.

By setting delay lower, locking is reduced, and moving to
the last record in a datasheet is speeded, but network
traffic increases.

The chunk size option provides an ever finer level of
control. For example, you can try to set the number of
rows on each background chunk fetch to 30000 (or even
more) instead of 100 (which is the default value when
the "MSysConf" table does not exist)

You can also reduce the delay (in seconds) between each
background chunk fetch to only one second instead of the
default value (10 seconds when the "MSysConf" table does
not exist).

For further information about how to create the MSysConf
table, please read the document which is included in the
file Rjwpv3.exe

That you can download the file Rjwpv3.exe at the following
address:

http://download.microsoft.com/downl...hitep5/1/W
98/EN-US/Rjwpv3.exe "

Que también, en versión "muy libre" viene a decir... los
parámetros que, por defecto, usa ODBC para comunicarse con
SQL Server, son valores pensados para las redes de 1.995,
valores que están superados actualmente. Para variar estos
valores por defecto hay que crear una tabla llamada
MSysConf en la base de datos SQL Server y dónde ODBC por
defecto dice recupera 100 registros, pongamos 30.000 y
donde ODBC por defecto dice 10 segundos, pongamos 1.

De momento parece que el programa, por fin, vuelve a
funcionar.

Un cordial saludo a todos.
CarCar
MVP-Access

PD: El problema es exactamente el mismo con Access XP, a
dónde migramos previamente ya que Microsoft ya no da
soporte a Access 97.

Preguntas similares