- Simple Queries (4)
- Setting criteria using WHERE (5)
- Calculations (7)
- Calculations using dates (4)
- Basic joins (8)
- More exotic joins (2)
- Aggregation and grouping (8)
- Views (5)
- Subqueries (5)
- Stored procedures (5)
- Variables (8)
- Parameters and return values (11)
- Testing conditions (1)
- Looping (3)
- Scalar functions (6)
- Transactions (5)
- Creating tables (5)
- Temporary tables and table variables (9)
- Table-valued functions (6)
- Derived tables and CTEs (13)
- Dynamic SQL (4)
- Pivots (2)
- Triggers (2)
- Archived (70)
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.
- Go into SQL Server Management Studio;
- Open the SQL file you've just unzipped (you can press CTRL + O to do this); then
- 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.
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:
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) = ''
@OutputParameter = @Variable OUTPUT
@Parameter = @Variable
Optionally save this as Time of woe.sql, then close it down.
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
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.
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.
Good to hear!