SAS Stored Processes: 3 Tips to Improve Your Prompts
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”;
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.
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!
Latest posts by Tricia Aanderud (see all)
- Administration: What Demons Are at Your Command? - October 28, 2014
- SAS Visual Analytics: Keeping it Clean for Users - May 27, 2014
- Working with Large Prompt Population Lists - April 21, 2014
- Which population method should I use for my SAS prompt? - April 13, 2014
- SAS Office Analytics: Working with Your Inner SAS Programmer - March 12, 2014