Hola Martín, como estás, tanto tiempo !
Si efectivamente y lo tengo clarísimo. El peligro de traer fruta, como vos decis. Lo que estoy haciendo y ya lo pude probar, es que a la hora de mostrar en pantalla datos ya grabados en el sistema, o generar consultas estadísticas, o emitiendo reportes que involucran muchos registros, no depender de los bloqueos que me está generando el hecho de que 20 estaciones estén insertando registros permanentemente. Por ahora lo resolví utilizando el comando SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED inmediatamente después de abrir una conexión, lo cual queda configurado mientras la conexión exista. Ahora bien, a la hora de leer o actualizar un dato como podría ser un campo autoincremental, lo vuelvo a SET TRANSACTION ISOLATION LEVEL READ COMMITTED hago la lectura del dato cierto, actualizo al nuevo valor icrementado y vuelvo a SET TRANSACTION ISOLATION LEVEL READ COMMITTED. Hice algunas pruebas como por ejemplo actualizar un dato y no hacer el commit trans. Consulto ese dato y ya está actualizado, entiendo que si hubiese un rollback , el dato que consulté es fruta, estuve evaluando el impacto y vale mucho más el hecho de consultar libremente todo lo que quiero sin depender de las modificaciones que se están realizando en la base de datos. Esperemos andar bien, Te mando un abrazo y gracias por tu opinión tan valiosa. Sebastian. De: [email protected] [mailto:[email protected]] En nombre de Martín Salías Enviado el: Miércoles, 20 de Abril de 2011 01:53 p.m. Para: GUFA List Member Asunto: [GUFA] Uso de NOLOCK (sqlserver) Hola, Sebastián. Casualmente en estos casos es donde NOLOCK podría traerte problemas, como dice Juancho. Si usás NOLOCK por ejemplo, para traer el último número de factura, o para el saldo de un comprobante, en un entorno de cierta concurrencia como el que mencionás, podrías estar leyendo fruta, para utilizar términos técnicos. Por ejemplo, podrías estar leyendo el número 358 mientras hay una transacción en ejecución que te da el 359. ¿Se entiende? Saludos, --- Martín Salías <http://CodeAndBeyond.org> 2011/4/20 Sebastian Massetti <[email protected]> Gracias Juan, muy clara tu explicación. En realidad quiero usar nolock en la mayor parte de consultas pequeñas, que traen a veces un solo registro, el tema es que por lo que estuve viendo, en mi caso hay muchos usuarios por ejemplo insertando facturas al mismo tiempo. Lo que me produce bloqueos muy cortitos pero repetidos y pone muy lento usar el sistema para consultas o para posicionarse simplemente en un comprobante, pensé que con el NOLOCK podría llegar a solucionar esto, de hecho funciona más rápido y no me precupa tanto el tema de la consulta sucia, ya que no lo voy a aplicar para consultas de tipo listado, sino para traer a pantalla datos puntuales de un registro en la mayoría de las veces. Muchas gracias por tu respuesta. Sebastian. De: [email protected] [mailto:[email protected]] En nombre de Juan Calcagno Enviado el: Miércoles, 20 de Abril de 2011 11:07 a.m. Para: GUFA List Member Asunto: [GUFA] Uso de NOLOCK (sqlserver) Pancho, habria que preguntarle al moderador si esto es realmente un OT . Sebastian, El link provisto por Pancho me parece que no aclara demasiado, primero porque no dice claramente en que casos es recomendable usarlo (si es que fuese recomendable) y el porque. La sintaxis en todo caso seria SELECT * FROM Tabla with NOLOCK (si es que esto lo tenes en algún Stored Procedure de SQL) Tene en cuenta que NOLOCK es un comando Semi-obsoleto (al igual que READUNCOMMITED no tiene soporte en futuras versiones de SQL para usar con UPDATE o DELETE http://msdn.microsoft.com/en-us/library/ms143729.aspx ). En tu caso que aparentemente solo pensas utilizarlo para consultas, NOLOCK es algo que solo querrías utilizar en queries de un tiempo de ejecución extenso, pero aun siendo asi, tenes que tener en cuenta que el resultado es una lectura-sucia (dirty read). Esto significa que con NOLOCK estas trayéndote data sin importar si es totalmente precisa: ejecutando el mismo query con NOLOCK y sin la clausula ORDER te puede traer un set de datos ordenado de una manera y el mismo query sin NOLOCK devolverte un resultado ordenado de otra manera, y has en algunos casos, el mismo registro dos veces. En escenarios de alta concurrencia, quizás alquien pueda justificar el uso de utilizar NOLOCK, pero no siendo asi, con data relativamente estatica no tiene sentido el uso por dar un ejemplo extremo. El uso deberías evaluarlo para cada caso en particular y no me parece una buena practica mandarlo por defecto en todas tus queries (sean desde VFP o desde SQL SP). Utilizar este tipo de comandos a lo largo y ancho de una aplicación es como comer en McDonalds, es rápido, fácil y te da una satisfacción instantánea, pero en el largo plazo te mata. En fin, quizás alguien tenga otra idea distinta, bienvenido el intercambio de ideas. Saludos, Juan Luis Calcagno From: [email protected] [mailto:[email protected]] On Behalf Of francisco prieto Sent: Wednesday, April 20, 2011 9:10 AM To: GUFA List Member Subject: [GUFA] Uso de NOLOCK (sqlserver) Sebastian, para la proxima esto sería una OT porque es un foro de VFP. Leete este articulo. http://stackoverflow.com/questions/64208/how-to-force-nolock-hint-for-sql-se rver-logins Saludos, Pancho Cordoba El 20 de abril de 2011 09:34, Sebastian Massetti <[email protected]> escribió: Hola Lista, Quería saber si es posible indicar al motor que todas las consultas que se harán no bloquearán las tablas involucradas, para ver si puedo evitar transcribir todas las consultas, para evitar agregar (NOLOCK) , pensé que tal vez haya una sentencia que le indique esto al motor . Desde ya muchas gracias. SELECT * FROM Tabla SELECT * FROM Tabla (NOLOCK)
