SQL | Parameters and return values exercise | Chain stored procedures using output parameters

This exercise is provided to allow potential course delegates to choose the correct Wise Owl Microsoft training course, and may not be reproduced in whole or in part in any format without the prior written consent of Wise Owl.

Software ==> SQL  (198 exercises)
Version ==> Any version of SQL Server
Topic ==> Parameters and return values  (11 exercises)
Level ==> Harder than average
Subject ==> SQL training
Before you can do this exercise, you'll need to download and unzip this file (if you have any problems doing this, click here for help). Once you've done this:
  1. Go into SQL Server Management Studio;
  2. Open the SQL file you've just unzipped (you can press CTRL + O to do this); then
  3. Execute this script.

This will generate the database that you'll need to use in order to do this exercise (note that the database and script are only to be used for exercises published on this website, and may not be reused or distributed in any form without the prior written permission of Wise Owl).

You need a minimum screen resolution of about 700 pixels width to see our exercises. This is because they contain diagrams and tables which would not be viewable easily on a mobile phone or small laptop. Please use a larger tablet, notebook or desktop computer, or change your screen resolution settings.

The aim of this exercise is to link two stored procedures together. Start by creating a stored procedure which shows the ContinentName where the first event occurred.

Stored Procedure Output Parameter

It's the publication of The Wealth of Nations (to save you searching for it)!


Now create a second stored procedure which filters events to show only those which happened in the continent passed in via a parameter. Run this with Europe:

Stored Procedure running with parameters

Not a particularly good time in Europe's history.

Using an output parameter take the ContinentName produced by the first stored procedure and store it in a variable. Use this variable to filter the second procedure.

DECLARE @Variable VARCHAR(100) = ''

EXEC uspProcedure1

@OutputParameter = @Variable OUTPUT

EXEC uspProcedure2

@Parameter = @Variable

Optionally save this as Time of woe.sql, then close it down.

You can unzip this file to see the answers to this exercise, although please remember this is for your personal use only.
This page has 1 thread Add post
02 Sep 21 at 18:09

My solution calls the first stored procedure as part of the second stored procedure. I get the same result as using the method described in the exercise of making two separate calls to two separate procedures and declaring a variable.

Is there any reason my solution would be bad in practice? It seems like being able to call a single procedure that internally leverages the work of another procedure would be preferable to having to declare a variable and call two separate procedures.

Thanks for any advice

03 Sep 21 at 11:49

In my opininon your solution is far more sensible, but ... be aware that this is a training exercise designed to teach about output parameters and calling stored procedures.

Personally I rarely if ever call one stored procedure from another, although I often find myself calling user-defined functions from stored procedures.  If this was a real-world scenario, I would certainly solve the problem using your approach.

03 Sep 21 at 15:17

Thanks for your detailed reply! I appreciate your experience with this. Looks like UDFs are my next lesson.

I try to solve the exercises from the initial description/prompt to see if I can do it without the guidance in the exercises. So, when I checked my work and saw that the exercise recommended a different approach I was just curious if one way was more preferable, as it seems that while there are often multiple solutions, there are usually benefits/drawbacks to each approach.

Thanks again, and thanks for providing these great exercises! I've been learning a lot.

Andy B  
03 Sep 21 at 15:30

Good to hear!