Introdução aos Stored Procedures no SQL Server

Conheça melhor estas funções muito úteis para DBAs e desenvolvedores, e

acompanhe um passo-a-passo baseado no SQL Server.

Afinal o que é Stored Procedures

Neste artigo veremos um pouco sobre stored procedures, funções muito úteis para o
dia-dia de DBAs e desenvolvedores. Veremos passo a passo como criar um stored
procedure no SQL Server.
Stored Procedure, que traduzido significa Procedimento Armazenado, é uma conjunto de
comandos em SQL que podem ser executados de uma só vez, como em uma função. Ele
armazena tarefas repetitivas e aceita parâmetros de entrada para que a tarefa seja
efetuada de acordo com a necessidade individual.
Um Stored Procedure pode reduzir o tráfego na rede, melhorar a performance de um
banco de dados, criar tarefas agendadas, diminuir riscos, criar rotinas de
processsamento, etc.
Por todas estas e outras funcionalidades é que os stored procedures são de
extrema importância para os DBAs e desenvolvedores.
Há cinco tipos de procedures básicos que podemos criar:
 Procedimentos Locais - São criados a partir de um banco de dados do próprio usuário;
 Procedimentos Temporários - Existem dois tipos de procedimentos temporários: Locais,
que devem começar com # e Globais, que devem começar com ##;
 Procedimentos de Sistema - Armazenados no banco de dados padrão do SQL Server
(Master), podemos indentifica-los com as siglas sp, que se origina de stored procedure.
Tais procedures executam as tarefas administrativas e podem ser executadas a partir
de qualquer banco de dados.
 Procedimentos Remotos - Podemos usar Queries Distribuídas para tais procedures.
São utilizadas apenas para compatibilidade.
 Procedimentos Estendidos - Diferente dos procedimentos já citados, este tipo de
procedimento recebe a extensão .dll e são executadas fora do SGBD SQL Server. São
identificadas com o prefixo xp.

Quando utilizar procedures

 Quando temos várias aplicações escritas em diferentes linguagens, ou rodam em
plataformas diferentes, porém executam a mesma função.
 Quando damos prioridade à consistência e segurança.
Os bancos (Itaú, Bradesco, Real, etc), por exemplo, em geral, utilizam stored procedures
para todas as operações em comum. Os procedimentos podem assegurar que as
operações sejam registradas de forma correta e segura.

Por que é mais seguro?

Seguindo a linha de raciocínio dos bancos, utilizando stored procedures outras
aplicações e usuários não conseguiriam nenhum tipo de acesso às tabelas do
banco de dados de forma direta.
Eles poderiam apenas executar os stored procedures, que rodam ações específicas e
determinadas pelos DBAs e desenvolvedores.

Criando um stored procedure

Este é um exemplo de um stored procedure que executa uma consulta utlizando um filtro
por descrição, em uma tabela específica de nosso banco de dados.

USE BancoDados
GO
CREATE PROCEDURE Busca --- Declarando o nome da procedure
@CampoBusca VARCHAR (20) --- Declarando variável (note que
utilizamos o @ antes do nome da variável)
AS
SELECT Codigo, Descrição --- Consulta
FROM NomeTabela
WHERE Descricao = @CampoBusca --- Utilizando variável como filtro
para a consulta

Para executar uma procedure basta utiilizar a cláusula EXECUTE seguido pelo nome da

procedure e na frente o valor a ser utilizado como parâmetro Exemplo:

EXECUTE Busca 'DEVMEDIA'
O que nos retornaria o seguinte resultado:
 Fig
ura 1. Retorno do stored procedure.

Para excluir um procedure é necessário utilizar a cláusula DROP PROCEDURE como no

exemplo abaixo.
DROP PROCEDURE Busca.

Especificar parâmetros

Ao especificar parâmetros de procedimento, programas de chamada podem passar

valores para o corpo do procedimento. Esses valores podem ser usados com vários
propósitos durante a execução do procedimento. Parâmetros de procedimento também
retornam valores ao programa de chamada quando o parâmetro é marcado como um
parâmetro OUTPUT.
Um procedimento pode ter no máximo 2100 parâmetros; a cada um é atribuído um nome,
um tipo de dados e uma direção. Outra opção é atribuir valores padrão aos parâmetros.
A seção a seguir fornece informações sobre como passar valores para parâmetros e
como cada atributo de parâmetro é usado durante uma chamada de procedimento.

Passando valores para parâmetros

