Hi All,
I am trying to create a dates table for every 3 months, when i am using the below code within Rsubmit the datesqtr
datasets is populating as expected. but when i use the same code outside Rsubmit the datesqtr dataset is not populating as expected. Could you please suggest?
DATA _NULL_;
YR_START_DATE=INTNX('MONTH', DATE(), -1, 'B');
YR_END_DATE=INTNX('MONTH', YR_START_DATE, -12);
DO UNTIL(YR_END_DATE>YR_START_DATE);
i+1;
MNTH_START_DATE=YR_START_DATE;
MNTH_END_DATE=INTNX('MONTH', MNTH_START_DATE, 0, 'e');
PREVDTE=INTNX('MONTH', MNTH_START_DATE, -1, 'S');
/*PREVIOUS MONTHS DATE*/
PUT MNTH_START_DATE=YYMMDD10. MNTH_END_DATE=YYMMDD10. PREVDTE=YYMMDD10.;
CALL SYMPUT(CATS('MNTH', I), PUT(MNTH_START_DATE, YYMMN6.));
CALL SYMPUT(CATS('MNTHSTDT', I), PUT(MNTH_START_DATE, YYMMN6.));
/*start date current month i.e. reporting period month t-1 month*/
CALL SYMPUT(CATS('MNTHENDDT', I), PUT(MNTH_END_DATE, YYMMN6.));
/*end date current month i.e. reporting period month t-1 month*/
/*FIRST MONTHS DATE YYMM AS TRANSACTION DATE*/
CALL SYMPUT(CATS('ATMDATE', I), PUT(PREVDTE, YYMMN6.));
/*atm transaction for the reporting month month*/
/*PREVIOUS MONTH DATE YYMM AS TRANSACTION DATE*/
CALL SYMPUT(CATS('PREVDTE', I), PUT(INTNX('MONTH', MNTH_START_DATE, -1, 'S'),
YYMMDD10.));
/*previous month date*/
CALL SYMPUT(CATS('BGNDTE', I), PUT(INTNX('MONTH', MNTH_START_DATE, -3, 'S'),
YYMMDD10.));
/*match to fetch the qtrly start date from the source format*/
CALL SYMPUT(CATS('ENDDTE', I), PUT(INTNX('MONTH', MNTH_START_DATE, -2, 'E'),
YYMMDD10.));
/*match to fetch the end qtrly date from the source format*/
CALL SYMPUT(CATS('DATE', I), PUT(MNTH_START_DATE, YYMMN6.));
/*transaction for previous months*/
CALL SYMPUT(CATS('ATMDATE', I), PUT(PREVDTE, YYMMN6.));
/*atm transaction for previous months*/
/*PREVIOUS MONTH DATE YYMMDD AS TRANSACTION DATE*/
YR_START_DATE=INTNX('MONTH', YR_START_DATE, -1);
END;
PUT YR_START_DATE YR_END_DATE;
RUN;
%macro test;
%do i=1 %to 4;
%let stdte&i. = %sysfunc(intnx(month, %sysfunc(today()), -&i.), 6.);
%put stdte&i. = &&stdte&i.;
%let endte&i. = %eval(%sysfunc(intnx(month, &&stdte&i., 3), 6.)-1);
%put endte&i. = &&endte&i.;
proc sql;
connect to teradata (user="&myname.@xxxx"
pass=&mypwd. tdpid=&id. mode=teradata);
create table datesqtr as select * from connection to teradata
(select date_key, cldte_sas from xxxx.ss_dte_dim where cldte_sas
between &&stdte&i. - 4 and &&endte&i.
order by cldte_sas;
) order by cldte_sas;
disconnect from teradata;
quit;
%end;
%mend;
%test;
Your macro test as posted doesn't really work as you describe it does. How much did you change your real code?
%macro test;
%do i=1 %to 4;
%let stdte&i. = %sysfunc(intnx(month, %sysfunc(today()), -&i.), 6.);
%let endte&i. = %eval(%sysfunc(intnx(month, &&stdte&i., 3), 6.)-1);
%put stdte&i. = %sysfunc(putn(&&stdte&i.,date9.)) endte&i. = %sysfunc(putn(&&endte&i.,date9.));
/**
proc sql;
connect to teradata (user="&myname.@xxxx" pass=&mypwd. tdpid=&id. mode=teradata);
create table datesqtr as
select *
from connection to teradata
(
select date_key, cldte_sas
from xxxx.ss_dte_dim
where cldte_sas between &&stdte&i. - 4 and &&endte&i.
;
)
order by cldte_sas;
disconnect from teradata;
quit;
**/
%end;
%mend;
%test;
Issues in above macro logic
1. The time periods are overlapping
2. The target table name is a fix string and though gets overwritten (re-created) by every single iteration of the loop. You need to use a dynamic table name instead like datesqtr_&i.
3. In the posted code there is an order by on the Teradata side and on the SAS side. Don't sort twice - that's just inefficient. Sort on the SAS side so the SAS table created gets the sort attribute set.
4. If this where clause works then "someone" must have stored SAS Date values in Teradata just as numbers instead of actual dates. This can work but.... why would one do that and loose all the date information and related functionality?
And last but not least the rsubmit story
One reason why one would use rsubmit is: You have a locally installed SAS where you don't have access to Teradata, you have a remote SAS Server that has access to Teradata and you want to run your SAS script from the locally installed SAS. In such a case you would create a remote session via rsubmit where you run your code BUT if you then want to use the table in your local SAS session you need to either download the table or use remote library services.
I would also expect that in such a scenario there are some additional part to rsubmit that you haven't shared - rsubmit <and here more stuff>; ...and a signon statement? etc.
How does RSUBMIT have anything to do with this?
What are you rsubmitting?
Where are you rsubmitting it from?
Where are you rsubmitting it to?
If you want to get a range of dates in Teradata use the built in CALENDER.
If you don't also rsubmit the rest of the code where it the macro going to get the macro variables?
Why just RSUBMIT the query instead?
%macro test;
Rsubmit;
proc sql....
endrsubmit;
%mend;
%test;
What is the SAS code you are trying to generate?
What does this code do?
create table datesqtr as
select * from connection to teradata
(select date_key
, cldte_sas
from xxxx.ss_dte_dim
where cldte_sas between &STDTE1 - 4 and &ENDTE1
order by cldte_sas
);
What type of values does CLDTE_SAS contain?
What type of values do the macro variables STDTE1 and ENDTE1 contain?
Why are you also creating STDTE2, STDTE3 and STDTE4? That is just making your macro code more complicated without any added value.
Why would you store the SAS's internal representation of a date as a numeric field in Teradata?
Why no make the variable a DATE field in Teradata?
I am still not clear what the purpose of the Teradata query is. Especially why you run it 4 different times.
Why run it four different times and overwrite the same output dataset each time?
Why not just skip the first three runs since you are throwing them away?
Your macro test as posted doesn't really work as you describe it does. How much did you change your real code?
%macro test;
%do i=1 %to 4;
%let stdte&i. = %sysfunc(intnx(month, %sysfunc(today()), -&i.), 6.);
%let endte&i. = %eval(%sysfunc(intnx(month, &&stdte&i., 3), 6.)-1);
%put stdte&i. = %sysfunc(putn(&&stdte&i.,date9.)) endte&i. = %sysfunc(putn(&&endte&i.,date9.));
/**
proc sql;
connect to teradata (user="&myname.@xxxx" pass=&mypwd. tdpid=&id. mode=teradata);
create table datesqtr as
select *
from connection to teradata
(
select date_key, cldte_sas
from xxxx.ss_dte_dim
where cldte_sas between &&stdte&i. - 4 and &&endte&i.
;
)
order by cldte_sas;
disconnect from teradata;
quit;
**/
%end;
%mend;
%test;
Issues in above macro logic
1. The time periods are overlapping
2. The target table name is a fix string and though gets overwritten (re-created) by every single iteration of the loop. You need to use a dynamic table name instead like datesqtr_&i.
3. In the posted code there is an order by on the Teradata side and on the SAS side. Don't sort twice - that's just inefficient. Sort on the SAS side so the SAS table created gets the sort attribute set.
4. If this where clause works then "someone" must have stored SAS Date values in Teradata just as numbers instead of actual dates. This can work but.... why would one do that and loose all the date information and related functionality?
And last but not least the rsubmit story
One reason why one would use rsubmit is: You have a locally installed SAS where you don't have access to Teradata, you have a remote SAS Server that has access to Teradata and you want to run your SAS script from the locally installed SAS. In such a case you would create a remote session via rsubmit where you run your code BUT if you then want to use the table in your local SAS session you need to either download the table or use remote library services.
I would also expect that in such a scenario there are some additional part to rsubmit that you haven't shared - rsubmit <and here more stuff>; ...and a signon statement? etc.
It's finally time to hack! Remember to visit the SAS Hacker's Hub regularly for news and updates.
Learn how use the CAT functions in SAS to join values from multiple variables into a single value.
Find more tutorials on the SAS Users YouTube channel.
Ready to level-up your skills? Choose your own adventure.