11-09-2016 10:57 AM - edited 11-09-2016 11:00 AM
I am having a lot of trouble this morning with this particular error.
ERROR: File WORK.SORTTEMPTABLESORTED.DATA does not exist.
It is happening in a program inside my EG process flow that comes before an export task where I added custom code yesterday. The custom code was to create a "custom" version of the work.sorttemptablesorted data that was created so I could include a PROC SQL case statement on it. Everything ran fine and exported what I wanted it to. However, now I am receiving this error on the program that comes before it.
I have several export scripts that do this same thing. I don't know if I somehow deleted this but I don't see how I could of.
Here is the custom code I entered into the export tasks:
Here is the process flow order of the program and then the export task where I entered the custom code:
Here is the code in the first program that has run just fine until I made the custom code change:
Here is a shot of where the error is showing up in this code:
I am not sure what else to change. Since the only change I made was adding custom code to the export event it must have something to do with that. However, everything looks fine to me. Any help would be greatly appreciated.
11-09-2016 05:26 PM
Your log at line 57 says if nothing is found then this code will never get called. WHICH code will never get called? The next line is proc sql referencing your trouble data set. If the trouble dataset that doesn't exist is suppose to be created when the "this code will never get called" code actually executes then you are referencing a set that didn't get created because the code didn't get called.
I would look into what ever method you are using to exclude the code and see if you either need to extend which code doesn't get called or make sure that a data set or view is actually created with the problem name.
11-10-2016 09:27 AM
The code that doesn't get run is the code immediately after that comment. It creates dummy records in the dataset if there are no records present in the dataset it is calling. This has always worked fine previous to this issue.
I will research how this sort table is involved. SAS has to be doing something behind the scenes that is not showing up in the log.
11-10-2016 02:07 AM
11-10-2016 09:32 AM
I will respectfully disagree, at least in my environment. EG has been a great tool in automating reporting processes with the combination of SQL and SAS logic. If you build datasets with common variables in mind it is actually quite easy to maintain. The trick is learning how to efficiently code for some of these intricacies that I run into.
These particular EG projects take a raw data file each day and process it into a very detailed report within a matter of minutes. It will also provide the data I need to graph, forcast, and analyze that data on the fly. I think a lot of potential is missed if it is only thought of as an adhoc tool.