When I read the original question, and then see the difficult programming that @Patrick provides, I feel compelled to ask @StickyRoll  why this data set needs to be transposed in the first place. What is the benefit of re-arranging the data in this fashion? It seems to me that re-arranging the data set just makes programming the next step(s) much more difficult. If the goal is to create a wide table for output, then no transpose is needed, and PROC REPORT will do this without the difficulties of transposing. ... View more

"WARNING: Variable key already exists on file WORK.MERGE_BACK." You are joining two tables, and variable KEY exists in both. So both cannot be in the resulting data set, you can only have one variable named KEY in the resulting data set.   Now the problem is still that the 2nd left join is bringing over all duplicates key instead of just the unique ones. What I see is that you eliminate duplicates from beneish_index. So the duplicates can't be coming from there. However, I don't see where you eliminate duplicates from work.beneish_m, unless I missed it somewhere, so the duplicates can be coming from there. ... View more

I am not experiencing this type of difficulty in Excel.   ods excel file='text.xlsx'; proc report data=sashelp.citimon(obs=20); columns date cciuac cciutc; define date/display format=date11. "Date"; run; ods excel close; ... View more

Please look at the log and see if it has any clues about what is wrong.   If you're not sure, show us the log by copying it and pasting it into the window that appears when you click on the </> icon. Please do not skip this step. ... View more

You might want to try the %TABLEN macro for this type of table. https://communities.sas.com/t5/SAS-Communities-Library/Demographic-Table-and-Subgroup-Summary-Macro-TABLEN/ta-p/634030 ... View more

I'm thinking you did learn this, and you just have to put the steps you learned together to get the desired output. There's not one command that's going to do this, maybe that's why you think you didn't learn this. Can you state in words what steps you would use? ... View more

From now on, please create a subject line that briefly describes the problem. If everyone used subject line "Revise Program", that would make the forum much less useful.   This looks like a homework assignment, so please show us what you tried and indicate where you are having a problem. ... View more

Is that it, you just all the text concatenated for a customer, and that's the end of the project? Or are you planning to do analysis once you have that? If so, what types of analysis?  ... View more

May I ask why you need to do this? What is wrong with leaving the data as it is and working with it in the long arrangement? ... View more

@atorchio wrote: Hello! I need to perform a one-way ANOVA once using effect coding and once using reference coding for a categorical variable with four categories. I suppose you can do this in PROC GLM, but the two models are identical — the predicted values are the same, the fit is the same.   @atorchio wrote: However, I noticed that PROC GLM only allows reference coding...   You could create your own effect coding dummy variables in a DATA step and then use these dummy variables in PROC GLM, but the end result is the same. In fact, this is one of the major benefits of PROC GLM (and other SAS modeling PROCs) is that you don't have to spend the time to create your own dummy variables for categorical effects (and potentially make mistakes), SAS does this for you behind the scenes. ... View more

@donspaul wrote: I figured out the issue, I forgot to put a period when calling the macro variable in the WHERE clause, I modified the syntax as follows and it works exactly as intended.   where (&STRT_DATE. <= a.veh_first_quot_tstmp_local and a.veh_first_quot_tstmp_local <= &END_DATE.) This would not cause the error messages you saw. More than likely, the error messages were because you used formatted macro variables instead of unformatted macro variables. ... View more

where (&STRT_DATE <= a.veh_first_quot_tstmp_local and a.veh_first_quot_tstmp_local <= &END_DATE) Arithmetic operations and logical operations work properly with unformatted macro variables.    To get unformatted macro variables, use    select variablename format=best32. into :strt_date from have   (Best32. produces the integer that represents the date/time value, essentially this is the unformatted value. If you don't like all the spaces before this integer in the macro variable use select variablename format=best32. into :strt_date trimmed from have ) ... View more

In most cases, macro variables should be unformatted, not formatted.  Maxim 28   What do you plan to do with this macro variable? ... View more

data have; chardate='23-Jan-23'; numdate=input(chardate,date9.); format numdate date9.; run; ... View more