EG- the new home for long-time SAS users

A recent post on SAS-L asks about using EG in a group that has used SAS for quite some time.   Here are my thoughts, if you have others feel free to post them as comments!

1) EG can be used to write code and submit it much like a batch SAS job.   You can totally avoid the GUI tasks if you like and open your old SAS files directly in EG and submit (Run) them just like a batch SAS program.   There are a few minor exceptions due to running via client server, but they seem to rarely be a problem in my experience.

2) If you open a .sas file from your server and are in viewing/editing mode, no one else can overwrite your file since you have the lock on it just like with vi.   If someone edits the file (vi, EG, etc.) and saves it, you will see the changes when you open it next time.

3) EG also allows the ability to save code “embedded” in the project.   This means there is no other way to edit the code than via EG and file locking issues become irrelevant.

4) If you are a long-time SAS programmer like me, if you take the time to really learn EG (1-2 hours/day for several months) you will likely discover areas where it is much faster and even superior to your code and others where it is inferior or incapable.

EG areas of speed/superiority

1. Importing data- uses native PC drivers/facilities to import data along with old-fashioned BASE SAS data step code.   Also, you can use your local ODBC and OLE DB database connections without SAS ACCESS (note, this won’t work well for massive data sources as the data is first sent to your PC and then the SAS server.)
2. SQL code- I can replace most of the need for DATA step with the EG Query builder.   SQL is also superior to the data step if the data is from a relational source and involves multi-table joins (i.e.- similar to merge statements).   With CASE logic, all of the data step functions, filtering, and parameterization (prompted macro variables) the Query builder is an awesome part of EG.
3. Graphs- the old days of trudging through the 800 pages of GRAPH manuals and still not getting what you wanted are over.   EG graph tasks are easily 3-30X faster than writing the equivalent code yourself.
4. Advanced statistical tasks like Mixed are much easier to quickly leverage in EG than writing the code yourself.
5. Statistical PROC’s across the board have a pretty good array of accompanying diagnostic plots that are superior to old STAT diagnostics.   The new Statistical Graphics in 9.2 will be incorporated into EG as well.
6. The OLAP analysis viewer in EG is really nice if you have SAS OLAP, MS Analysis Services, or SAP BW.
7. The easy ability to export data or e-mail/distribute results is very slick.
8. Even if you want to write code as your primary means of analysis, EG can be a great validation tool to replicate your results in a “quick and dirty” way via the GUI tasks.
9. Very easy access to ODS output types like PDF, RTF, HTML, etc.   Also, easy access to the new ActiveX and Java graph controls for your graphics- interactive viewing of graphs!
10. You can easily package up a Process Flow as a Stored Process and create a reusable object that is like a glorified user macro program.

EG areas of frustration/lack of functionality

1. Excessive additional code generated by EG when you export the code.   Also, data import and export doesn’t fully work without modification or at all as an exported job (i.e.- you need EG to make these steps work correctly, along with Send Results type functionality.)
2. Your old AF/SCL/FSP stuff is toast, you need to rewrite it in VB or .NET.
3. You can schedule EG projects, but it still isn’t anywhere near as powerful as some facilities I have seen at many companies leveraging traditional batch SAS type queues, etc. (note, you can write some fancy VB scripts to control these scheduled projects, but you will want a dedicated PC where all projects are scheduled.)
4. Help menu often “recompiles” the help system.   I think this has something to do with EG leveraging several help indexes.   Still, it’s pretty annoying when you are trying to find a serious bug with a presentation coming up in a few minutes!
5. EG has few “guard rails” to stop you from doing boneheaded things.
6. You still need to write and maintain macros as before.
7. You still need an expert programmer to work on efficiency and complex data processing (lags, complex conditional logic, etc.).
8. Learning curve is moderate, but still several months.   The next release should help with this quite a bit (4.2 paired with SAS 9.2).

Overall, I would say I am 2-3X as productive using EG and SAS code than just SAS code alone.   The key is to learn the app over time and you will begin to see the areas of utility for you.   An easy to pick it up is to start with it as a validation tool and eventually move to using it as a production tool.   Also, IT types and strong business analysts can have an environment that they can also leverage with EG.   At my company, on of my colleagues in another department said that “EG would change his life.”   And this is someone who is a true expert at Excel, Excel scripting, and can write very complex SQL queries.  

If you want to see EG in action, check out my book, “SAS for Dummies” which mainly covers EG along with  several other SAS applications.   There are also several good books exclusively on EG and papers EG for SAS Programmers.   You can find some links for this at: http://stephenmcdaniel.us/useful-web-sites-for-sas-users/