Home » Stored Processes

SAS Stored Processes: 3 Tips to Improve Your Prompts

Submitted by on May 16, 2012 – 7:38 am
http://www.cartoonaday.com/lifes-rat-race-cartoon/

Image courtesy of CartoonADay.Com

SAS stored processes are similar to SAS programs in that they use the same programming language.  Many of my SAS programs I created early on were only used by me, so I could live with  a little uncertainty and it was easy enough to check the logs for any issues.  If anything went wrong then I knew what I had to change.

Stored processes required a whole new level of thinking – my first few stored processes back in the SAS 9.1.3 days were – well they left a lot to be desired.  When I would roll out a new stored process I would often get a call from a user who had done something crazy and the stored process wouldn’t work.  For instance, why would anyone put a state name in a customer name field to see if it would return all the customers from that state?  Only one thing could happen – no report!  

Here’s some usability tricks that I have learned with my SAS Stored Processes to make them more robust and harder to break.  Really the out-of-the box prompts provide a lot of functionality that really helps. That’s right – let’s build a better mousetrap!

Tip #1: Require an Answer for Your Prompt

If your SAS stored process code will break unless it gets a value from the prompt, require the user to have a value.  For example if your code is something like the following example, your stored process will fail if the user does not make a selection:

proc print data=OPS.orders;
where status = “&StatusPrompt”;
run;

One way around this situation is to require an answer. When you create the stored process, select the Requires a non-blank value check box on the General pane.  With this selection, SAS will not let the user move forward without an answer. SAS adds an asterisk to the prompt and if the user selects Run without providing an answer, an error message is generated. Very nice built-in functionality.  It will save you hours of coding.

require the sas prompt to have an answer

 

Tip #2: Provide a Default Value

Tip #1 can be annoying and you might want to make sure the prompt situation warrants it.  As an alternative you can also set a default value for the prompt. Based on the prompt type, there are many ways to indicate the value.  This does allow a user to just go with the defaults so the stored process does not generate an error message.  The only downside I see is if the user doesn’t understand they can make changes – but most people are computer-savvy enough that they can understand it.

Hint: Set the default value when testing your stored process so you don’t have to fill out the values each time.

 

Tip #3:  Provide Minimum and Maximum Prompt Values

If you know the data starts at and ends in a certain time frame, then don’t allow the user to select past those values.  Check the SAS Stored Process: How do I use a Date Range Prompt? for an example of setting minimum and maximum date values. 

Here’s some examples to give you some other ideas. For numeric prompts, if you know the user cannot select a value greater than 100, then limit the value to 100.  Likewise, if you are allowing the user to type a value, then set the minimum value to 5.  It is more likely to be a word.  You have to decide based on your data – but I hope this example just gives you some ideas of how to use the prompts built-in error-checking.

 

These built-in error checks from SAS will save you a lot of coding – so use them to make your stored process more robust and usable.  But mainly to prevent users calling you to report what your stored process does not do.


Learn More about SAS Stored Processes and Prompts

You can learn more tips and tricks for creating, debugging, and using SAS stored processes in the 50 Keys to Learning SAS Stored Processes book. It's a complete guide to SAS stored processes. Check Amazon for best pricing and quick shipping!

The following two tabs change content below.
Tricia Aanderud is a SAS Business Intelligence and Visual Analytics consultant based in Raleigh, NC. She has written several books about SAS, presented papers at many SAS conferences, and has over 10 years of SAS programming experience. Contact her for assistance with your next project.

Tags: , , , ,