Os valores de parâmetros fornecidos com uma chamada de procedimento devem ser
constantes ou uma variável; um nome de função não pode ser usado como um valor de
parâmetro. As variáveis podem ser definidas pelo usuário ou pelas variáveis de sistema
como @@spid.
Os exemplos a seguir demonstram a passagem de valores de parâmetro para o
procedimento uspGetWhereUsedProductID. Eles ilustram como passar parâmetros como
constantes e variáveis e também como usar uma variável para passar o valor de uma
função.

USE AdventureWorks2012;
GO
-- Passing values as constants.
EXEC dbo.uspGetWhereUsedProductID 819, '20050225';
GO
-- Passing values as variables.
DECLARE @ProductID int, @CheckDate datetime;
SET @ProductID = 819;
SET @CheckDate = '20050225';
EXEC dbo.uspGetWhereUsedProductID @ProductID, @CheckDate;
GO
-- Try to use a function as a parameter value.
-- This produces an error message.
EXEC dbo.uspGetWhereUsedProductID 819, GETDATE();
GO
-- Passing the function value as a variable.
DECLARE @CheckDate datetime;
SET @CheckDate = GETDATE();
EXEC dbo.uspGetWhereUsedProductID 819, @CheckDate;
GO

Especificando nomes de parâmetro

Na criação de um procedimento e declaração de um nome de parâmetro, o nome de
parâmetro deve começar com um único caractere @ e deve ser exclusivo no escopo do
procedimento.
A nomeação explícita dos parâmetros e a atribuição dos valores apropriados a cada
parâmetro em uma chamada de procedimento permitem o fornecimento dos parâmetros
em qualquer ordem. Por exemplo, se o procedimento my_proc espera três parâmetros
com os nomes @first, @second e @third, os valores passados ao procedimento podem
ser atribuídos aos nomes de parâmetros, como: EXECUTE my_proc @second = 2, @first
= 1, @third = 3;
Observação
Se um valor de parâmetro for fornecido no formato @parameter = value, todos os
parâmetros subsequentes deverão ser fornecidos dessa maneira. Se os valores de
parâmetros não forem passados no formato @parameter = value, os valores deverão ser
fornecidos na mesma ordem (da esquerda para a direita) em que os parâmetros serão
listados na instrução CREATE PROCEDURE.
Aviso
Qualquer parâmetro passado no formato @parameter = value, com o parâmetro digitado
incorretamente, fará com que o SQL Server gere um erro e impedirá a execução do
procedimento.

Especificando tipos de dados de parâmetros

Parâmetros devem ser definidos com um tipo de dados quando são declarados em uma
instrução CREATE PROCEDURE. O tipo de dados de um parâmetro determina o tipo e o
intervalo dos valores aceitos pelo parâmetro quando o procedimento é chamado. Por
exemplo, se você definir um parâmetro com um tipo de dados tinyint , somente valores
numéricos no intervalo entre 0 e 255 serão aceitos quando passados para esse
parâmetro. Um erro será retornado se um procedimento for executado com um valor
incompatível com o tipo de dados.

Especificando valores padrão de parâmetro

Um parâmetro é considerado opcional se o parâmetro tem um valor padrão especificado
quando é declarado. Não é necessário fornecer um valor para um parâmetro opcional em
uma chamada de procedimento.
O valor padrão de um parâmetro é usado quando:

 Nenhum valor é especificado para o parâmetro na chamada do procedimento.

 A palavra-chave DEFAULT é especificada como o valor na chamada do procedimento.

Observação
Se o valor padrão for uma cadeia de caracteres contendo pontuação ou espaços em
branco inseridos, ou caso ela comece com um número (por exemplo, 6xxx), ela deverá
ser colocada entre aspas simples.
Observação
Não há suporte para parâmetros padrão no SQL Data Warehouse do Azure ou no Parallel
Data Warehouse.
Se nenhum valor puder ser especificado adequadamente como um padrão para o
parâmetro, especifique NULL como o padrão. Convém levar o procedimento a retornar
uma mensagem personalizada se ele for executado sem um valor para o parâmetro.
O exemplo a seguir cria o procedimento armazenado uspGetSalesYTD com um
parâmetro de entrada, @SalesPerson. NULL será atribuído como valor padrão para o
parâmetro e será utilizado em instruções de tratamento de erros para retornar uma
mensagem de erro personalizada nos casos de execução do procedimento sem um valor
para o parâmetro @SalesPerson .

