About LawrenceHW

LawrenceHW · ‎01-08-2008

Mike, The only way (that I can think of) is to calculate the percentages in a data step prior to reporting. I really don't like proc tabulate and would rather use proc report but that's a personal preference. The n (%) variable can be created as a character type (i.e. 2 (50%)) using whatever method you want and then just use proc report to print out the results.

LawrenceHW · ‎11-02-2007

Hi Cynthia, Thanks for the information. Still slightly puzzled why it happens. But it does ... I'll try the ACTXIMG device driver (or something similar) and see if I can get the program works. Cheers, Lawrence

LawrenceHW · ‎11-01-2007

Hi all, I've come across something puzzling when using ODS RTF in conjunction with SAS/Graph. I have specified a font to use within my GOPTIONS in conjunction with a PROC GPLOT with a BY statement. Code below: FILENAME rtf "&rtf."; ODS LISTING CLOSE; ODS RTF FILE=rtf STYLE=RTF STARTPAGE=YES; GOPTIONS DEVICE=PNG TARGETDEVICE=PNG XMAX=8in XPIXELS=2400 YMAX=6in YPIXELS=1800 HSIZE=8in VSIZE=6in FTEXT="Arial" FTITLE="Arial" HTEXT=11pt HBY=0 HTITLE=11pt; OPTIONS PAPERSIZE=A4 ORIENTATION=LANDSCAPE; AXIS1 LABEL=(A=90); TITLE3 "#BYVAL(lbtest) (#BYVAL(lbstresu))"; PROC GPLOT DATA=lab_screen; WHERE PctChange IS NOT MISSING; BY lbtestcd lbtest lbstresu; PLOT PctChange * StudyDay = siteid / VAXIS=AXIS1; RUN; QUIT; TITLE3; ODS RTF CLOSE; ODS LISTING; In my output file I am finding that the first 7 images are in Arial font but the remaining images (26) have reverted to the default font (simplex) in the graphic. There are no messgaes in the LOG regarding font issues within GPLOT. Has anyone else come across this problem? I suspect this may be something I have to consult with the SAS technical helpdesk but I thought I'd try this forum first ...

LawrenceHW · ‎10-04-2007

Great example Cynthia. PICTURE formats can be (in my experience) quite hard to explain. But they are very, very useful. I find them invaluable for special date/time presentations. I think the main thing that gets people confused is the fact the placeholders are numeric values, so everyone automatically thinks of them being the values. When they're not! I would concur with Cynthia on using the ROUND option. It can cause some unusual results if you don't use it.

LawrenceHW · ‎10-04-2007

The HAVING clause is all very well. But how would you deal with character variables? I don't think the MAX (or MIN) functions work on character values. I also think that FIRST. and LAST. are far more self-documenting.

LawrenceHW · ‎09-27-2007

You could use a simple PROC FREQ. That does the counts for you. Why re-invent the wheel? Or you could use PROC SQL. Something along the lines of: PROC SQL; SELECT DISTINCT subject, COUNT(field5) AS count FROM data GROUP BY subject; QUIT; This will give you the total number of records for FIELD5 for each subject.

LawrenceHW · ‎09-27-2007

It's probably to do with a customer requirement. Many of our clients have a variable order preference so that when someone is browsing the data set (either FSV or Viewtable) then the key variables (i.e. subject ID) are always to the left of the screen. Makes it much easier than having to manually shift the variables around.

LawrenceHW · ‎09-24-2007

The other alternative (and the one I prefer) is to use PROC SQL. PROC SQL; CREATE TABLE xxx AS SELECT v3, v2, v1 FROM xxx; QUIT;

LawrenceHW · ‎09-10-2007

True. I meant to type LAST. and I typed FIRST. What can I say? It was the end of pretty long day. From a code maintenance and documentation pov I would always have the full by statement that I use. Saves inexperienced people coming up to you and asking why something works. Also means that when you go back to the code in a year or so, you don't have to work out what you did.

LawrenceHW · ‎09-06-2007

