[guillotmarc]

Hola.

Hace años que no utilizo SQL Server (nunca llegué a utilizar el SQL Server 2000), así que no se me ocurre mucho.

Realmente creo que tienes que mirar los bloqueos, un problema de saturación de memória lo puedes tener en un momento dado (a veces tenía problemas de este tipo, con transacciones que quedaban colgadas), pero no cada vez que ejecutas esa instrucción.

SQL Server no lleva nada bien los bloqueos. Si modificas un registro solo debería bloquear ese registro, pero te encuentras en que a pesar de que realmente solo ese registro está bloqueado, no se pueden hacer consultas sobre la tabla debido a que no se puede evaluar correctamente el WHERE en todos los registros de la tabla (uno está bloqueado).

Además estaban los bloqueos sobre los índices que utiliza la tabla, etc ... Total, que en estos Foros he visto gente que para evitar que dos usuarios puedan entrar en el mismo registro, lo bloquean mediante el mecanismo de transacciones. Realmente hay que tener mucho valor en SQL Server para hacer eso. En seguida te encuentras con tablas totalmente bloqueadas.

Justamente por varias razones como esta, dejé de utilizar SQL Server y me pasé a Interbase/Firebird (es una gozada como implementan las transacciones).

Para hacerte una idea de lo que puede estar pasando, haz un seguimiento mediante el Administrador Corporativo, de los bloqueos que tienes activos justo antes de lanzar la actualización de los detalles.

Por cierto, puedes establecer el Lock TimeOut al empezar las modificaciones (antes de insertar/modificar el maestro), no hace falta que esperas al momento de crear los detalles. Esa variable va a permanecer con ese valor durante toda la sesión (si no lo recuerdo mal).

NOTA : También puedes jugar con el ISOLATION_LEVEL, si lo bajas a un nivel como el Read Uncommited, te puedes ahorrar muchos problemas de bloqueos (aunque leerás información que puede no ser del todo coherente).

Saludos.