USE AdventureWorks2012;
GO
IF OBJECT_ID('Sales.uspGetSalesYTD', 'P') IS NOT NULL
DROP PROCEDURE Sales.uspGetSalesYTD;
GO
CREATE PROCEDURE Sales.uspGetSalesYTD
@SalesPerson nvarchar(50) = NULL -- NULL default value
AS
SET NOCOUNT ON;

-- Validate the @SalesPerson parameter.

IF @SalesPerson IS NULL
BEGIN
PRINT 'ERROR: You must specify the last name of the sales
person.'
RETURN
END
-- Get the sales for the specified sales person and
-- assign it to the output parameter.
SELECT SalesYTD
FROM Sales.SalesPerson AS sp
JOIN HumanResources.vEmployee AS e ON e.BusinessEntityID =
sp.BusinessEntityID
WHERE LastName = @SalesPerson;
RETURN
GO

O exemplo a seguir executa o procedimento. A primeira instrução executa o procedimento

sem especificar um valor de entrada. Isso leva as instruções de tratamento de erros no
procedimento a retornarem a mensagem de erro personalizada. A segunda instrução
fornece um valor de entrada e retorna o conjunto de resultados esperado.
-- Run the procedure without specifying an input value.
EXEC Sales.uspGetSalesYTD;
GO
-- Run the procedure with an input value.
EXEC Sales.uspGetSalesYTD N'Blythe';
GO
Embora seja possível omitir os parâmetros para os quais foram fornecidos padrões, a lista
de parâmetros só poderá ser truncada. Por exemplo, se um procedimento tiver cinco
parâmetros, o quarto e o quinto parâmetros poderão ser omitidos. Entretanto, o quarto
parâmetro não poderá ser ignorado desde que o quinto parâmetro seja incluído, a menos
que os parâmetros sejam fornecidos no formato @parameter = value.

Especificando a direção do parâmetro

A direção de um parâmetro é de entrada, em que um valor é passado para o corpo do
procedimento armazenado, ou de saída, em que o procedimento retorna um valor ao
programa de chamada. O padrão é um parâmetro de entrada.
Para especificar um parâmetro de saída, especifique a palavra-chave OUTPUT na
definição do parâmetro na instrução CREATE PROCEDURE. O procedimento retorna o
valor atual do parâmetro de saída ao programa de chamada quando o procedimento
existe. O programa de chamada também deve usar a palavra-chave OUTPUT ao executar
o procedimento a fim de salvar o valor do parâmetro em uma variável que pode ser usada
no programa de chamada.
O exemplo a seguir cria o procedimento Production.usp_GetList, que retorna uma lista de
produtos com preços que não excedem uma quantia especificada. O exemplo mostra o
uso de várias instruções SELECT e vários parâmetros OUTPUT. Os parâmetros OUTPUT
permitem que um procedimento externo, um lote ou mais de uma instrução Transact-SQL
acessem um valor definido durante a execução do procedimento.
USE AdventureWorks2012;
GO
IF OBJECT_ID ( 'Production.uspGetList', 'P' ) IS NOT NULL
DROP PROCEDURE Production.uspGetList;
GO
CREATE PROCEDURE Production.uspGetList @Product varchar(40)
, @MaxPrice money
, @ComparePrice money OUTPUT
, @ListPrice money OUT
AS
SET NOCOUNT ON;
SELECT p.[Name] AS Product, p.ListPrice AS 'List Price'
FROM Production.Product AS p
JOIN Production.ProductSubcategory AS s
ON p.ProductSubcategoryID = s.ProductSubcategoryID
 WHERE s.[Name] LIKE @Product AND p.ListPrice < @MaxPrice;
-- Populate the output variable @ListPprice.
SET @ListPrice = (SELECT MAX(p.ListPrice)
FROM Production.Product AS p
JOIN Production.ProductSubcategory AS s
ON p.ProductSubcategoryID = s.ProductSubcategoryID
WHERE s.[Name] LIKE @Product AND p.ListPrice < @MaxPrice);
-- Populate the output variable @compareprice.
SET @ComparePrice = @MaxPrice;
GO

