One of my current tasks is to convert a hand-written EG project into a manageable DI solution: one that can be scheduled and maintained and so on.
I came across a weird bit of code:
proc sort data=source out=target; by acct_date descending prev_balance; by account_id posting_dt Transfer_Order descending prev_balance; run;
Oh - that looks a bit weird. I wonder what it does - does it use the first by statement, the second, or concatenate them together?
With a bit of expermentation, I found that it only uses the last one it sees. With the data contents being what they were (don't ask), it made little difference as to which statement was being used, but the last one was preferable. I suspect when the code was written, the second line was put in and the first line left there; it compiled and executed and didn't produce an error, so hey-ho.
So then I thought I should experiment. What I came up with is that (not exhaustively): procedures don't care about multiple by statements and use the last; but data steps produce:
ERROR 221-185: More than one BY statement specified for a SET, MERGE, UPDATE, or MODIFY statement.
So there you go. Novel, of no use whatsoever (I mean, why would you?!), but it afforded a little amusement/bemusement in the office today. It's interesting to infer what's going on under the parser's hood.
And back to work.
Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.
If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.