none
Select @Error com + de um Return RRS feed

  • Pergunta

  • Olá galera eu to com uma duvida e não to conseguindo resolver...

    eu quero criar 2 if's com 2 returns de erros diferentes... exemplo:

    ALTER procedure [dbo].[TESTE](@UserNum int, @Opt int)
    AS
    BEGIN
    
    	DECLARE @RETURN int
    	DECLARE @PREMIUM_APPLY_OK int = 0x11
    	DECLARE @PREMIUMITEM_STANDBY_OK int = 0x12
    	DECLARE @ERROR int = 0x13
    	DECLARE @CharacterIdx bigint
    	DECLARE @CurrentStyle int
    	DECLARE @Name varchar(50)
    	DECLARE @Nation tinyint
    
    
    	IF(@Opt IN (1001))
    	BEGIN
    
    	-- Verifica se o Personagem esta Online
    		SELECT 
    			@CharacterIdx = CharacterIdx,
    			@CurrentStyle = Style
    		FROM SERVER01.dbo.cabal_character_table 
    		WHERE CharacterIdx/8 = @UserNum AND Login = 1
    		
    	-- Verifica se existe mais de 1 Personagem Online
    		IF @@ROWCOUNT != 1
    		BEGIN
    			GOTO CHANGE_CLASS_ERROR
    			SELECT @ERROR, 0, 0
    			RETURN;
    		END
    
    	-- Verifica se nao Existe Nenhuma Troca de Classe Ativa Na conta!
    		IF EXISTS (
    			SELECT TOP 1 * FROM SERVER01.dbo.Character_Change_Class
    			WHERE CharacterIdx = @CharacterIdx AND IsChanged = 0
    		) BEGIN
    			GOTO CHANGE_CLASS_ERROR
    			SELECT @ERROR, 0, 0
    			RETURN;
    		END
    
    	-- Insere na Tabela de Troca de Classe as Informaçoes
    		INSERT INTO SERVER01.dbo.Character_Change_Class (CharacterIdx, TargetBattleStyle, FromBattleStyle)
    		VALUES (@CharacterIdx, (@Opt - 1000), (@CurrentStyle & (POWER(2, 3) - 1)))
    
    		SELECT @PREMIUM_APPLY_OK, 0, 0
    		RETURN;
    	END
    
    	-- Config caso haja algum erro durante todo o Processo!
    	SELECT @ERROR, 0, 0
    	CHANGE_CLASS_ERROR:
    	-- Caso haja algum erro, ele retorna o item com a option para o personagem!
    		EXEC CabalCash.dbo.up_AddMyCashItemByItem @UserNum, 1, 1, 526537, @Opt, 0
    END
    
    
    --- eu gostaria de criar um outro IF exemplo:
    
    
    	IF(@Opt IN (2001))
    
    e que esse if executace um outro código de erro tipo um @ERROR2
    
    que ao invés de usar o comando
    		EXEC CabalCash.dbo.up_AddMyCashItemByItem @UserNum, 1, 1, 526537, @Opt, 0
    END
    
    com a ID 526537
    ele usaria um com a ID 426547
    
    END

    alguém sabe como eu posso fazer isso? todas as maneiras que eu tentei. toda vez que da erro no primeiro IF ele manda as IDS configuradas 

    sexta-feira, 3 de janeiro de 2020 23:51