True. I'm just so used to using PROC PRINTTO (spot the V6 programming traits) .... habit I guess. I think ODS is a far neater statement though.

LawrenceHW · ‎09-06-2007

Just adding my two pence worth here. I agree. Don't like users having long text strings as input. Leads to all sorts of horrors with %STR, %BQUOTE, %SUPERQ, etc. etc. etc. I often find that using a DATA _NULL_ step reading the macro variable into a data step variable much easier to deal with as there are lots of character manipulation functions to play around with. Then if you want a list of values in a list which are quoted why not use the SQL code of "SEPERATED BY ' '"? Always a useful little function. Or you could use RETAINs within the DATA step and concatenation functions. Can be easier to de-bug and maintain as well. In the old (v6) days text variable were restricted to 200 chars. Which made macro variables far more attractive when dealing with massive strings.

LawrenceHW · ‎09-06-2007

There are a few little ways to do this. First you don't need the PROC SORT. The GROUP BY should have sorted the STEP01 dataset already for you. If it hasn't just bung an ORDER BY statement after the GROUP BY. Although I'm pretty sure the GROUP BY should do this for you (in my defence it's been a long day:( ). To get the FIRST. & LAST. working inside a DATA step you need the BY statement. That's just the way it is. FIRST. & LAST. are explicitly defined temporary variables. I assume your BY statement would look something like: BY person end_date; In the DATA step you would pick off: IF FIRST.end_date; You would then get the last job details for each person. You could also do some slightly fancy SQL code using MAX functions and sub-selections and joins ... but to be honest the SQL followed by the DATA step is pretty much the best and most efficient (certainly from a code maintenance POV) way to achieve this. Hope this makes sense. Lawrence

LawrenceHW · ‎09-06-2007

Try PROC PRINTTO with a fileref.

LawrenceHW · ‎08-10-2007

True some procedures don't require the data to be sorted before using. But SAS is still going to have to go through the sorting process somewhere ....

LawrenceHW · ‎08-06-2007

Thanks for the swift reply. I still route PROC REPORT to the listing destination as that's what's required most of the time in my day-to-day job. I'd already encountered the "<" ">" repeating functionality. I managed to get round the problem by inserting a blank character (using BYTE(160)) before and after the "++" and this stopped the spanning characters. Another example of having to fool SAS into doing what you want it to do rather than it doing what it's been asked to do. Not that I'm complaining ... after all it keeps you on your toes.

Online Status	Offline
Date Last Visited	‎05-24-2022 08:42 AM

Re: Numer of months between 2 dates

Re: Finding a value across all datasets in a library

Re: Finding a value across all datasets in a library

Finding a value across all datasets in a library

Re: Parallel processing in a Grid - sort of works

Parallel processing in a Grid - sort of works

Re: Indenting rows in ODS EXCEL - it works in TAGSETS.EXCELXP

Re: Indenting rows in ODS EXCEL - it works in TAGSETS.EXCELXP

Re: Indenting rows in ODS EXCEL - it works in TAGSETS.EXCELXP

Indenting rows in ODS EXCEL - it works in TAGSETS.EXCELXP

Browsing SAS data sets in Enterprise Guide without locking

Autosave/backup projects

Expanded Details Regarding Compiled Macros

Create ROW_NUMBER() function for PROC SQL

Re: Check if the table is empty

Re: Finding a value across all datasets in a library

SAS Studio Task - in clause for a where statement

Re: How to get count of occurrences of a record

Re: Custom Tasks: Checking whether inputtext has a value

Re: AE table with %'s

Re: ODS RTF and Proc GPLOT

ODS RTF and Proc GPLOT

Re: How to make a format for monetary values

Re: Questions about use of first. or last.

Re: How to get count of occurrences of a record

Re: re-order SAS variables

Re: re-order SAS variables

Re: Questions about use of first. or last.

Re: Output Proc Report to different text files

Re: How to break apart a parameter

Re: Questions about use of first. or last.

Re: Output Proc Report to different text files

Re: Sorting the dataset

Re: proc report spanning column headers