We have a lot of code which follows a similar pattern where we collect data, do a bunch of joins and sorts, then use the data. * gather records from some source and put it into a table temp1; proc sql _method;      CREATE TABLE temp1 AS      SELECT     t.*,                        a.another_field      FROM     temp1 LEFT JOIN another_table a                          ON t.acct_id = a.acct_id      ; quit; proc sort data=temp1 nodupkey; by acct_id; run; proc sql _method;      CREATE TABLE temp1 AS      SELECT     t.*,                        y.yet_another_field      FROM     temp1 LEFT JOIN yet_another_table y                          ON t.acct_id = y.acct_id      ; quit; proc sort proc sort data=temp1 nodupkey; by acct_id; run; proc sql _method;      CREATE TABLE temp1 AS      SELECT     t.*,                        e.even_yet_another_field      FROM     temp1 LEFT JOIN even_yet_another_table e                          ON t.acct_id = e.acct_id      ; quit; * and so on and so on until we actually use temp1; This evolved over the decades because every so often someone decides they need another field in the data from another source, so the developer will just inject another CREATE TABLE AS in the middle of the pile. This results in the same data being sloshed around in WORK over and over again. Ideally, we would refactor and test thousands of lines of code every time a join is added, but that's just not viable. Each new CREATE TABLE AS is relatively easy to test in isolation without resorting to full testing. We have refactored one program (of hundreds) which ends with this crazy long join at the end. It will be more difficult to test changes in the future. We have discussed replacing all (or most) of the tables with views, deferring the joins and avoiding sloshing around hundreds of fields and millions of records at each proc sql step. There seem to be two problems: 1. There is no view-friendly substitute for proc sort 2. Creating a view with the same name (as is done above with tables) seriously confuses SAS The hope was to make incremental changes to the code to use views, not to perform a complete rewrite. How are others handling this? Thanks, Marty ... View more

Hello, I am relatively new SAS convert tasked with taking ownership of some legacy production code.  I recently wrote some SAS code to ingest the results of SCAPROC and produce some nice diagrams.  I started with the ds2const macro, but the user interface was rather difficult, so I wrote a replacement that feeds the graphviz suite.  While I am documenting the code, I need to be as minimally-invasive as possible. Everything worked fine, except it appears that a file called in via %include will be documented as a unit, instead of the individual datasteps.  Let me explain.  It turns out the production code I am looking at has wrapper code which calls %include for the real code.  We added PROC SCAPROC to the real code and the resulting file had 1049 "/* JOBSPLIT:" lines consisting of various CATALOG, SYMBOL, LIBNAME, FILE and DATASET entries, followed by the final lines: /* JOBSPLIT: ELAPSED 20307685  */ /* JOBSPLIT: PROCNAME DATASTEP */ /* JOBSPLIT: STEP SOURCE FOLLOWS */ /* JOBSPLIT: END */ After some testing, it appears that SCAPROC will refuse to log any SAS file that has been included via %include.  I could always make changes to the production code and the way it is invoked, but I am trying to avoid that while I document it. Is there an easy was to tell SAS to analyze the individual steps within included files? Many thanks, Marty ... View more