Execute usp_GetList para retornar uma lista de produtos (bicicletas) da Adventure Works
que custam menos que $ 700. Os parâmetros OUTPUT @cost e @compareprices são
usados com linguagem de controle de fluxo para retornar uma mensagem na janela
Mensagens.
Observação
A variável OUTPUT deve ser definida durante a criação do procedimento e também
durante o uso da variável. O nome de parâmetro e o nome de variável não precisam
coincidir. Porém, o tipo de dados e o posicionamento do parâmetro precisam ser
correspondentes (a menos que @listprice= variable seja usado).
DECLARE @ComparePrice money, @Cost money ;
EXECUTE Production.uspGetList '%Bikes%', 700,
@ComparePrice OUT,
@Cost OUTPUT
IF @Cost <= @ComparePrice
BEGIN
PRINT 'These products can be purchased for less than
 $'+RTRIM(CAST(@ComparePrice AS varchar(20)))+'.'
END
ELSE
PRINT 'The prices for all products in this category exceed
$'+ RTRIM(CAST(@ComparePrice AS varchar(20)))+'.';

Este é o conjunto de resultados parcial:

Product List Price
-------------------------------------------------- ------------------
Road-750 Black, 58 539.99
Mountain-500 Silver, 40 564.99
Mountain-500 Silver, 42 564.99
...
Road-750 Black, 48 539.99
Road-750 Black, 52 539.99

(14 row(s) affected)

These items can be purchased for less than $700.00.

Exemplos de Stored Procedure MS SQL Server

Consulta sem passagem de parâmetro
-- ============================================================
-- Author    : Antonio Azevedo
-- Create date: 22/08/2016
-- Description: Select alunos classificados por nome
-- ============================================================
Create PROCEDURE [dbo].[pcdAluno_Slc]
AS
BEGIN
     
    select a.idaluno, a.nome, a.email, a.dtcadastro, a.valor,
           c.idcurso, descricao_curso = c.descricao 
    from alunos a
        inner join cursos c on c.idcurso = a.idcurso
        order by a.nome
             
END
GO
Consulta com passagem de parâmetro
-- ============================================================
-- Author    : Antonio Azevedo
-- Create date: 22/08/2016
-- Description: Select alunos por ID
-- ============================================================
Create PROCEDURE [dbo].[pcdAluno_SlcID]
@idaluno               INT
AS
BEGIN
     
    select a.idaluno, a.nome, a.email, a.dtcadastro, a.valor,
           c.idcurso, descricao_curso = c.descricao 
    from alunos a
        inner join cursos c on c.idcurso = a.idcurso
        where idaluno = @idaluno
         
END
GO
Insert com retorno do Id Criado
O comando @@IDENTITY executado antes de finalizar a conexão retorna o numero do ultimo id criado.
-- ============================================================
-- Author    : Antonio Azevedo
-- Create date: 22/08/2016
-- Description: Incluir Alunos e retornar o ID no novo registro
-- ============================================================
Create PROCEDURE [dbo].[pcdAluno_Ins]
@idcurso               INT,
@nome                  VARCHAR(100),
@email                 VARCHAR(100),
@dtcadastro            DATETIME = NULL,
@valor                 DECIMAL(15,2) = NULL
AS
BEGIN
     
    INSERT INTO alunos (idcurso, nome, email, dtcadastro, valor)
                       VALUES  (@idcurso, @nome, @email, @dtcadastro, @valor)
     
    SELECT CONVERT(INT,@@IDENTITY) as retorno
         
END
GO
Update com passagem de parâmetros
-- ===========================================
-- Author    : Antonio Azevedo
-- Create date: 22/08/2016
-- Description: Altera Alunos
-- ===========================================
Create PROCEDURE [dbo].[pcdAluno_Upd]
@idaluno               INT,
@idcurso               INT,
@nome                  VARCHAR(100),
@email                 VARCHAR(100),
@dtcadastro            DATETIME = NULL,
@valor                 DECIMAL(15,2) = NULL
AS
BEGIN
     
    UPDATE alunos set idcurso = @idcurso, nome = @nome, email = @email, dtcadastro = @dtcadastro, valor =
@valor
    where idaluno = @idaluno   
     
END
GO
Delete com passagem de parâmetros
-- ===========================================
-- Author    : Antonio Azevedo
-- Create date: 22/08/2016
-- Description: Altera Alunos
-- ===========================================
Create PROCEDURE [dbo].[pcdAluno_Del]
@idaluno               INT
AS
BEGIN
     
    DELETE alunos where idaluno = @idaluno 

END
GO
Update/Delete com INNER em MS-SQL Server
Autor : Antonio Carlos Ferreira de Azevedo Postado em : 21/07/2018

