Bypassing the LIBNAME/libref

[AnnHarper]

Hello,

I teach SAS to MPH students during the summer semester.  Last summer, at least one student used the following syntax, which I never knew you could do in 30+ years of SAS programming - but it worked! I'm just wondering, other than not being 'best practice', what the downside of this would be.... 

PROC SORT DATA= 'C:\zipdataset.sas7bdat' OUT= newdataset; by zipcode; run;

Thanks!

[FreelanceReinh]

Hello @AnnHarper and welcome to the SAS Support Communities!

Yes, this syntax looks unfamiliar to people (like us) who started with SAS version 6 or earlier because it's one of the "Changes and Enhancements" from version 7:

• "ability to refer to a permanent SAS data set with the actual physical filename rather than a SAS library reference"

I think a big advantage of the traditional, concise libref.memname syntax is its portability: Unless the libref is assigned explicitly in the same program, the code can be used without any change in different environments (e.g., development vs. production, different computers, operating systems or SAS versions -- remember .sd2 files).

Also, to refer to the library of a dataset (e.g., in PROC DATASETS or when using certain DICTIONARY tables) you would need to know the libref that SAS automatically generated (something like WC000001) if no user-defined libref for the path existed.

[PaigeMiller]

If you will have to refer to many SAS data sets in a folder, then using a libref to refer to them is less typing and less error prone than typing something like 'C:\zipdataset.sas7bdat' each time (and typically, the full path name is longer than that).

[mkeintz]

Another advantage of a LIBNAME statement approach is that the libname can be told to use an input data library engine other than native sas (teaching MPH students?  Maybe some of them have SPSS files hanging around).  I suspect that the use of the use of a physical file name for most procs is restricted to native sas data files.

[Reeza]

Why is this best practice?

Because files move around. If files are moved you just update your lib reference and you then don't have to change the path to every file. This is especially important when you work in systems that may have a development and production environment where the files are entirely in separate locations. Or if you have students submit homework and need to test 100 students code and don't want to change the path to the source files in every students code.

[PaigeMiller]

Good point from @Reeza ! In a related matter:

Out here in the real world, we don't store files on the C: drive. We store files on servers, and server names and paths to the folder change from time to time. I have had that happen about 3 times in the last 10 years. By having fewer things to change, and fewer places to make the changes, you help yourself in the long run by using libnames.

The libname in all of my programs begins with "&pers" which is the path (currently) to my server location where all my files are stored. It looks something like this:

libname myfiles "&pers\project 1";

Macro variable &pers is set in my autoexec, so if the path the my personal folder on the server changes, I only need to change that macro variable, and all my code will then point to the proper folder. I don't have to change each libname statement, and I don't have to change the path name in DATA='C:\zipdataset.sas7bdat';

This also works well if your code has to switch from development to production systems.

[Ksharp]

It is not a big deal. Similar code like this ?

data 'c:\temp\temp.sas7bdat';
 set sashelp.class;
run;

data 'c:\temp\temp';
 set sashelp.class;
run;