none
Stored procedures em cascata RRS feed

Respostas

  • Boa Tarde,

     

    O SQL Server possui o limite de aninhamentos fixado em 32 níveis. Isso significa que se uma stored procedure chama uma view que chama uma tabela, serão gastos 3 níveis de aninhamento. Dificilmente você irá atingir esse limite, mas esteja ciente que ele não pode ser ultrapassado.

     

    Aninhar stored procedures não é uma prática ruim, pois, permite a construção de planos de execução mais elaborados e facilita o trabalho do otimizador, mas pode lhe trazer dificuldades adicionais no momento do DEBUG.

     

    O grande "problema" é controlar as configurações de sessão como SET DATEFORMAT, SET ANSI_NULLS além de níveis de isolamento, etc. Se você utiliza a mesma configuração para toda a sua sessão isso não é nenhum impecilho. Será um problema se haver diferenciação entre as chamadas.

     

    [ ]s,

     

    Gustavo

     

    terça-feira, 6 de janeiro de 2009 20:29
  • Olá Rogerio Jun,

     

    Isso depende. Você pode configurar ambas as possibilidades. Vai depender do tratamento de erro que foi dado e da severidade do erro. Erros muito severos podem para a execução imediatamente, erros medianos podem ser capturados e você pode escolher se prossegue ou não (dependendo do tratamento), erros informativos não tem impacto na mudança da execução.

     

    [ ]s,

     

    Gustavo

    terça-feira, 6 de janeiro de 2009 21:17

Todas as Respostas

  • Boa Tarde,

     

    O SQL Server possui o limite de aninhamentos fixado em 32 níveis. Isso significa que se uma stored procedure chama uma view que chama uma tabela, serão gastos 3 níveis de aninhamento. Dificilmente você irá atingir esse limite, mas esteja ciente que ele não pode ser ultrapassado.

     

    Aninhar stored procedures não é uma prática ruim, pois, permite a construção de planos de execução mais elaborados e facilita o trabalho do otimizador, mas pode lhe trazer dificuldades adicionais no momento do DEBUG.

     

    O grande "problema" é controlar as configurações de sessão como SET DATEFORMAT, SET ANSI_NULLS além de níveis de isolamento, etc. Se você utiliza a mesma configuração para toda a sua sessão isso não é nenhum impecilho. Será um problema se haver diferenciação entre as chamadas.

     

    [ ]s,

     

    Gustavo

     

    terça-feira, 6 de janeiro de 2009 20:29
  • Digamos que uma Stored Procedure A chame uma SP B. Se a B der algum erro, a A seguira adiante ou ira parar também?

    terça-feira, 6 de janeiro de 2009 20:46
  • Olá Rogerio Jun,

     

    Isso depende. Você pode configurar ambas as possibilidades. Vai depender do tratamento de erro que foi dado e da severidade do erro. Erros muito severos podem para a execução imediatamente, erros medianos podem ser capturados e você pode escolher se prossegue ou não (dependendo do tratamento), erros informativos não tem impacto na mudança da execução.

     

    [ ]s,

     

    Gustavo

    terça-feira, 6 de janeiro de 2009 21:17