Necesito saber si el SQL Server versión 7 bloquea al realizar transacciones
a nivel de registro o a nivel de tabla. En nuestras pruebas nos bloquea toda
la tabla pero la documentación asegura que por defecto lo hace a nivel de
registro. ¿Y eso de que lo elige automáticamente el servidor? !!¿Se le puede
obligar a que sea siempre a nivel de registro?. (Y en tal caso a nivel del
servidor o a nivel de aplicación?)
Javier Alonso Prieto
MCP
"SQL Server 7.0 tiene la habilidad de bloquear a nivel de registro si esta
es
la solución más eficiente, pero si el coste de mantener bloqueos a nivel de
registro es exageradamente alto, bloqueará a nivel de página. Esto sucede,
por ejemplo, cuando se ejecutan transacciones con nivel de aislamiento
SERIALIZABLE y no hay un índice en los campos especificados en el rango.
Pero para demostrarte a ti mismo que SQL Server 7.0 SI bloquea a nivel de
registro, abre una conexión con Query Analyzer y ejecuta las siguientes
instrucciones:
USE Northwind
GO
BEGIN TRANSACTION
UPDATE Products
SET UnitPrice = 10
WHERE ProductID = 10
verás que un registro ha sido modificado. Los cambios no son permanentes, ya
que no hemos finalizado la transacción, por lo que el registro está
bloqueado. Abre una nueva conexión y ejecuta las siguientes instrucciones
(asegúrate que tienes seleccionado modo texto para las salidas):
SELECT *
FROM Products
WHERE ProductID = 8
GO
SELECT *
FROM Products
WHERE ProductID = 10
Verás que el producto correspondiente a ProductID=8 es mostrado sin ningún
problema, mientras que la segunda instrucción no puede ejecutarse ya que el
producto 10 está bloqueado por la otra conexión."
Verás cómo tiene razón (como siempre)
--
Un saludo
Carlos S
(quitar XXX para mi email)
Javier Alonso Prieto <Javier...@ceinsa.ws> escribió en el mensaje de
noticias uc58cc7IAHA.248@cppssbbsa05...
ROWLOCK, para obtener bloqueos a nivel de registro a pesar de que SQL Server
preferiría utilizar bloqueos a nivel de página o de tabla.
PAGLOCK, para obtener bloqueos a nivel de página a pesar de que SQL Server
preferiría utilizar bloqueos a nivel de tabla. Esto no tiene ning;un efecto
en el caso en que el bloqueo por defecto fuera a nivel de registro.
TABLOCK, para obtener bloqueos a nivel de tabla a pesar de que SQL Server
preferiría utilizar bloqueos a nivel de registro o de página.
Para mayor información sobre el tema consulta en Books OnLine la página
"Locking Hints"
--
Fernando G. Guerrero
QA Group Ltd., UK
Share what you know, learn what you don't
"Javier Alonso Prieto" <Javier...@ceinsa.ws> wrote in message
news:uc58cc7IAHA.248@cppssbbsa05...
Gracias
mig...@soft9126.es
Carlos Sacristán <csacri...@ocaso.es> escribió en el mensaje de noticias
urGGvG8IAHA.195@cppssbbsa05...
> Hace poco Fernando Guerrero publicó esto en respuesta a otra cuestión:
>
> "SQL Server 7.0 tiene la habilidad de bloquear a nivel de registro si esta
> es
> la solución más eficiente, pero si el coste de mantener bloqueos a nivel
de
> noticias uc58cc7IAHA.248@cppssbbsa05...
Si estas moificaciones las estás haciendo desde ACCESS, puedes encontrarte
con que Access bloquea permanente estos registros, pero solamente desde el
entorno de Access, ya que desde SQL Server han sido desbloqueadosrealmente.
Los bloqueos pertenecen a una transacción, si no hay transacción, no hay
bloqueos, así de simple.
--
Fernando G. Guerrero
www.QA.com, UK
PASS Spanish Group
"Share what you know, learn what you don't"
"Miguel Angel Santos" <mig...@soft9126.es> wrote in message
news:uDPjHqtqAHA.1300@tkmsftngp02...
Gracias.
Fernando G. Guerrero <fer...@GuerreroG.org> escribió en el mensaje de
noticias OjGtPtwqAHA.1924@tkmsftngp03...
Otra opción es manejar esta opción desde el string de conexión, mediante la
opción:
"OLE DB Services=-1;"
Para inhabilitar session pooling:
"OLE DB Services=-2;"
Tmabién se puede manejar modificando el registro. Echa un vistazo al
artículo Q228843 de MSDN donde verás diferentes opciones.
--
Fernando G. Guerrero
www.QA.com, UK
PASS Spanish Group
"Share what you know, learn what you don't"
"Miguel Angel Santos" <mig...@soft9126.es> wrote in message
news:uzVF9m7qAHA.684@tkmsftngp03...