BookmarkSubscribeRSS Feed
Calcite | Level 5

I  know that there will be opinions both ways on this, but I am curious to see what folks are thinking and why.  So, the two topics are:

1) Thoughts about saving code within the EG project versus as shortcuts and saving the code as .sas outside the project

2) Thoughts about using relative paths for pointing to external files - such as external code (if we go that way) or external data sets, etc.

Calcite | Level 5

I'll start by answering my own questions

1) Code location

At first we were embedding the code, but then I was offsite using my mac via remote desktop to run an unplanned fix to the code.  I found I couldn't get to the code b/c EG was not on our server.  After that we went to the practice of putting the code external so it was available in case we for some reason needed a way to run the code interactively (we are SAS programmers, not EG analysts so we are very comfortable with that).  Since then we've loaded a copy of EG on the server so now even from my mac with VPN and remote desktop, I can log in and run EG projects no problem

My conclusion:  If you have EG available in all your environments, keeping the code inside the program is the way to go as it prevents things from getting lost when you migrate environments and reduces the chances of accidental deletion/editing/moving.

2) Relative paths

My conclusion:  Why wouldn't we - other than the chance you forget to migrate external files with it - and that is just making sure we have good attention to details.  Okay, easier said than done, but we should be able to do it.


If you need ultimate flexibility in how you run your SAS programs and from what location you run them from, then I suggest it is best to avoid relative paths. However it is common practice for us to set up a global macro variable to define our application path like so: %let appdir = \\ourappserver\appdir1\appdir2; We then cascade this definition throughout all SAS programs in the overall SAS application so it sort of acts like a relative path. Then it doesn't matter from where you run your SAS application: SAS server, any desktop etc the programs always reference directory locations correctly. And if you want to switch between Production / Test / Development environments you just need to change one macro variable and the application then is re-pointed to the new environment.

Rhodochrosite | Level 12


On the code location.  The best answer is "it depends".  If the code is to be used by multiple projects, then storing it outside EGuide makes maintenance easier.  If the code is project specific, then inside EGuide is fine.  Another consideration is the editor.  Like many who program a lot, I am rather fond of an editor other than the SAS provided one; if I want to use that editor, I need to keep the code outside of the EGuide project.

[The EGuide editor has actually gotten pretty decent.  As I work in both the Unix and PC worlds, I prefer the consistency of EMACS.]

Doc Muhlbaier


Quartz | Level 8

1) Thoughts about saving code within the EG project versus as shortcuts and saving the code as .sas outside the project

I save my codes externally as different .SAS files. And heavily use %include in the main .SAS.

PROS: I primarily used EG. But when I need to run on my desktop version of SAS for Windows, I can migrate it easily from EG. Sometimes our corporate SAS Server which is shared by many departments can be very slow.

CONS: Without EG, there is no Link and it is not easy to visualize the link and order of codes:

This problem of visualizing the structure of the code will be gone after sometime when the user gets used to the project. For documentation, we draw a diagram of the code hierachy.

2) Thoughts about using relative paths for pointing to external files - such as external code (if we go that way) or externa

As SASKiwi as replied, I use global variable to define the path and libraries.

Community Manager

EG 4.3 added an under-advertised feature for relative paths.  You can store files such as SAS programs, and Excel and text files for import, in a folder relative to the EGP file, and when you move the whole collection around from machine to machine (or check in/out of a source management system) the files should all resolve.

First, enable it for your project with File->Project->Properties, select File References and the "Use relative paths" option:


Then you can have a file structure like:





Assuming that you add the SAS programs by reference (not embedded) and import the XLSX file, this entire folder structure becomes "portable" -- you can lift it and drop it on another folder, drive, or machine and all should resolve without having to fix in Tools->Project Maintenance.

And you can make your code "relative folder aware" as well, using this tip:


Check out SAS Innovate on-demand content! Watch the main stage sessions, keynotes, and over 20 technical breakout sessions!


Available on demand!

Missed SAS Innovate Las Vegas? Watch all the action for free! View the keynotes, general sessions and 22 breakouts on demand.


Register now!

SAS Enterprise Guide vs. SAS Studio

What’s the difference between SAS Enterprise Guide and SAS Studio? How are they similar? Just ask SAS’ Danny Modlin.

Find more tutorials on the SAS Users YouTube channel.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 5 replies
  • 5 in conversation