DATA Step, Macro, Functions and more

Proc SQL macro "skipping" updates

Reply
Occasional Contributor
Posts: 7

Proc SQL macro "skipping" updates

Hi,

I have written some code to update a table with various values from another table, however, SAS seems to randomly skip updating rows, even when the conditions at satisfied. I have noticed that if I restart SAS (close and re-open) the problem seems to be alleviated to some degree, but there will still missing values at times. I would say that this happens about 90% of the time I try and run the code. Furthermore, each time I run the code, (even with the same input data) the rows that don't get updated are different each time.

%if &i=1 %then %do;
proc sql feedback;
alter table l.raw_%sysfunc(date(),date7.)
add A num format best32.
add B num format best32.;
update l.raw_%sysfunc(date(),date7.) t1
set A = (select ppg_total_&rpi2._a from l.raw_%sysfunc(date(),date7.)_copy where monotonic() = &i) where monotonic() = &i;
update l.raw_%sysfunc(date(),date7.) t1
set B = (select ppg_allow_total_&rpi2._a from l.raw_%sysfunc(date(),date7.)_copy where monotonic() = &i) where monotonic() = &i;
quit;
%end;
%else %do;
proc sql;
update l.raw_%sysfunc(date(),date7.) t1
set A = (select ppg_total_&rpi2._a from l.raw_%sysfunc(date(),date7.)_copy where monotonic() = &i) where monotonic() = &i;
update l.raw_%sysfunc(date(),date7.) t1
set B = (select ppg_allow_total_&rpi2._a from l.raw_%sysfunc(date(),date7.)_copy where monotonic() = &i) where monotonic() = &i;
quit;
%end;
Super User
Posts: 5,080

Re: Proc SQL macro "skipping" updates

I can't tell if this is the problem or not, but I believe that SAS considers the MONOTONIC function to be an undocumented, unsupported feature.  It could be a source of problems.

Occasional Contributor
Posts: 7

Re: Proc SQL macro "skipping" updates

yea, i had a feeling that monotonic might have something to do with it. i am trying to think of a solution to work around using monotonic.

Super User
Posts: 17,784

Re: Proc SQL macro "skipping" updates

It seems a bit unintuitive in SAS to update row by row like that as well. I've seen that done using cursors in SQL, but not in SAS.

It looks like straight join by row, and that A and B are set to the same thing?  I'm not sure if you simplified the code to post it.

Occasional Contributor
Posts: 7

Re: Proc SQL macro "skipping" updates

A and B are different variables, but the way in which they are retrieved are the same (one is pgg_total and one is ppg_allow).

the problem i am running into is getting sas to update only one row at a time... which is why i have two monotonic() constraints. the first retrieves the value from the table, and then the second only updates one row at a time.

edit: i am guessing i can figure out a better way to write this, without using monotonic() like this, but its intriguing to me that SAS evaluates it differently each time the code is executed.

Super User
Posts: 3,102

Re: Proc SQL macro "skipping" updates

Why not write your updating process in a DATA step where you have full row-by-row control and don't require undocumented features?

Occasional Contributor
Posts: 7

Re: Proc SQL macro "skipping" updates

I tend to use sql as a crutch... more than I should.

Anyhow, I still kept the meat of the sql there, but instead of using monotonic i used a data step to create a macro variable to keep the constraints.

...and before I wrote this post, I didn't realize that monotonic was unsupported.

Super User
Posts: 3,102

Re: Proc SQL macro "skipping" updates

Understandible if you come from an SQL background, but SAS DATA step processing goes way beyond what you can do in SQL with the bonus of row-by-row control.

I've done SQL stored procedures with cursors to get row control but its way more complicated than DATA steps Smiley Wink.

Super User
Super User
Posts: 6,499

Re: Proc SQL macro "skipping" updates

Can you explain in non code what that program is trying to do?

I wouldn't normally use an "ALTER TABLE" statement in SAS.  To add a column to a table would require SAS to totally recreate the table. So at that point why not just use a data step or an SQL create table statement to make the table you want?

Ask a Question
Discussion stats
  • 8 replies
  • 280 views
  • 3 likes
  • 5 in conversation