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;
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.
The early bird rate has been extended! Register by March 18 for just $695 - $100 off the standard rate.
Check out the agenda and get ready for a jam-packed event featuring workshops, super demos, breakout sessions, roundtables, inspiring keynotes and incredible networking events.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.