If the WHERE statement is part of a DATA step, it is much better to use a hash object there. A macro variable will reach its maximum size much earlier than a hash object would run out of memory. Note that the hash object can also be used in a DATA step view that serves as input for a procedure.
... View more
Then it is obvious why this
INPUT(SUBSTR(B.CIRCDKEY, 15,9), DATE9.)
cannot work. One, your date is stored in the first 8 characters (and not starting at position 15), and two in a YMD format. Your function call must therefore be
input(substr(b.circdkey,1,8),yymmdd8.)
... View more
I see neither a DATA nor a %MACRO statement in your code.
If you need help with code that does not do what you expected, ALWAYS post the complete log.
... View more
Your SAS session runs on a remote UNIX-based server. It cannot access files stored on your local Windows system. Before you can read data from a file, you need to make it accessible, either by uploading to the server, or storing it on a shared resource which is also mapped on the UNIX server. In both cases, you need to use UNIX-style filename syntax. UNIX does not use drive letters and backslashes.
Talk to your SAS admins for assistance.
... View more
You probably have
options missing=0;
set, which means missing values are always displayed as zeroes, and this "hides" the missing values from the unwary user.
That's why we always present datasets as DATA step code, as that prevents any ambiguities. DATALINES don't lie.
... View more
PS when I run
proc export
data=want
file="~/want.xlsx"
dbms=xlsx
replace
;
run;
and open the file in Excel after downloading, it looks EXACTLY like the PROC PRINT result.
... View more
@ligbag4 wrote:
Sorry, I'm realizing I wasn't clear in my initial question. I'm not having the problem when I print the merged dataset in SAS. The issue is occurring when I export the dataset into a xlsx file.
Why are you guys always posting only half (or sometimes, even a tenth) of the real issue????
Maxim 42!!
Please post code and log of your Excel export, so we can recreate the issue. Use the data I created with DATA steps as source, or also show us your original data in DATA steps, as I did.
... View more
In your whole environment, all components (operating systems, databases, SAS, …) need to use the same encoding, or you will always run into such issues.
... View more
CALL SYMPUTX treats its arguments as expressions, and these do not automatically apply formats.
Either use VVALUE, as already suggested, or the PUT function with a suitable format.
... View more
