The SAS Output Delivery System and reporting techniques

proc report bookmarks

Reply
Regular Contributor
Posts: 196

proc report bookmarks

I want the bookmark created by contents="Summary Table" (2nd level), but I don't want the 3rd level bookmark called "Table 1".
How do I remove this bookmark (ie "Table 1")?

ods proclabel="Region";
proc report data=field nowd contents="Summary Table"

Thank you.
Super Contributor
Super Contributor
Posts: 3,174

Re: proc report bookmarks

Suggest sharing the rest of your ODS code as well as any FILENAME, if used. And your post may have been truncated - in case, review this prior post on posting posts that has certain characters (code) which gets mangled in the process.

http://support.sas.com/forums/thread.jspa?messageID=27609

Scott Barry
SBBWorks, Inc.
SAS Super FREQ
Posts: 8,743

Re: proc report bookmarks

Hi:
This Tech Support note discusses one method for getting rid of the "extra" Table 1 node that you see in PROC REPORT:
http://support.sas.com/kb/31/278.html


cynthia
Regular Contributor
Posts: 196

Re: proc report bookmarks

Looks good. Thank you.
Do you know how I can remove specific 2nd level bookmarks created by proc print? Is it possible to actually remove them instead of just hide them?
SAS Super FREQ
Posts: 8,743

Re: proc report bookmarks

Hi:
Generally speaking, ODS PROCLABEL is used to RENAME the top-level node in the Results Window or TOC. The CONTENTS= option for PRINT, REPORT and TABULATE, then provides a way to RENAME the lower level or second-level nodes. PROC REPORT has a third-level node that you can alter with the COMPUTE before logic, as shown in the Tech Support note. PROC TABULATE allows the use of CONTENTS= on the TABULATE statement and on the TABLE statement. PROC PRINT only supports CONTENTS= on the PROC PRINT statement. (by RENAME, I mean, either provide a text string for the node or use a ' ' to suppress the text -- which sometimes will also suppress the node in the TOC.)

I'm not sure what you mean by "second-level" bookmark for PROC PRINT. I thought you were using PROC REPORT. Do you have a code example that you can post??? If you don't want to use your data, then make a program with SASHELP.SHOES and PROC PRINT and ODS that illustrates the bookmarks you want to change.

cynthia
Occasional Contributor
Posts: 9

Re: proc report bookmarks

Hi, Cynthia,

Sorry I bring out this discussion again. I think my question is related to this old one.

http://support.sas.com/kb/31/278.html this link gives a way of deleting the "Table 1" node in Proc Report by adding an nonprint Order variable and use of Break Before statement.

However, my own data set already contains an Order variable and I still want to supress the "Table 1" node in the proc report. If I use the method provided in the above link, I got:

p.JPG

That is, my one integrate table becomes two separate tables separated by the level of my original order variable (Type).  The following is my code:

Data temp;

  Set original;

  node = 1;

Run;

Proc Report Data = temp Spanrows Contents = "";

  Define _All_ / Center;

  Define _Numeric_ / Format = 8.2;

  Define type / "Type" Order;

  Define node / Order Noprint;

  Break Before node / Contents = "" Page;

  Break After type / Summarize Suppress Style = [Background = H0F8ED06];

Run;

This code does supress the "Table 1" node in the bookmarks. But I would prefer the one whole table. Is there a way to do this?

Thank you!

SAS Super FREQ
Posts: 8,743

Re: proc report bookmarks

Hi:

  As a general rule of thumb, it is not a good idea to "piggyback" a new question on top of an older posting. When I see a date from over 2 years ago, I assume that there's been some kind of glitch. It would be better to make a new post and, if relevant, include the URL of the older post.

  However, you did not follow the Tech Support note as it was intended. Since you did NOT put a column statement into your code, you essentially ignored the fact that it is the COLUMN statement that defines the left to right order of the variables. If you notice, in that note, the COUNT variable (the fake variable that is set to 1 for every observation) is listed FIRST in the COLUMN statement in that example. That is because you want to only touch the Table 1 node one time. That's why it is set to 1 for every obs.

  When you have a COLUMN statement, it doesn't matter what the order is of your DEFINE statements. But since you did NOT have a COLUMN statement, PROC REPORT did not know where to put the COUNT variable from left-right and so it is probably at the end of the report row, where it is subordinate to the value of TYPE, so essentially it forces a PAGE for every TYPE, which is not what you want. You want COUNT or NODE (as shown in the Tech Support note) to be the primary break. It is the same value for every obs, so as long as COUNT or NODE is primary (or first in the COLUMN statement), it will only issue the PAGE 1 time. When COUNT or NODE is subordinate to TYPE, then it will force a page for every unique value of TYPE (the behavior you are getting that is undesirable).

  I believe this could easily be fixed by using a COLUMN statement, similar to what is shown here (since you did not show your destination or your data variable names, I just called them LABEL and VALUE):

  

Proc Report Data = temp Spanrows Contents = ""

     style(header)={just=c}

     style(column)={just=c};

  column node type label value;

  define node / group  noprint;

  define type /"Type" Order;

  Define label / display 'Label';

  define value / display 'Value' f=8.2;

  Break Before node / Contents = "" Page; /* this will only happen one time with NODE at the beginning of each row */

  Break After type / Summarize Suppress Style = [Background = H0F8ED06];

Run;


   

I don't know why you don't have a COLUMN statement. You do not actually need your DEFINE _ALL_ and DEFINE _NUMERIC_ statements. You could have formatted all numeric variables this way:

FORMAT _NUMERIC_ 8.2; (instead of using a DEFINE statement). But since it looks to me like you only have 1 numeric item on the report, I don't understand what the DEFINE statement for _NUMERIC_ buys you that using a simple DEFINE for your VALUE variable doesn't solve:

define value / 'Value' f=8.2;  (as shown above)

 

and you could have done centering for all the header and data cells this way:

      
proc report data=xyz nowd

     style(header)={just=c}

     style(column)={just=c};


  

and that would have set the defaults to center instead of your DEFINE _ALL_;

 

I believe that you caused the problem in your output by not having a COLUMN statement which listed NODE as the first report item. It doesn't really matter if it is listed before TYPE because 1) it is NOPRINT, 2) it is the same for every obs, and 3) the BREAK will only happen 1 time if it is listed first, which is what you want. If you run your existing code and take the NOPRINT off the DEFINE statement for NODE, you should see that it appears at the end of the report row. This is not what you want if you want the output you describe. You need the NODE variable (like the COUNT variable) in the Tech Support example to be at the beginning of the report row. See the attached screen shot. This is a very slight modification of the Tech Support note to make AGE an order variable, similar to how your TYPE is an ORDER variable. You can see that with the COUNT variable at the beginning of the report row, the output looks like what you want. The way to get the COUNT or NODE item at the beginning of the report row is to use a COLUMN statement.

If you continue to have issues in modifying the code in the Tech Support note to get the output you want, then you might want to open a track with Tech Support for more directed help. but my suggestion is to use a COLUMN statement and to list NODE first, as shown above.

cynthia


count_var_begin_row.png
Occasional Contributor
Posts: 9

Re: proc report bookmarks

Hi Cynthia,

You are right, I never notice the function of the "Column" statement.

After adding it, the output is correct.

Thanks, and sorry for bringing up the old discussion.

Ask a Question
Discussion stats
  • 7 replies
  • 1158 views
  • 0 likes
  • 4 in conversation