Hi:
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.
cynthia