In EG, when you are developing a stored process, is there a way to "walk through" code you are developing? In Visual Basic, there is an option tostep through the code your'e writing, and I'm wondering if there is an equivalent step-through in EG and stored processes.
There is not the same kind of facility in EG -- to step through code. So when you add stored processes into the mix, there's still NOT the ability. In BASE SAS, outside of EG, there is a data step debugger that you can use to step through a data step program, but that won't help you if your stored process is composed of several PROC SQLs and a PROC REPORT.
The best way to ensure you have a bulletproof stored process is to thoroughly
1) test your code BEFORE you turn it into a stored process.
2) Then, once you have a working SAS program, add macro variables and %LET statements and test your code, (yes again), with macro variables (before you turn the code into a stored process).
3) Then, once your code with single macro variables works, if you have no more processing to do, THEN and only THEN, turn your code into a stored process using the stored process wizard.
If, on the other hand, you are at step 2 and your code works and it works with macro variables and %LET and you say to yourself, "Golly, I'd like to add some conditional logic here." then you enter phase 2a:
2a) turn your program into a SAS macro program that uses macro conditional logic or other macro processing -- test this code OUTSIDE of a stored process (yes, test all over again) and then proceed to #3.
If you have done all that and you start to have problems or issues with the stored process execution, generally, I find the problems fall into these categories:
a) results are not what you expect -- either the users did not enter parameters the way you tested or you did not anticipate some combination of parameter values -- check the log and go back to step 2 and retest your working SAS code with the same combination of macro variables and see whether you can duplicate the problem -- fix the problem and then move those changes into the SP code or recreate the SP using the SP wizard with the new code
b) results are what you expect - -but the formatting is different in XXX application than it looked in EG -- generally this happens with Web Report Studio or PowerPoint --because they take SP results and turn them into SASReport XML, whereas EG turns the SP results into HTML. (by default)
c) the program worked in step 2 and step 3 tests, but just doesn't work as a SP -- examine the log -- there are some things that will work in EG, but don't work in other client applications (like the LINE statement in PROC REPORT) -- this is the place where you search Tech Support Notes or call Tech Support for direction.
Even if you could "walk through" the code in EG, it wouldn't help you in the other client applications, anyway. There's a difference between walking through just the code and simulating the interactivity that happens on the client application side and simulating the working through the metadata, simulating server processing, etc.
So the best way to develop your stored process is to test the code first, then once you have working code, turn the code into a stored process. Then, before you move the SP to a production repository, you have to test the SP in all the client applications from which it could be executed and adjust the SP accordingly. But, if you started with working code, making these subsequent adjustments should not be very burdensome.
OK.... thanks for your reply. Actually I was hoping there was a step-through capability, rather than using something like Proc Print items.... I wasn't concerned with where the SP is run from as much as being concerned with how values are achieved at various stages of processing.
Most of our SP's are striaght fall-through applications, and having an ability to stop / step through code, going fro one proc to a macro and so on would be great. That's why I mentioned how VB has that capability. In VB, it doesn't matter where the program is run...you can, as a developer, stop the code and walk-through the code.
SAS's log can provide a wealth of information for debugging purposes.
If you have SOURCE and SOURCE2 turned on the code is echoed to the log.
If you are using MACROS, then MPRINT, MLOGIC, MPRINTNEST, MLOGICNEST adds tons of log messages, including the values of macro variables and macro resolutions.
Use of %put statements help to echo values to the log.
If you are developing code directly, and need stepping capability, then you should invest in PC SAS to be able to use its interactive environment. It has a debugger.
EG is biased more towards interactive data analysis than toward application coding.
As Chuck said, there are extensive options to help you "step through" your code. One of my favorites is SYMBOLGEN -- which shows you EXACTLY how your macro variables are being resolved.
When you start with a working SAS program and then convert that working SAS program to use Macro variables or Macro programs BEFORE you convert the program to a stored process -- there is ample opportunity to use these options to debug your macro code and understand how the macro facility works.
Turning such a program into a stored process is not a big deal, IF you already have tested, working, debugged code. If you have something like this:
proc print data=sashelp.class;
proc freq data=work.wombat;
And you want to "step through" the behavior of %somemac -- then the options that Chuck mentioned, plus, SYMBOLGEN -- are the equivalent of the walk through that you want. This kind of walk through is MUCH easier if you do it BEFORE you turn your program into a stored process. If you have not done the debugging before you turned your program into a stored process and you need to do debugging, then you can add the options to your stored process, however -- falling back to the working code that you started with is probably a faster way to do debugging. The SP input parameters are just taking the place of any hardcoded %LET statements that you use in your testing.
Of course, there's always Tech Support for more help, if you get completely stuck with debugging a macro that's inside a stored process.
Isn't there also a / debug option for DATA steps that allows you to step through the processing? I don't use it much, so I can't comment on its suitability and it may not be an option with EG, but I thought I'd mention it.
I expect it fails for the same reason we can't use %window and %display in EG.
As I said, EG is biased toward interactive analysis, not application development.
So, some features of SAS do not work within that environment, which is a shame, because it is such a great start at simplifying SAS. It just falls down when you want to get into more details and pickier use (not all options are readily available, adding custom code to charts/graphs is a pain, etc.)