O segredo para fazermos um UPDATE ou DELETE com um INNER em uma outra tabela é utilizarmos a clausula
FROM, para que possamos relacionar as tabelas.
Segue exemplos abaixo:
-- update
UPDATE tblclientes SET idcidade = ende .idcidade
      FROM tblclientes cli
      INNER JOIN tblendereco ende ON ende.idendereco = cli.idendereco

-- delete
DELETE tblclientes 
      FROM tblclientes cli
      INNER JOIN tblendereco ende ON ende.idendereco = cli.idendereco
Criando Tabelas Temporarias em MS-SQL
São criada em TempDB podendo ser classificadas em Locais e Globais, os principais tipos são:
 Locais, utilizam o prefixo '@', são como matrizes e ficam restritas ao escopo local de uma rotina, como uma
variavel local comum.
 Locais, utilizam o prefixo '#' e possuem visibilidade restrita a conexão responsável por sua criação, outras conexòes
não encergam esta tabela e dasaparecem quando nenhuma conexão as usam.
 Globais, Temporarias são criadas com o prefixo '##' e são visíveis por todas as conexôes, são adicionadas no log.
Para criar uma tabela temporária utilizamos o comando CREATE TABLE e para apagar o comando DROP TABLE,
assim como faríamos para criar uma tabela normal.
Segue exemplo para criação de uma tabela temporaria:
CREATE TABLE tempdb.dbo.#temp
    ( 
         id INT,
         depto VARCHAR(100) COLLATE Latin1_General_CI_AS,
         cargo VARCHAR(80) COLLATE Latin1_General_CI_AS    
    )
Para verificar se a tabela ainda existe e aparga-la utilize o seguinte comando:
IF OBJECT_ID('tempdb.dbo.#temp', 'U') IS NOT NULL
BEGIN
    DROP TABLE #temp
END   
Para manipular a tabela utilize os comandos normalmente:
-- select
SELECT * FROM #temp tmp
    INNER JOIN tblclientes cli ON cli.idproduto = tmp.id

-- delete
DELETE #temp WHERE id = 2035

-- update
UPDATE #temp set cargo = 'Diretor' WHERE id = 2035
Trabalhando com Cursores em MS-SQL Server.
Autor : Antonio Carlos Ferreira de Azevedo Postado em : 21/08/2018

Quando estamos trabalhando com STORED PROCEDURES, muitas vezes temos a necessidade de fazer uma leitura e
processar seus registros lendo linha a linha até o final da tabela. Vamos lá entender como podemos fazer esta operação
em MS-Sql.

Para evitar erros quando estamos trabalhando com diversos cursores podemos executar a seguinte função para verificar
se o cursor esta aberto e se sim executar o procedimento para fechar (CLOSE) e liberar a memoria (DEALLOCATE),
conforme o exemplo abaixo:
IF (CURSOR_STATUS('global','curr')>=-1)
BEGIN
      CLOSE curr
      DEALLOCATE curr
END
O próximo passo é declarar nosso cursor
DECLARE curr
CURSOR FOR
Agora vamos carregar os dados e abrir nosso cursor, abaixo temos o exemplo de um SELECT, declarando as variaveis e
carregando os dados no cursor com o comando FETCH:
-- Select
SELECT id, nome, idgrupo FROM tblclientes c WHERE c.idgrupo > 0

-- Declarando as variáveis para carregar os dados

DECLARE @id INT
DECLARE @nome VARCHAR(50)
DECLARE @idgrupo INT

-- Abrindo o Cursor
OPEN curr

-- Posiciona os dados do registro atribuindo as variáveis

FETCH NEXT FROM curr INTO @id, @nome, @idgrupo
em seguida faremos o LOOP de leitura de nosso de nossos dados utilizando o cursor:
-- While
WHILE @@FETCH_STATUS = 0
BEGIN
     
   -- faça o tratamento dos dados aqui....
       
   UPDATE tblclientes SET soma = soma + 1 WHERE id = @id

   -- Movimenta o ponteiro dos dados para o próximo registro e carrega as variáveis
   FETCH NEXT FROM curr INTO @id, @nome, @idgrupo

END
Após finalizarmos nosso LOOP de leitura e tratamento dos dados fechamos nosso cursor e liberamos a memoria:
CLOSE curr
DEALLOCATE curr

Nossa estrutura completa completa ficaria assim:

IF (CURSOR_STATUS('global','curr')>=-1)
BEGIN
      CLOSE curr
      DEALLOCATE curr
END

DECLARE curr
CURSOR FOR

