01-03-2017 09:20 AM
In case this is important, I am using SAS EG 5.1.
I am working with a code, and in it, I code a lot of variables and then do some analytics like proc surveymeans and proc surveyreg.
Important to note, when I run this code the first time - it works without any issues. Now, whenever I re-run the code, despite not making any changes to the original code, some of the variables suddenly now change so that the observations for that variable are all coded to missing. So for, example, if I had a variable "color" - all of its observations are now "." in the dataset. So now when I attempt to run some analytics, I can't run analytics on those variables.
Is this some sort of internal issue? Because it's clearly not my code if it runs the first time but not repeatedly.
01-03-2017 09:25 AM - edited 01-03-2017 09:25 AM
Any messages in your log, notes or errors?
Do you have any recursive references, ie
or conditional execution of code that checks for the existence of tables?
Without seeing the code it's hard to say. It's possible it's an EG glitch, but 99% of the time it's a logic error in the code - not a syntax error why your log may be clean.
01-03-2017 09:32 AM
Unfortunately, it's a very long code. There are no warnings or errors in the log when this happens. And what's weird is that it runs fine if you run it once. But if you run it again, suddenly some of the variables all have missing observations. So then I have to close out the program, re-open it, and run it all again... which is really eating a lot of time.
If it's still more helpful to send my code, I can do that. It's just a lot to sort through!
01-03-2017 09:38 AM
Actually here is a small example of something that's no longer working when I re-run it. In this example, the variable "employed" at first was coded correctly and the surveyfreq procedure ran correctly. Then when I re-ran this piece of code, all the observations for "employed" suddenly changed to "." so the surveyfreq procedure no longer was useful.
/*separating out employment variable Q60 into separate variables for each type of employment*/
IF Q60_clean = 1 THEN employed = 1;
ELSE IF Q60_clean IN (2:7) THEN employed = 0;
ELSE employed = . ;
IF Q60_clean = 2 THEN outofwork1yrplus = 1;
ELSE IF Q60_clean IN (1,3:7) THEN outofwork1yrplus = 0;
ELSE outofwork1yrplus = . ;
IF Q60_clean = 3 THEN outofwork1yrless = 1;
ELSE IF Q60_clean IN (1:2, 4:7) THEN outofwork1yrless = 0;
ELSE outofwork1yrless = . ;
IF Q60_clean = 4 THEN homemaker = 1;
ELSE IF Q60_clean IN (1:3, 5:7) THEN homemaker = 0;
ELSE homemaker = . ;
IF Q60_clean = 5 THEN student = 1;
ELSE IF Q60_clean IN (1:4, 6:7) THEN student = 0;
ELSE student = .;
IF Q60_clean = 6 THEN retired = 1;
ELSE IF Q60_clean IN (1:5, 7) THEN retired = 0 ;
ELSE retired = . ;
IF Q60_clean = 7 THEN unabletowork = 1;
ELSE IF Q60_clean IN (1:6) THEN unabletowork = 0;
ELSE unabletowork = . ;
PROC SURVEYFREQ data=work.abcdata;
TABLES Q60_Clean employed;
01-03-2017 09:52 AM
Run it step by step to figure out where it breaks. If you know it's employed variable, see if any code between shown step and final are changing the variable again.
01-03-2017 10:53 AM
"When rerunning" makes me believe there is lots of code you are repeating.
Something else to look for: Changing order of steps when "rerunning". It may be that for some reason your work.abchmvdata no longer has the expected values of the q60_clean variable.
01-03-2017 09:41 AM
When this happens for me, it is usually because the code expects that certain data sets (or variables) are not created before the code runs. As Reeza suggests, look for DATA A; SET A. You can test if that is the case by using PROC DATASETS at the beginning of your program to delete any data sets in WORK.
For other tips, see Rosenbloom and Lafler (2012), "Best Practices: Clean House to Avoid Hangovers."