It's the same with CAS. data work.demo_compute; format dt_1 tod. dt_2 time.; dt_1='30:22:00't ; dt_2='30:22:00't ; run; title 'demo_compute'; proc print data=work.demo_compute; run; data casuser.demo_cas; set work.have; run; title 'demo_cas'; proc print data=casuser.demo_cas; run; proc casutil; alterTable casdata="demo_cas" columns={{name="dt_1" format="time."}} ; quit; title 'demo_cas after changing format'; proc print data=casuser.demo_cas; run;   ... View more

What the warning tells you is that the data type on the SQL Server side must be Datetime or Datetime2 but that on the SAS side the variable uses a Date and not a Datetime format. The code you shared also shows that the variable on the SAS side stores a SAS Date (count of days since 1/1/1960) and not a SAS Datetime value (count of seconds since 1/1/1960). This section LIBNAME Statement Data Conversions under the doc for the SQL Server access engine shows you how SAS and SQL Server column types map to each other.   If you populate and format your variable in your data step as a SAS datetime column then things will work. data org.procedures; set procedures; RunDate = DATETIME(); format RunDate DATETIME22.; if firstobs then Obs_ID = 1; else Obs_ID +1; run;       ... View more

The log your shared complains not only about PID. Please run below code and share the result. title 'Data: cht_all_sort'; proc contents data=cht_all_sort(keep=pid pid_id vit_oth_sp); run;quit; title 'Data: redcap'; proc contents data=redcap(keep=pid pid_id vit_oth_sp); run;quit; title;   ... View more

@BruceBrad wrote: I think my confusion stems from how %sysfunc works. I was assuming that translate() was interpreted as a normal function, and following its documentation, would require quoted inputs. Is the %sysfunc(translate()) syntax best interpreted as turning translate() into a macro function, with macro-type inputs? This is something that confused me as well in the beginning. Translate() is still a SAS function and not a macro function but %sysfunc() is a macro function and that's why you don't need the quotes.   From the documentation for %SYSFUNC, %QSYSFUNC Macro Functions function is the name of the function to execute. This function can be a SAS function, a function written with SAS/TOOLKIT software, or a function created using the FCMP Procedure in Base SAS Procedures Guide. The function cannot be a macro function. ... Because %SYSFUNC and %QSYSFUNC are macro functions, you do not need to enclose character values in quotation marks as you do in DATA step functions. ... View more

You could replace any character not part of the SAS naming convention with a blank using the translate() function BUT.... things will become quickly complicated if your expressions also can contain functions like sum(varA,varB).  If you can limit your expressions to certain patterns then writing some code might be feasible. Something that would work for any valid SAS syntax would be very involved. ... View more

...and using "&admitdt" instead of bringing the AdmitDt into the data is the only solution I can think of. Which is why I proposed that you share some representative sample data, show the desired result based on this sample data and explain the logic to get from have to want. Someone else can eventually think of a different solution.   If using a SAS macro variable in SAS data step code the macro variable will resolve before the data step gets compiled and executes. It's therefore on the data step level a constant value.    The macro variable will only ever have a single value. In below based on what you've posted... data table4; do AdmitDt='01jan2024'd to '31jan2024'd; output; end; run; data _null_; set table4; call symputx('admitdt',admitdt); run; %put AdminDT: %sysfunc(putn(&admitdt.,date9.));   ...the value of macro variable &admitdt is the last value written to it (=last row from table4). 39 %put AdminDT: %sysfunc(putn(&admitdt.,date9.)); AdminDT: 31JAN2024   Below code leads to the exactly same outcome. data _null_; set table4 end=last; if last then call symputx('admitdt',admitdt); run;   ... View more

@bhca60 Looking at the code you shared I believe you are overcomplicating things. I'm even not sure that you need a macro variable at all. Why don't you explain us what you've got and what you're trying to achieve. Ideally share some sample data with us and show us the desired outcome.   Below some sample code that demonstrates how you could figure out if the days of a week (starting on Sundays) span over two months. data demo; length week_num 8; format week_begin_dt dt week_end_dt weekdatx.; do dt='01jan2024'd to '31dec2024'd; week_num=week(dt); week_begin_dt =intnx('week',dt,0,'b'); week_end_dt =intnx('week',dt,0,'e'); week_two_month_flg =intck('month',intnx('week',dt,0,'b'),intnx('week',dt,0,'e')); weekday_in_diff_month_flg =intck('month',intnx('week',dt,0,'b'),dt); output; end; run; proc print data=demo; where week_two_month_flg = 1; run; If you don't want to use the defaults then you also need to tell us when for you a new year and a new week starts.   ... View more

@thiennguyen19x5 wrote: I understand that code programs are generally different from point-and-click software (JMP, SPSS, Minitab, etc.). Anyway, I only need to love code; I must be adaptable to the inconvenient code program variable name rule. You can use variable names in SAS that don't comply with SAS naming conventions. To use them you need to reference them like: '<variable name>'n It's cumbersome to work with such non-compliant names. Such names will then also be non-compliant in many other programing languages and though will cause even more complication when exchanging data with other environments (like a database).   It's normally best to use short and compliant names with a label added for display (or just as a description stored together with the variable name). data demo; attrib myvar format=percent10.2 label ='This is my numerical variable that displays values in percent' 'myvar literal $'n length=$1 label="This is another variable where the name doesn't comply with SAS naming conventions" ; ; myvar=0.456; 'myvar literal $'n='A'; run; proc print data=demo; run; proc print data=demo label; run;   ... View more

Not sure what you believe is not working. Make sure that in your real code you don't use the lag function conditionally. It only works as you'd expect if it executes for every single row of data. data demo; set sashelp.class; /*Setting lag name of the original name*/ LAG_name = lag(name); *'lag' highlighed in blue; LAG2_name = lag2(name); *'lag' not highlighed; LAG3_name = lag3(name); *'lag' not highlighed; LAG4_name = lag4(name); *'lag' not highlighed; run; proc print data=demo; var name lag:; run;     ... View more

It's easy to establish blocks for game days/game times and I have done this, ... It's may-be obvious to you but for me even when looking at your color coded Excel I don't really understand the rules for such grouping.   ..., but this path has not been helpful since I cannot figure out how to match these blocks properly with the relevant bets. If you can explain the rules how to match as clear and simple as possible then I'm sure someone can help with the code. Right now I don't understand the required logic so won't be able to provide any code. ... View more

As I see the dataset., there are overlaps but it has given me zero overlaps for all observations. Is there another way to do it? If above statement is related to the code sample I shared earlier: The overlaps are all zero because it uses the data you shared via data step and there start and end dates have always the same date and though there aren't any overlaps. You can amend your sample data (data have; step) so they contain overlapping periods and then test again if the script now returns the overlaps you're after.    Is there another way to do it? If you are after some sample code then you need to 1) provide sample data via data step (Have) , 2) show the desired result based on the sample data (Want), 3) explain the logic required to get from have to want. ... View more