[firebase-br] RES: Meio OFF [SQLSERVER VS FIREBIRD ou ORACLE]

[Davi Eduardo Borges Wall]

Marco!!! Seguinte!!

A instrução (HINT) NOLOCK faz com que o Select se torne DirtyRead. E não é bem isso o que eu estou procurando. DirtyRead's trazem dados não commitados e conseqüentemente irreais.

Se alguém está interessado eu achei uma solução para o problema
somente para SQL SERVER 2005, é uma instrução nova. Provavelmente muita gente andou reclamando para MS e eles não agüentaram.

ALTER DATABASE XXX
SET ALLOW_SNAPSHOT_ISOLATION ON
ALTER DATABASE XXX
SET READ_COMMITTED_SNAPSHOT ON

READ COMMITED SNAPSHOT é uma extensão de isolation Level que compatibiliza
o READ COMMITED como nos outros Bancos.
Então o SQL SERVER não vai mais gerar locks.

Ele vai levar o registro em transação para um TEmpDB e após commitado
Então ele irá escrever o dado na base de dados propriamente dita.

Agora o problema continua as versões anteriores do SQL SERVER.

Fazer o que !

[]'s
Obrigado pela atenção.

-----Mensagem original-----
De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em nome de Marco A
Enviada em: sexta-feira, 8 de junho de 2007 12:40
Para: lista em firebase.com.br
Assunto: Re: [firebase-br] Meio OFF [SQLSERVER VS FIREBIRD ou ORACLE]


nunca tive este problema, mas sei que o sql tem a opcao NOLOCK justamente 
para que o registro nao seja travado durante um select, ou seja independente 
de commitar ou nao ele nao trava o registro e nao deixa de retornar o valor. 
se vc nao usa esta clausula, ele tenta bloquear o registro enquanto lista. 
provavelmente se ele ja estiver bloqueado, ele retorna mensagem de erro.

tenta ai tipo select * from tabela nolock .....

se falei bobagem tbm, me corrijam ! rsrs



"Davi Eduardo Borges Wall" 
<davi.wall em mult.com.br> escreveu na mensagem 
news:C675ACED260795429F251C2D0AA212AD4D88F4 em internetsrv.mult.com.br...
Olá amigos,





Tenho uma dúvida intrigante. Trabalho no desenvolvimento de uma  aplicação 
multibanco SQLSERVER, FIREBIRD, ORACLE.



A questão é a seguinte...



(utilizando ReadCommited)

Inicio uma transação, em uma tabela eu altero um registro da coluna 
"DESCRICAO" de "TESTE" para "XXXX" e ainda não dei COMMIT.



Se em outra conexão eu efetuar um select desta tabela, o firebird e o oracle 
me retornam o valor TESTE para este registro. (valor anterior ao inicio da 
transação)



No SQL SERVER da LOCK!



Procurei na internet todo tipo de informação a respeito disto, e tudo indica 
que este é o comportamento correto do SQLSERVER

nesta ocasião.



A minha questão é POR QUÊ? Porque o SQLSERVER faz uma barbaridade dessas?

Se eu quero somente ler dados "COMMITADOS" o que ta não está commitado na 
faz diferença então pra que dar lock?



Pelo que percebi isto não tem solução, mas ainda estou muito curioso para 
saber o que levou a microsoft a seguir este caminho, totalmente diferente de 
outros SGDB's do mercado?





Se falei alguma besteira, por favor, me corrijam!

Qualquer dica é bem vinda, até mesmo o endereço de um grupo de discussão 
SQLSERVER.



[]'s

Obrigado.

Davi Wall.



______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
Para editar sua configuração na lista, use o endereço 
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
Para consultar mensagens antigas: http://firebase.com.br/pesquisa