Olá pessoal.

 

Estou preciso rodar um procedimento em minha aplicação que requer algumns

cuidado.

Por exemplo: A executar uma atualização ex.(preço/valor) em determinada tabela

é preciso que nenhum usuário esteja usando esta tabela/registro, pois isto poderia 

causar perda de dados atualizado qdo. o outro usuário fizesse a gravação dos dados

que estava em sua tela antes do procedimento de atualização mencionado.

Como posso saber se existe usuários usando esta tabela ?.

Como posso enviar um aviso para os demais usuários não acessar ou impedir que outros possa entrar?.

Ou como executar este procedimento de atualização qdo. não há usuarios em uso.

Grato pela ajuda.

 

Aguiar.

 

Pra evitar esse mesmo tipo de problema, em minha tabela pedido criei um campo chamdo em_uso, sempre que qq usuário abre um pedido e solicita alteração a primeira coisa que faço é testar se esse campo é true, se não for, gravo a opção em_uso como true, e for, mando um aviso dissendo que algum usuário está em modo de edição desse pedido.

espero ter ajudado.

 

uso do lock ...

Iniciando os testes....
Passos
01 - Você deve utilizar dois Query Analyzer. (OBS devem ser duas janelas do
Query Analyzer e não duas novas querys) Conecte no servidor AresDesenv
banco de dados Desenv

02 - Query Analyzer 1 rode o seguinte código

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION
select * from Table3 with (XLOCK)

OBS: note que o código simplesmente vai rodar e pronto

03 - No Query Analyzer 2 rode o seguinte código

exec sp_lock XX

Onde XX é o spid do Query Analyzer 1
Observe que o SQL vai gerar um lock do tipo Mode = X, esse tipo de
lock não é compartilhado.

04 - Agora faça o seguinte no  Query Analyzer 2 rode o seguinte código

select * from desenv..Table3

O SQL não vai conseguir completar a instrução uma vez que estamos
com uma transação aberta e um lock não compartilhado em cima da tabela de
trabalho (ele vai resolver isso quanto tiver um commit ou um rollback),
portanto aborte (cancele) esse teste

05 - Agora rode o seguinte código no Analyzer 2

select * from desenv..Table3 with (nolock)

Isso o SQL vai ser capaz de executar pois você acabou de abrir mão
do controle transacional

Portanto é por isso que falamos que o nolock pode trazer sujeira, suponha
que estivéssemos fazendo um comando de insert ao invés de um select no Query
Analyzer 1 com o uso do nolock os dados insertados retornariam no select (no
Query Analyzer 2) com nolock mesmo que a transação não tenha sido comitada.

Portanto esse são os ganhos e as perdas com o uso do nolock.