none
Script de Alter executa com sucesso mesmo quando não existe base no script RRS feed

  • Pergunta

  • Pessoal,

    Estou com uma situação estranha aqui no banco. Agora estamos com o SSMS na versão 14.0.17199.0 e estamos com o MSSQL 2014 SP2 em nosso ambiente. Anteriormente quando executávamos um alter em uma procedure se tivesse um objeto que não existisse no banco ( como um banco de dados ou um linked server) o SQL me retornava erro, porém agora ele esta executando com sucesso o alter, fazendo com quem a gente não perceba que esta faltando algo e quando o usuario vai executar a procedure ela falha. Alguém sabe se é alguma configuração no sp_configure ou então no SSMS que eu tenho que alterar para voltar a dar erro?

    Carlos Justo

    quinta-feira, 11 de janeiro de 2018 17:51

Respostas

Todas as Respostas

  • Deleted
    quinta-feira, 11 de janeiro de 2018 21:34
  • Eu acho estranho é o comportamento citado em “Anteriormente quando executávamos um alter em uma procedure se tivesse um objeto que não existisse no banco ( como um banco de dados ou um linked server) o SQL me retornava erro”. O usual, inclusive documentado no comando CREATE PROCEDURE, é

    Um procedimento pode referenciar tabelas que ainda não existem. No momento da criação, apenas a verificação de sintaxe é executada. O procedimento não é compilado até ser executado pela primeira vez. Somente durante a compilação todos os objetos referenciados no procedimento são resolvidos. Portanto, um procedimento sintaticamente correto que referencie tabelas que não existem pode ser criado com êxito; entretanto, ele falhará em tempo de execução se as tabelas referenciadas não existirem.

    A documentação cita tabelas; falta pesquisar como é o comportamento com relação a outros objetos (colunas, banco de dados, etc).

    Qual era a versão do SQL Server utilizada anteriormente?

    O artigo Deferred Name Resolution and Compilation pode ser útil para compreender o que está a ocorrer.

    PS: tinha uma vaga lembrança sobre esse assunto ter sido mencionado anteriomente neste fórum; pesquisando, encontrei o tópico Identificar erro em procedure - Management Studio, de 2014.


    e-mail       José Diz     Belo Horizonte, MG - Brasil


    José Diz,

    Posso estar enganado, mas parece que isso era um bug que surgiu após o SP2 no SQL Server 2014.

    Você se lembra de algo?


    Pedro Antonio Galvao Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    quinta-feira, 11 de janeiro de 2018 22:25
    Moderador
  • Justo,

    Você possui algum outro ambiente com versão diferente do SQL Server 2014 que seja possível testar este comportamento?


    Pedro Antonio Galvao Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    quinta-feira, 11 de janeiro de 2018 22:26
    Moderador
  • Deleted
    quinta-feira, 11 de janeiro de 2018 22:59
  • Ai já ´euma questão de vermos o script de que está falando. De puder poste ele.
    sexta-feira, 12 de janeiro de 2018 12:09
  • Um exemplo simples do codigo seria:

    Alter Procedure [dbo][MinhaProcedure]

    as begin

    select * from [BANCODEDADOS1].[DBO].[TABELA]

    END

    Anteriormente se eu tentasse executar e o banco de dados BANCODEDADOS1 não existisse o SSMS me retornaria com erro e hoje em dia a situação que esta ocorrendo é que executa com sucesso.

    No exemplo que eu sei , foi que tinhamos um linked server

    select * from [Servidor].[BANCODEDADOS1].[DBO].[TABELA]

    E mesmo assim se o banco não existisse no outro servidor apareceria o erro e agora não mais.

    sexta-feira, 12 de janeiro de 2018 18:52
  • Posso estar enganado, mas parece que isso era um bug que surgiu após o SP2 no SQL Server 2014.

    Pedro, o artigo “Deferred Name Resolution”, anteriormente citado, é da época do SQL Server 2008 R2; ou seja, o comportamento de postergar (deferred) a resolução dos nomes de objetos existe bem antes da versão 2014. É um artigo curto; vale a pena a leitura atenta do mesmo. Nesse artigo fica claro que “table objects referenced by the stored procedure need not exist when the stored procedure is created, but only when it is executed”. E também alerta que “when you reference an existing table in a stored procedure you cannot list nonexistent columns for that table”.

    Além disso, esse comportamento de postergar consta na documentação do comando CREATE PROCEDURE.

    O que percebo de diferente neste tópico é a referência a objetos existentes em outro banco de dados, por causa da menção a linked server.


    e-mail       José Diz     Belo Horizonte, MG - Brasil


    José,

    É verdade você tem razão eu não me lembrava destas observações.


    Pedro Antonio Galvao Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    sexta-feira, 12 de janeiro de 2018 23:20
    Moderador
  • Justo,

    Mas você esta executando este mesmo select fazendo a chamada do linked server na sua stored procedure?


    Pedro Antonio Galvao Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    sexta-feira, 12 de janeiro de 2018 23:22
    Moderador
  • Deleted
    • Marcado como Resposta Justo_Daniel terça-feira, 23 de janeiro de 2018 17:51
    sábado, 13 de janeiro de 2018 21:46