Please note that the lag() function only queues a value if it executes. Using this function conditionally leads most of the time to undesired results. https://go.documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/lefunctionsref/n0l66p5oqex1f2n1quuopdvtcjqb.htm    You get the missing note because the first time below code executes the lag() function will return a missing.   I believe logic like below should return what you're after. data b(drop=_:); set a; by x y; _lag_y=lag(y); /*only do the comparison after the first record*/ if _n_=1 then do; cnt=1; end; else do; if not first.x and y le (_lag_y+4) then cnt+0; else cnt+1; end; run;  And stripping down your logic further below should still return the same result: data b(drop=_:); set a; by x y; _lag_y=lag(y); if first.x or y le (_lag_y+4) then cnt+1; run; And even below would still work data b(drop=_:); set a; by x y; cnt + ( first.x or y > sum(lag(y),4) ); run; ... View more

Your SQL code looks wrong (it is certainly confusing).  What does it even mean to full join in a chain like that?   Let's make some example data. data one; input id name1 $30.; s1=1; cards; 1 all three 2 one only 3 one and two 4 one and two and three ; data two; input id name2 $30.; s2=1; cards; 1 all three 3 one and two 5 two only ; data three; input id name3 $30.; s3=1; cards; 1 all three 4 one and two and three 6 three only ; So when I merge these data ds_merge; merge one two three; by id; run; there are 6 observations. If I tell SQL to combine two of them and combine the resulting set with the third  create table sql_join as select * from three natural full join (select * from two natural full join one) x order by 1,2 ; I get the same 6 observations But if I leave it up to the PROC to try to combine three datasets will chained full joins  create table sql_join2 as select * from two natural full join three natural full join one order by 1,2 ; I get something different To get it to work properly without the nesting the subsequent joins have to refer back to all of the previous dataset's key values, using OR condition. proc sql feedback; create table sql_join as select coalesce(one.id,two.id,three.id) as id ,name1,s1,name2,s2,name3,s3 from one full join two on one.id=two.id full join three on three.id = one.id or three.id=two.id order by 1 ; quit; ... View more

Hi: Without some sample data, nobody can run your code. I have a few thoughts about what you're trying to do. CNT and CNTPCT are both nested UNDER an ACROSS item, CY. That is the major difference between the code in the Tech Support note and the code you posted.   More thoughts: you can't use the "simple" name in your COMPUTE block. You have to use the absolute column number that is calculated by PROC REPORT behind the scenes. Take a look at this paper https://support.sas.com/resources/papers/proceedings14/SAS388-2014.pdf -- in particular, the example on pages 8, 9 and 10 so that you can see a concrete example of how absolute column numbers are created by PROC REPORT with ACROSS items. The other challenge is the way you are creating CNTTOT. Your only placement of CNT is UNDER an ACROSS item, so calculating the percent using the reference to CNT.SUM is not going to work. In the SAME paper, on pages 10,11 you can see how a percent is calculated for every item under an ACROSS item. Cynthia ... View more

I don't use snowflake, so this is just a guess. But from the logs, it looks like there might be a column named Order number in your source snowflake table, and that is tripping up the generated SQL which thinks ORDER is a keyword instead of part of a variable name.     You could try stuff like:   DATA SASTEMP.ICD10_AMPUTATION; SET A3X5_LIB.ICD10_AMPUTATION (rename=("Order Number"N = OrderNumber)) ; RUN; ... View more

Hi: As I show in my example, my titles are NOT wrapping. So I would recommend that you remove all the suboptions and width controls out of your syntax and start with code more like the code I show. Then introduce only one change at a time until you find the one that's causing the wrapping. Without data, it is impossible to run your code. And since I can show that the TITLES don't wrap with taking all the defaults on width and row heights, there's something in your options that is conflicting and causing the issue. Cynthia ... View more

If the spaces are not macro quoted you can just recreate the macro variable from its value. %let median=&median; If they are macro quoted then you might need the %unquote() function. %let median=%unquote(&median); But the real solution is to not put the spaces into the macro variable to begin with.   If you are making it with a data step then make sure the use the new (only 20 years old) CALL SYMPUTX() method instead of the ancient CALL SYMPUT() method.  That will will strip leading and trailing spaces. data _null_; set have; call symputx('median',median); run; If you are making it with PROC SQL and the INTO clause then make sure to add the TRIMMED keyword. proc sql noprint; select min_date,max_date,median into :min_date trimmed , :max_date trimmed , :median trimmed from have ; quit;   ... View more

Hello @Batman,   It's not the difference between PROC SQL and DATA step, but the difference between WHERE and IF: The WHERE filter (be it in a PROC SQL or a DATA step) is applied before the firstobs= dataset option, whereas the subsetting IF is applied after the dataset option. So, in the first case firstobs=2 removes one of the observations satisfying the WHERE condition profit_status3 ne '' from the result, unless there is none at all. The observation skipped with firstobs=2 in the second case might not satisfy the IF condition anyway.   Example: data have; input x profit_status3 $; cards; 1 . 2 b 3 c ;     ... View more