Olá senhores,
Gostaria de saber como os senhores lidaram com esta situação que aparentemente só acontece no SGBD SQL Server. Trabalho no desenvolvimento de um sistema multibanco que utiliza transação pessimista. Ou seja, somente quero ler informações "commitadas". Todos os dados que não forem "commitados" considero dados inconsistentes. No SQL Server (no meu caso 2005) se eu abrir uma transação, alterar, salvar e não dar commit ele da lock na tabela em questão. Todas as outras consultas ficarão literalmente travadas, até que o commit desta transação seja efetuado. Alguém sabe a causa disto? É assim mesmo que o SQL Server se comporta nesse caso? Por que os outros bancos como o FireBird e o Oracle não se comportam desta maneira mesmo utilizando ReadCommited? Estudei o hint NOLOCK que transforma aquele select especifico em uma consulta Read Uncommited, isto está ok, não gera mais o lock. Mas ele me retorna os dados antes de "Commitar". O que não é legal. Imagine que um dado está sendo inserido por um usuário enquanto Outro usuário está tirando um relatório e esta informação está saindo no relatório. Daí da um erro, e acontece um Rollback. Eu tenho um dado no relatório que não existe na base. ReadPast me traz todos os registros que não estão "lockados". O que também não satisfaz, pois o usuário pode estar editando um registro, importante alterando por exemplo a descrição, e estou tirando um relatório com valores. Esse registro não vai aparecer no relatório. Um colega uma vez disse " Qualquer que for a sua escolha, todas as opções são ruins", é isso mesmo ? Estas situações me fazem chegar a conclusão de que o Sql Server não é um banco de dados compatível com isolation ReadCommited, pois se para evitar um lock eu devo usar uma instrução Read Uncommited. No SqlServer também, estou com um problema intrigante. Se eu tenho uma query com fetch de 30 ou XX registros e tento alterar algum registro, após salvar o registro não salva. Somente se eu der um FetchAll, alterar e salvar, aí então os dados são salvos. Se alguém passou por esses problemas, qualquer sugestão é bem vinda. []'s Davi Wall. [As partes desta mensagem que não continham texto foram removidas]
