I want to use the following code to select the first 30days (from the first wagerdatedatime) data, but it turned out I still got the whole data. Where could be the problem?
proc sql; create table final2.First_30_days_wager as select DUPI, count(distinct provider) as sites_wagered, count(distinct datepart(wagerdatetime) ) as betting_days, min(total_wager) as min_wager, max(total_wager) as max_wager, mean(total_wager) as mean_wager, std(total_wager) as std_wager, sum(total_wager) as sum_wager, count(total_wager) as betting_times, min(datepart(wagerdatetime)) as first_day from Anawager.dupi_wager_b_all where total_wager>0 group by DUPI having datepart(wagerdatetime)<min(datepart(wagerdatetime))+30; quit;
Hi @fengyuwuzu,
The issue was that the HAVING clause applied to the result of the SELECT statement up to and including the GROUP BY clause. That is, the various summary statistics before the FROM clause were not restricted to the 30-days time window. The first occurrence of WAGERDATETIME in the HAVING clause then required remerging summary statistics to the original data. Finally, the HAVING clause selected part of the remerged records (most probably many duplicates).
Instead of creating an intermediate dataset test.first30days you could write the SELECT statement of the new first PROC SQL step as an inline view into the FROM clause of the second PROC SQL step. (Also, the SELECT statement could be restricted to the variables needed in the second query: DUPI, provider, wagerdatetime, total_wager.)
In any case, please note that it makes a difference, in general, whether the WHERE clause is applied in the first query (or inline view, resp.) or in the second query.
I don't see anything explicitly wrong with your code.
Can you add some sample data that replicates your issue?
And/or your log if it shows any Notes/Errors.
Thank you, Reeze. Log file already overwritten.
I ended up with 2 steps, first step select the 30 days data and second step to do the summaries.
proc sql; create table test.first30days as select * from anawager.dupi_wager_b_all group by DUPI having datepart(wagerdatetime) <= min(datepart(wagerdatetime))+30; quit; proc sql; create table test.first30days_stat as select DUPI, count(distinct provider) as sites_wagered, count(distinct datepart(wagerdatetime) ) as betting_days, min(total_wager) as min_wager, max(total_wager) as max_wager, mean(total_wager) as mean_wager, std(total_wager) as std_wager, sum(total_wager) as sum_wager, count(total_wager) as count_wager from test.first30days where total_wager>0 /* some total_wager<0; so many =0 */ group by DUPI; quit;
Hi @fengyuwuzu,
The issue was that the HAVING clause applied to the result of the SELECT statement up to and including the GROUP BY clause. That is, the various summary statistics before the FROM clause were not restricted to the 30-days time window. The first occurrence of WAGERDATETIME in the HAVING clause then required remerging summary statistics to the original data. Finally, the HAVING clause selected part of the remerged records (most probably many duplicates).
Instead of creating an intermediate dataset test.first30days you could write the SELECT statement of the new first PROC SQL step as an inline view into the FROM clause of the second PROC SQL step. (Also, the SELECT statement could be restricted to the variables needed in the second query: DUPI, provider, wagerdatetime, total_wager.)
In any case, please note that it makes a difference, in general, whether the WHERE clause is applied in the first query (or inline view, resp.) or in the second query.
Thank you for the explanation and suggestion.
Join us for SAS Innovate April 16-19 at the Aria in Las Vegas. Bring the team and save big with our group pricing for a limited time only.
Pre-conference courses and tutorials are filling up fast and are always a sellout. Register today to reserve your seat.
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.