-- Select
SELECT id, nome, idgrupo FROM tblclientes c
    WHERE c.idgrupo > 0

-- Declarando as variáveis para carregar os dados

DECLARE @id INT
DECLARE @nome VARCHAR(50)
DECLARE @idgrupo INT

-- Abrindo o Cursor
OPEN curr

-- Posiciona os dados do registro atribuindo as variáveis

FETCH NEXT FROM curr INTO @id, @nome, @idgrupo

-- While
WHILE @@FETCH_STATUS = 0
BEGIN
     
   -- faça o tratamento dos dados aqui....
       
   UPDATE tblclientes SET soma = soma + 1 WHERE id = @id

   -- Movimenta o ponteiro dos dados para o próximo registro e carrega as variáveis
   FETCH NEXT FROM curr INTO @id, @nome, @idgrupo

END

-- Fechando nosso cursor

CLOSE curr
DEALLOCATE curr
Afinal de contas… O que é uma Stored Procedure?

Stored Procedure contém comandos T-SQL que suportam

parâmetros de entrada e saída e que podem ou não retornar
resultados.
Dentro de uma stored procedure você pode escrever comandos
DML (Data Manipulation Language = Insert, Delete, Update,
Merge) e DDL (Data Definition Language – Create, Drop, Alter)
… Ou seja, você pode fazer muita coisa!
O SQL Server armazena em cache os planos de execução das
consultas e, normalmente, os reutiliza em execuções subseqüentes
da procedure para economizar tempo, CPU e recursos de
memória associados à otimização das consultas.
As stored procedures fornecem muitos benefícios em comparação
à implementação da lógica de negócios no aplicativo. Eles
encapsulam a lógica para permitir a reutilização e ocultam a
complexidade. É muito mais fácil aplicar alterações a um
procedimento armazenado com um comando ALTER
PROCEDURE simples em comparação à implementação de
alterações no aplicativo. Além disso, com os procedimentos
armazenados, você precisa ter menos tráfego de rede, pois quando
você chama o procedimento armazenado a partir do aplicativo,
tudo o que é passado pela rede é apenas o nome do procedimento
e seus parâmetros. O fluxo é executado na engine do banco de
dados e, em seguida, apenas o resultado final é enviado para o
aplicativo.
Quando você implementa a lógica no aplicativo, geralmente são
necessárias mais “viagens” entre o aplicativo e o banco de dados e,
consequentemente, mais tráfego de rede. As stored procedures
também simplificam o tratamento de segurança no banco de
dados. Muitas vezes, você não deseja conceder aos usuários
permissões para consultar diretamente e modificar dados nas
tabelas, em vez disso, você quer que eles consigam realizar essas
tarefas apenas indiretamente por meio de procedimentos
armazenados. Para conseguir isso, conceda aos usuários
permissões EXECUTE na stored procedure sem conceder acesso
direto aos objetos.
Fofo né? Dentro de uma procedure a lógica é reaproveitável, além
do desempenho ser melhor… Acredite em mim! É uma boa
prática criar procedures.
Vamos ao exemplo…
Mas antes lembre de algumas coisas…
 Para criar ou alterar um objeto no SQL, então você vai usar as
palavras mágicas CREATE OR ALTER
 Você quer criar uma PROCEDURE
 A procedure deve ter um nome
 A procedure pode ter parâmetros, e cada parâmetro tem um
tipo, e pode ter um valor default
 Dentro da procedure, você pode escrever diversos tipos de
comandos
CREATE OR ALTER PROCEDURE dbo.GetOrders  
(@orderid   AS INT  = 0)

AS

SELECT orderid, orderdate FROM Sales.Orders

WHERE orderid   = @orderid    ; 

GO
Em nosso exemplo a procedure chama GetOrders, recebe como
parâmetro o orderid, que tem como valor default 0, e o retorno da
execução são as colunas orderid, orderdate, da tabela
Sales.Orders onde a coluna orderid tem o valor igual ao
parâmetro passado. Entenda que o valor do @orderid será
substituído pelo valor do parâmetro de entrada.
@ é um símbolo usado na frente do nome das variáveis e
parâmetros.
E como executar uma stored procedure? Simples, comando
EXECUTE 
Execute GetOrders 23

Conclusão

Aprender a criar stored procedures é essencial, fundamental para

você que quer ser um desenvolvedor de sucesso! Você pode criá-
las tanto no SQL Server 2017 quanto no SQL Azure 