SAS Stored Processes: 3 Tips to Improve Your Prompts

This post was kindly contributed by Business Intelligence Notes for SAS® BI Users - go there to comment and to read the full post.

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.

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.