Usuários mais ativos no mês 12/2019
  1. henrique.muller

    844 Pontos

  2. paulo.silva

    842 Pontos

  3. maicon.pereira

    582 Pontos

  4. juliano.pezzini

    472 Pontos

  5. leandro.piscke

    428 Pontos

  6. diuari.molinari

    400 Pontos

  7. dirceu.schlickmann

    347 Pontos

  8. Camila

    288 Pontos

  9. bruno.cardoso

    272 Pontos

  10. Rafael Leonhardt

    253 Pontos

É possível remover as hints (NOLOCK) "forçadas" em SQLs tratados pelo Runner?

+8 votos
61 visitas

Apenas para fins de demonstração para um cliente, solicitaram-me a elaboração de alguns SQLs. Em um deles, faz-se necessário o uso de uma Common Table Expression do SQL Server.

Entretanto, o Builder apresenta erro ao executar o SQL.

 

O mesmo SQL, executando na ferramenta do SQL Server, executa normal.

 

 

Ainda na Dash SQL Server, adicionando os (NOLOCK) da mesma maneira que o Runner faz, é apresentado o mesmo erro.

 

 

De acordo com a Microsoft, ao usar Table Hints recomenda-se o uso de WITH... "Omitting the WITH keyword is a deprecated feature: This feature will be removed in a future version of Microsoft SQL Server." - http://msdn.microsoft.com/en-us/library/ms187373.aspx

Na Dash do SQL Adicionando os (NOLOCK) com WITH funciona normal.

Já no Builder, não funciona. Tenta executar o SQL, acredito que não consiga, e retorna -1 linhas, sem apresentar nenhum erro.

Fiz uma pesquisa na Wiki, e vi que se for feito um SQL diretamente de uma TBQuery no Delphi, ou BPesquisa na Macro, é possível desligar o atributo ForceNoLockOnTables do objeto para não gerar estes NOLOCK. Mas estou fazendo diretamente no módulo "Adm" -> "Desktop" -> "Data Packets", e não tenho controle sobre a programação, tudo deve ser resolvido no próprio SELECT.

É possível desligar esta geração de (NOLOCK) à nível global, de todo o sistema??

Não seria melhor alterar a funcionalidade para colocar "WITH (NOLOCK)"  ao invés de apenas "(NOLOCK)" nos comandos executados?

 

perguntou Jul 10, 2014 por fernando.medeiros (195 pontos)
republicada Jul 14, 2014 por fernando.medeiros
Todas as ferramentas deveriam seguir o que esta no server manager, salvo configuração especifica de cada ferramenta.
Acredito que o builder não tenha esta configuração e não a respeite.

O Readpast/Nolock surgiu para normatizar o acesso a dados em ambientes multi-usuários, que é uma caracteristica do runner. O builder por sua vez tem a caracteristica de poucos usuários, por se tratar de uma ferramenta de desenvolvimento.

1 Resposta

+6 votos
 
Melhor resposta

Sim, é possível.

Utilize o parâmetro READPAST = "N" conforme informado em :

http://wiki.benner.com.br/wiki/index.php?title=Par%C3%A2metros_do_Server_Manager#READPAST

O readpast utilizado no sql server é (NOLOCK).

respondida Jul 15, 2014 por dirceu.schlickmann (347 pontos)
selecionada Jul 15, 2014 por fernando.medeiros
Realmente, desligou os (NOLOCK) no Runner. Mas aparentemente, não no Builder... O SELECT ainda não executa no Builder, mesmo após setar o parâmetro no ServerManager.
Mesmo após reiniciar o sistema?
Se por "Reiniciar o Sistema" você refere-se àquele botão no módulo "Sistemas" do ServerManager... sim, mesmo após reiniciar sistema. Runner OK, Builder NOT OK.
Creio que os Builder não seja afetado pelos parâmetros do Server Manager... Ou estou equivocado?
O Builder tem um flag Leitura na janela de execução de comandos SQL que vem por padrão selecionado e que, em bancos SQL Server, força o NOLOCK. O problema aí é que ele faz uma verificação no comando a ser executado.. se não começar com SELECT *, mesmo que você tenha desmarcado o flag ele marca sozinho, ou seja, força o NOLOCK nas consultas.
O Builder precisaria passar a considerar também o parâmetro do ServerManager (que não necessariamente precisa ser o READPAST... se tiver o parâmetro READCOMMITTEDSNAPSHOT estiver como N ele coloca NOLOCK também).

Perguntas relacionadas

0 votos
1 resposta 15 visitas
+6 votos
2 respostas 38 visitas
+7 votos
1 resposta 45 visitas
+3 votos
1 resposta 17 visitas
17 visitas perguntou Dez 6, 2016 por maicon.pereira (582 pontos)
+10 votos
1 resposta 38 visitas
...