Respostas

  • Deleted
    • Marcado como Resposta karygalock1 sábado, 4 de janeiro de 2020 19:38
    sábado, 4 de janeiro de 2020 02:14
  • "K",

    há uma falha nos blocos de tratamento de erro.

    Nas construções do tipo

    -- código #2

    1 IF condição_lógica 2 begin 3 GOTO _ERRO 4 SELECT @ERROR, 0, 0 5 RETURN 6 end; 7 _ERRO: 8 SELECT 'estou em _ERRO';


    caso condição_lógica seja verdadeira, o fluxo de processamento é desviado para o rótulo _ERRO. Ou seja, as linhas 4 e 5 jamais serão executadas.

    Em resumo, o código #2 é a mesma coisa que:

    -- código #3
    
    1  IF condição_lógica
    2    begin
    3    GOTO _ERRO
    6    end;
    
    7  _ERRO:
    8  SELECT 'estou em _ERRO';

    Assim, antes de avaliar outras questões, sugiro que primeiro identifique como deve ser cada bloco de IF.

    ok, obrigado José, vou analisar aqui e ver se consigo alterar, assim que possível ja dou um retorno!

    Kary,

    Particularmente eu não havia observado este cenário que o outro argumentador apresentou, alias, observação muito oportuna e extremamente válida.

    Estes desvios para os rótulos realmente são necessários? O comando GOTO é algo bem antigo, presente em desde as linguagens de programação para ambiente MS-DOS, como já destacado COBOL, mas também muito utilizada pelo bom e velho BASIC utilizada por Bill Gates.

    Sinceramente falando eu nunca utilizei no SQL Server, pois acredito ser uma técnica que acaba sobrecarregando o processo ou transação em execução, prefiro fazer uso de forma condição e bem aplicado do IF, como você esta tentando fazer.

    Eu pensaria na possibilidade de remover estes desvios e aplicar em seu lugar mensagens de retorno ao usuário ou até mesmo o encerramento da Stored Procedure.

    Avalie por gentileza esta possibilidade.

    Um outro ponto que gostaria de apresentar em relação ao seu código se relaciona a declaração das variávies:

    DECLARE @PREMIUM_APPLY_OK int = 0x11
    DECLARE
    @PREMIUMITEM_STANDBY_OK int = 0x12

    1 - Por que você esta declarando variáveis do tipo Int mas passando valores em Hexadecimal?

    2 - Existe algum motivo em especial? Não seria mais indicado já passar o valor inteiro? 

    Indiretamente ao realizar o procedimento de apresentar os valores existentes nas respectivas variáveis ou fazer uma análise condição o SQL Server terá que realizar uma conversão implícita, identificando o valor hexa e convertendo para int. Isso em alguns casos acaba impactando no custo de processamento ou até mesmo forçando o SQL Server a ter que mudar o respectivo plano de execução.

    Veja a imagem abaixo:

    Você poderia analisar este trecho também?


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





    • Editado Junior Galvão - MVPMVP sábado, 4 de janeiro de 2020 19:33 Havia escrito que a Linguagem Basic foi criado por Bill Gates, esta errado, ele utilizou a linguagem, cometi um erro de digitação.
    • Marcado como Resposta karygalock1 sábado, 4 de janeiro de 2020 19:39
    sábado, 4 de janeiro de 2020 13:46
  • Deleted
    • Marcado como Resposta karygalock1 sábado, 4 de janeiro de 2020 23:07
    sábado, 4 de janeiro de 2020 21:48

Todas as Respostas

  • Deleted
    sábado, 4 de janeiro de 2020 01:13
  • Kary,

    Você se refere ao uso de IFs aninhados? 

    Se for algo similar ao exemplo abaixo extraído da documentação oficial Microsoft do operador lógico condicional IF:

    DECLARE @Number int;  
    SET @Number = 50;  
    IF @Number > 100  
       PRINT 'The number is large.';  
    ELSE   
       BEGIN  
          IF @Number < 10  
          PRINT 'The number is small.';  
       ELSE  
          PRINT 'The number is medium.';  
       END ;  
    GO  

    Podemos tentar fazer da seguinte forma na sua Stored Procedure:

    ALTER procedure [dbo].[TESTE](@UserNum int, @Opt int) AS BEGIN DECLARE @RETURN int DECLARE @PREMIUM_APPLY_OK int = 0x11 DECLARE @PREMIUMITEM_STANDBY_OK int = 0x12 DECLARE @ERROR int = 0x13 DECLARE @CharacterIdx bigint DECLARE @CurrentStyle int DECLARE @Name varchar(50) DECLARE @Nation tinyint IF(@Opt IN (1001)) BEGIN -- Verifica se o Personagem esta Online SELECT @CharacterIdx = CharacterIdx, @CurrentStyle = Style FROM SERVER01.dbo.cabal_character_table WHERE CharacterIdx/8 = @UserNum AND Login = 1 -- Verifica se existe mais de 1 Personagem Online IF @@ROWCOUNT != 1 BEGIN GOTO CHANGE_CLASS_ERROR SELECT @ERROR, 0, 0 RETURN; END -- Verifica se nao Existe Nenhuma Troca de Classe Ativa Na conta! IF EXISTS ( SELECT TOP 1 * FROM SERVER01.dbo.Character_Change_Class WHERE CharacterIdx = @CharacterIdx AND IsChanged = 0 ) BEGIN GOTO CHANGE_CLASS_ERROR SELECT @ERROR, 0, 0 RETURN; END -- Insere na Tabela de Troca de Classe as Informaçoes INSERT INTO SERVER01.dbo.Character_Change_Class (CharacterIdx, TargetBattleStyle, FromBattleStyle) VALUES (@CharacterIdx, (@Opt - 1000), (@CurrentStyle & (POWER(2, 3) - 1))) SELECT @PREMIUM_APPLY_OK, 0, 0 RETURN; END -- Config caso haja algum erro durante todo o Processo! SELECT @ERROR, 0, 0 CHANGE_CLASS_ERROR: -- Caso haja algum erro, ele retorna o item com a option para o personagem! EXEC CabalCash.dbo.up_AddMyCashItemByItem @UserNum, 1, 1, 526537, @Opt, 0 END --- eu gostaria de criar um outro IF exemplo: IF(@Opt IN (2001)) Begin EXEC CabalCash.dbo.up_AddMyCashItemByItem @UserNum, 1, 1, 526537, @Opt, 0
    End
    Else
    Begin

    If (@opt In (2002)) EXEC CabalCash.dbo.up_AddMyCashItemByItem @UserNum, 1, 1, 426547, @Opt, 0 Else Return 0 End END

    Ou implementando os IFs separados:

    ALTER procedure [dbo].[TESTE](@UserNum int, @Opt int)
    AS
    BEGIN
    
    	DECLARE @RETURN int
    	DECLARE @PREMIUM_APPLY_OK int = 0x11
    	DECLARE @PREMIUMITEM_STANDBY_OK int = 0x12
    	DECLARE @ERROR int = 0x13
    	DECLARE @CharacterIdx bigint
    	DECLARE @CurrentStyle int
    	DECLARE @Name varchar(50)
    	DECLARE @Nation tinyint
    
    
    	IF(@Opt IN (1001))
    	BEGIN
    
    	-- Verifica se o Personagem esta Online
    		SELECT 
    			@CharacterIdx = CharacterIdx,
    			@CurrentStyle = Style
    		FROM SERVER01.dbo.cabal_character_table 
    		WHERE CharacterIdx/8 = @UserNum AND Login = 1
    		
    	-- Verifica se existe mais de 1 Personagem Online
    		IF @@ROWCOUNT != 1
    		BEGIN
    			GOTO CHANGE_CLASS_ERROR
    			SELECT @ERROR, 0, 0
    			RETURN;
    		END
    
    	-- Verifica se nao Existe Nenhuma Troca de Classe Ativa Na conta!
    		IF EXISTS (
    			SELECT TOP 1 * FROM SERVER01.dbo.Character_Change_Class
    			WHERE CharacterIdx = @CharacterIdx AND IsChanged = 0
    		) BEGIN
    			GOTO CHANGE_CLASS_ERROR
    			SELECT @ERROR, 0, 0
    			RETURN;
    		END
    
    	-- Insere na Tabela de Troca de Classe as Informaçoes
    		INSERT INTO SERVER01.dbo.Character_Change_Class (CharacterIdx, TargetBattleStyle, FromBattleStyle)
    		VALUES (@CharacterIdx, (@Opt - 1000), (@CurrentStyle & (POWER(2, 3) - 1)))
    
    		SELECT @PREMIUM_APPLY_OK, 0, 0
    		RETURN;
    	END
    
    	-- Config caso haja algum erro durante todo o Processo!
    	SELECT @ERROR, 0, 0
    	CHANGE_CLASS_ERROR:
    	-- Caso haja algum erro, ele retorna o item com a option para o personagem!
    		EXEC CabalCash.dbo.up_AddMyCashItemByItem @UserNum, 1, 1, 526537, @Opt, 0
    END
    
    
    --- eu gostaria de criar um outro IF exemplo:
    IF(@Opt IN (2001))
     EXEC CabalCash.dbo.up_AddMyCashItemByItem @UserNum, 1, 1, 526537, @Opt, 0
      
    If (@opt In (2002))
     EXEC CabalCash.dbo.up_AddMyCashItemByItem @UserNum, 1, 1, 426547, @Opt, 0
    
    END

    Não testei, pode contar erros, utilizei a mesma estrutura de código que você esta postando.


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

    sábado, 4 de janeiro de 2020 01:15
  • essa questão dos ifs eu entendi, na verdade eu acho que eu me expliquei mal, vou tentar explicar novamente.

    toda vez que eu uso o

    IF(@Opt IN (1001))

    ele executa uma serie de comandos como listado acima

    1 deles insere em 1 tabela especifica do sql 1 linha. cujo qual ela tem uma coluna chamada "ischanged" e esse valor é default 0
    oque acontece, caso esse IF seja executado novamente com esse valor ainda em 0
    ele da um erro.

    esse erro é o 

    	GOTO CHANGE_CLASS_ERROR
    	SELECT @ERROR, 0, 0
    	RETURN;
    
    
    	SELECT @ERROR, 0, 0
    	CHANGE_CLASS_ERROR:
    EXEC CabalCash.dbo.up_AddMyCashItemByItem @UserNum, 1, 1, 526537, @Opt, 
    que nada mais nada menos, retorna 1 item especifico com a @opt que foi utilizada...
    ou seja é um sistema pra nao usar 2x o mesmo comando sem terminar toda a execuçao do primeiro

    eu queria criar um segundo IF que caso gere esse erro ele nao retorne o código acima e sim um segundo Select @error 

    acho que agora ficou melhor a explicaçao


    sábado, 4 de janeiro de 2020 01:47
  • Deleted
    • Marcado como Resposta karygalock1 sábado, 4 de janeiro de 2020 19:38
    sábado, 4 de janeiro de 2020 02:14
  • "K",

    há uma falha nos blocos de tratamento de erro.

    Nas construções do tipo

    -- código #2

    1 IF condição_lógica 2 begin 3 GOTO _ERRO 4 SELECT @ERROR, 0, 0 5 RETURN 6 end; 7 _ERRO: 8 SELECT 'estou em _ERRO';


    caso condição_lógica seja verdadeira, o fluxo de processamento é desviado para o rótulo _ERRO. Ou seja, as linhas 4 e 5 jamais serão executadas.

    Em resumo, o código #2 é a mesma coisa que:

    -- código #3
    
    1  IF condição_lógica
    2    begin
    3    GOTO _ERRO
    6    end;
    
    7  _ERRO:
    8  SELECT 'estou em _ERRO';

    Assim, antes de avaliar outras questões, sugiro que primeiro identifique como deve ser cada bloco de IF.

    ok, obrigado José, vou analisar aqui e ver se consigo alterar, assim que possível ja dou um retorno!
    sábado, 4 de janeiro de 2020 02:27
  • "K",

    há uma falha nos blocos de tratamento de erro.

    Nas construções do tipo

    -- código #2

    1 IF condição_lógica 2 begin 3 GOTO _ERRO 4 SELECT @ERROR, 0, 0 5 RETURN 6 end; 7 _ERRO: 8 SELECT 'estou em _ERRO';


    caso condição_lógica seja verdadeira, o fluxo de processamento é desviado para o rótulo _ERRO. Ou seja, as linhas 4 e 5 jamais serão executadas.

    Em resumo, o código #2 é a mesma coisa que:

    -- código #3
    
    1  IF condição_lógica
    2    begin
    3    GOTO _ERRO
    6    end;
    
    7  _ERRO:
    8  SELECT 'estou em _ERRO';

    Assim, antes de avaliar outras questões, sugiro que primeiro identifique como deve ser cada bloco de IF.

    ok, obrigado José, vou analisar aqui e ver se consigo alterar, assim que possível ja dou um retorno!

    Kary,

    Particularmente eu não havia observado este cenário que o outro argumentador apresentou, alias, observação muito oportuna e extremamente válida.

    Estes desvios para os rótulos realmente são necessários? O comando GOTO é algo bem antigo, presente em desde as linguagens de programação para ambiente MS-DOS, como já destacado COBOL, mas também muito utilizada pelo bom e velho BASIC utilizada por Bill Gates.

    Sinceramente falando eu nunca utilizei no SQL Server, pois acredito ser uma técnica que acaba sobrecarregando o processo ou transação em execução, prefiro fazer uso de forma condição e bem aplicado do IF, como você esta tentando fazer.

    Eu pensaria na possibilidade de remover estes desvios e aplicar em seu lugar mensagens de retorno ao usuário ou até mesmo o encerramento da Stored Procedure.

    Avalie por gentileza esta possibilidade.

    Um outro ponto que gostaria de apresentar em relação ao seu código se relaciona a declaração das variávies:

    DECLARE @PREMIUM_APPLY_OK int = 0x11
    DECLARE
    @PREMIUMITEM_STANDBY_OK int = 0x12

    1 - Por que você esta declarando variáveis do tipo Int mas passando valores em Hexadecimal?

    2 - Existe algum motivo em especial? Não seria mais indicado já passar o valor inteiro? 

    Indiretamente ao realizar o procedimento de apresentar os valores existentes nas respectivas variáveis ou fazer uma análise condição o SQL Server terá que realizar uma conversão implícita, identificando o valor hexa e convertendo para int. Isso em alguns casos acaba impactando no custo de processamento ou até mesmo forçando o SQL Server a ter que mudar o respectivo plano de execução.

    Veja a imagem abaixo:

    Você poderia analisar este trecho também?


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





    • Editado Junior Galvão - MVPMVP sábado, 4 de janeiro de 2020 19:33 Havia escrito que a Linguagem Basic foi criado por Bill Gates, esta errado, ele utilizou a linguagem, cometi um erro de digitação.
    • Marcado como Resposta karygalock1 sábado, 4 de janeiro de 2020 19:39
    sábado, 4 de janeiro de 2020 13:46
  • Deleted
    sábado, 4 de janeiro de 2020 14:29
  • Um outro ponto que gostaria de apresentar em relação ao seu código se relaciona a declaração das variávies:

    DECLARE @PREMIUM_APPLY_OK int = 0x11
    DECLARE
    @PREMIUMITEM_STANDBY_OK int = 0x12

    1 - Por que você esta declarando variáveis do tipo Int mas passando valores em Hexadecimal?

    2 - Existe algum motivo em especial? Não seria mais indicado já passar o valor inteiro? 

    Indiretamente ao realizar o procedimento de apresentar os valores existentes nas respectivas variáveis ou fazer uma análise condição o SQL Server terá que realizar uma conversão implícita, identificando o valor hexa e convertendo para int. Isso em alguns casos acaba impactando no custo de processamento ou até mesmo forçando o SQL Server a ter que mudar o respectivo plano de execução.

    Veja a imagem abaixo:

    Você poderia analisar este trecho também?


    Bom, na verdade Junior é bem simples, eu declaro a funçao como INT e coloco valores em hexadecimal pois essa procedure especifica é executada através de um "item" dentro do jogo e como o jogo só trabalha em hexadecimal e linguagem  assembly infelizmente existe algumas limitações ou melhor dizendo alguns obstáculos a serem superados devido a isso quando o item é usado ele executa um valor em hexa (valor declarado ali) e como esse valor é = a declaração int que eu fiz, funciona perfeitamente sem nenhum erro. se eu usar simplesmente um numero decimal padrão, eu teria que utilizar um código muito maior pra chegar no valor exato que eu preciso!
    sábado, 4 de janeiro de 2020 18:02
  • bom, na verdade eu descobri o erro que estava causando a leitura incorreta do comando GOTO e independente do if ele sempre lia o GOTO errado.

    -- tinha o comando if qualquer no código
    
    IF(Valor)
    Begin
    
    --comando qualquer para execuçao
     insert into tabela_name (valor, valor1)
     valus (@valor, @valor1)
    
    -- ai vamos supor que vinha o comando goto
    
    		BEGIN
    			GOTO CHANGE_CLASS_ERROR
    			SELECT @ERROR, 0, 0
    			RETURN;
    		END
    
    
    END
    
    -- ai no fim do código eu colocava o result digamos assim
    
    
    	CHANGE_CLASS_ERROR:
    EXEC CabalCash.dbo.up_AddMyCashItemByItem @UserNum, 1, 1, 526537, @Opt, 0

    oque acontecia era o seguinte, que indiferente do if que eu criava ele sempre lia o "change_class_error" nao importa se eu criasse outros 10 diferentes... ai analisando com calma eu tentei uma solução simples e funcional

    IF(Valor)
    Begin
    
    --comando qualquer para execuçao
     insert into tabela_name (valor, valor1)
     valus (@valor, @valor1)
    
    -- ai vamos supor que vinha o comando goto
    
    		BEGIN
    			GOTO CHANGE_CLASS_ERROR
    			SELECT @ERROR, 0, 0
    			RETURN;
    		END
    
    
    	CHANGE_CLASS_ERROR:
    EXEC CabalCash.dbo.up_AddMyCashItemByItem @UserNum, 1, 1, 526537, @Opt, 0
    
    END;

    ou seja, ao invés de colocar no fim do código, eu coloquei antes do ultimo END do if... e adivinha? funcionou perfeitamente. eu posso criar 10 IF's diferentes. só alterando o comando "goto change_class_error" pra qualquer outro vamos supor. "goto change_lvl_error" e funciona perfeitamente, cada if com seu próprio comando de erro!.....

    EDIT:
    devido algumas dicas do José e do Junior eu fiz umas alterações no comando GOTO, porém ainda continuo usando ele devido a facilidade que eu encontrei nesse comando, como vocês devem lembrar eu sou muito novo nesse mundo do SQL, então eu leio, aprendo e tento executar as coisas de forma funcional e melhora-las conforme vou aprimorando esse conhecimento! 

    enfim, pode dar close no tópico pois a duvida ja foi resolvida, obrigado a todos +1 vez :D 


    • Editado karygalock1 sábado, 4 de janeiro de 2020 18:16
    sábado, 4 de janeiro de 2020 18:13
  • Um outro ponto que gostaria de apresentar em relação ao seu código se relaciona a declaração das variávies:

    DECLARE @PREMIUM_APPLY_OK int = 0x11
    DECLARE
    @PREMIUMITEM_STANDBY_OK int = 0x12

    1 - Por que você esta declarando variáveis do tipo Int mas passando valores em Hexadecimal?

    2 - Existe algum motivo em especial? Não seria mais indicado já passar o valor inteiro? 

    Indiretamente ao realizar o procedimento de apresentar os valores existentes nas respectivas variáveis ou fazer uma análise condição o SQL Server terá que realizar uma conversão implícita, identificando o valor hexa e convertendo para int. Isso em alguns casos acaba impactando no custo de processamento ou até mesmo forçando o SQL Server a ter que mudar o respectivo plano de execução.

    Veja a imagem abaixo:

    Você poderia analisar este trecho também?


    Bom, na verdade Junior é bem simples, eu declaro a funçao como INT e coloco valores em hexadecimal pois essa procedure especifica é executada através de um "item" dentro do jogo e como o jogo só trabalha em hexadecimal e linguagem  assembly infelizmente existe algumas limitações ou melhor dizendo alguns obstáculos a serem superados devido a isso quando o item é usado ele executa um valor em hexa (valor declarado ali) e como esse valor é = a declaração int que eu fiz, funciona perfeitamente sem nenhum erro. se eu usar simplesmente um numero decimal padrão, eu teria que utilizar um código muito maior pra chegar no valor exato que eu preciso!

    Kary,

    Ok, entendi, perfeito, obrigado pelo retorno.


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

    sábado, 4 de janeiro de 2020 18:46
  • Para garantir a correção das informações publicadas nestes fóruns, a respeito de

    deve-se esclarecer que não foi Bill Gates quem criou o Basic, pois utilizei Basic no CP/M e a linguagem Basic já existia bem antes disso. Sugestão de leitura: BASIC.

    Quando ao GOTO, ele não sobrecarrega "o processo ou transação em execução". Aliás, construções IF/THEN/ELSE (e algumas outras) são geralmente implementadas como sequências de GOTO.

    A questão de evitar o uso de instruções GO TO, independente de linguagem, vem da programação estruturada e Dijkstra, existindo inclusive a expressão código espaguete para códigos-fonte mal estruturados, cheios de desvios.


    José Diz     Belo Horizonte, MG - Brasil     [query performance tuning: Porto SQL]


    Este conteúdo é fornecido sem garantias de qualquer tipo, seja expressa ou implícita.

    José,

    Você esta certo, BASIC não foi criado por Bill Gates, eu acabei errando, fui escrever utilizada e acabei digitando criado, muito obrigado.

    Eu utilizei BASIC entre 1994 e 1997, em ambientes 386 e 486! Não tive oportunidade quanto você, pois tenho uma boa diferença de idade.

    Em relação ao uso GOTO, conheço os conceitos de linguagem estruturada, bem como, esta definição de código espaguete, quando eu me refiro a sobrecarga, você como um conhecedor de BASIC sabe muito bem que os desvios de código acabavam sim impactando no processamento, era isso que eu estava querendo dizer.

    Em suma, estou compartilhando a minha experiência, independente do que se trata ou se refira na documentação.

    Pois bem, parece que vamos continuar mesma batalha vivida em 2019, eu tento contribuir e você continua criando motivos para fazer este tipo de exposição.

    O que você quer? Quer ser dono deste fórum? Você também erra, mas a diferença que eu não me preocupo em contradizer o que você expressa aqui.


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



    sábado, 4 de janeiro de 2020 18:53
  • Kary,

    Por gentileza, por questões de controle e melhor evidência da(s) resposta(s) que podem ser consideradas corretas, peço que você marque aquela ou aquelas que entender como correta.



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

    sábado, 4 de janeiro de 2020 18:57
  • Kary,

    Por gentileza, por questões de controle e melhor evidência da(s) resposta(s) que podem ser consideradas corretas, peço que você marque aquela ou aquelas que entender como correta.


    foi mal, eu estava só marcando como voto, ja marquei as respostas! sorry
    sábado, 4 de janeiro de 2020 19:39
  • Deleted
    • Marcado como Resposta karygalock1 sábado, 4 de janeiro de 2020 23:07
    sábado, 4 de janeiro de 2020 21:48
  • (...) ou seja, ao invés de colocar no fim do código, eu coloquei antes do ultimo END do if... e adivinha? funcionou perfeitamente.

    Ok.

    Dessa forma o rótulo ficou dentro do bloco iniciado por
         IF(@Opt IN (1001))

    ---

    "K", somente fique atento que nos exemplos que postei as instruções que estão imediatamente após o GOTO não são executadas. No caso do código #2 as instruções das linhas 4 e 5 são inoperantes; jamais serão executadas. Se elas não são mais necessárias, basta retirá-las, o que inclusive simplificará o seu código SQL.

    Por exemplo, o seguinte trecho

    ...
    	-- Verifica se existe mais de 1 Personagem Online
    		IF @@ROWCOUNT != 1
    		BEGIN
    			GOTO CHANGE_CLASS_ERROR
    			SELECT @ERROR, 0, 0
    			RETURN;
    		END
    ...

    é o mesmo que:

    ...
    	-- Verifica se existe mais de 1 Personagem Online
    		IF @@ROWCOUNT != 1
    			GOTO CHANGE_CLASS_ERROR;
    ...


    Obrigado José foi oque eu fiz, devido ao comentário que tu tinha feito antes e reforçou agora foi basicamente oque eu fiz, eu simplifiquei o código e removi as linhas que eram inoperantes que tu tinha comentado, assim mantendo todo o código funcional porem mais compacto e simples :D

    vlw mesmo 
    • Editado karygalock1 sábado, 4 de janeiro de 2020 23:08
    sábado, 4 de janeiro de 2020 23:06
  • Kary,

    Por gentileza, por questões de controle e melhor evidência da(s) resposta(s) que podem ser consideradas corretas, peço que você marque aquela ou aquelas que entender como correta.


    foi mal, eu estava só marcando como voto, ja marquei as respostas! sorry

    Kary,

    Sem problemas, não precisa de desculpar. Obrigado.


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

    sábado, 4 de janeiro de 2020 23:09
  • Deleted
    sábado, 4 de janeiro de 2020 23:14