SAS data set "nonexistent"? - sas

Yesterday I renamed a SAS dataset using my OS. (instead of doing it within a SAS environment). Now, I can see it in my SAS explorer, but when I try to access it SAS tells me that it doesn't exist. I was able to recall the name that I had given the set originally, change it back "manually" and then access it through the interactive SAS environment but, my question:
What the heck is going on here? Is this a flaw in my particular version of SAS or is this just how it is?

Member names in SAS must be valid SAS names. So you couldn't name your dataset 1979data.sas7bdat. You can relax some of the restrictions by setting the option VALIDMEMNAME to EXTEND and using name literals in your SAS code.
But also note that file names on case-sensitive file systems, like Unix, must be all lowercase. So you couldn't use uppercase letters in the name of the file. So SAS would not see a file named OldData.SAS7bdat because if you tried to access a dataset named xxx.OldData it would be looking for a file named olddata.sas7bdat instead.

Related

Variable names incompatible between SPSS and SAS

I imported an SPSS (.sav file) into SAS. Several of the variables are not showing up as they are named things like 'variable___1.1' When i try to KEEP certain variables in a data step, I get an error because these variables create an error as SAS misinterprets the '.'
Has anyone encountered this before or know a way around it?
I can see the problem variables and their values in the .sas7bdat file, so the data imported, I just need to find a way to change the variable name so I can include it in the report.
You use name literal notation, 'variable1_1'n in your code, e.g.
rename 'variable___1.1'n = variable1_1;
Or set this option and reimport your data so that you get better names.
option validvarname=v7;
That will tell SAS to import the data with simpler variable names. Note that I'm not sure if that's two underscores or three or four in the variable name....guessing at 3.

Data does not exist

I'm facing a very weird problem.
I've assigned a libname such as
libname TEST_LIB "/Info-One/...." /*have removed the exact location*/
/*The dataset TEST_DATA is visible in this output*/
proc datasets lib = TEST_LIB;
RUN;
/*This statement throws an error saying the file does not exist*/
DATA TEST_DATA_2;
set TEST_LIB.TEST_DATA;
RUN;
I'm running this code in SAS Enterprise guide connected to the remote server.
I'm also able to navigate to the location from File explorer and drag it into Enterprise guide and then the dataset is visible. But even if I double click on the dataset from the defined library then it says that the dataset does not exist.
I've run out of ideas now and I'm not sure how to troubleshoot this.
A couple of things that I've tried/checked
Case sensitivity is not an issue
The filename does not have spaces
I have permissions to the folder because I can work normally with another dataset that I created and placed in that folder
In fact if I copy the data to excel, upload the excel to SAS to create a SAS dataset and place it in the same location with a different name, I face the same issue!!
Would really appreciate any ideas that you guys may have, not just on why its happening, but also how to bypass it
Transferred from comments and expanded
Here are 2 possibilities:
The filename of the data set may contain uppercase. This is an unlikely but possible scenario:
On Unix systems filenames are case sensitive. A data set name in a SAS program will be mapped internally to a corresponding lowercase named data file (those sas7bdat files at the operating system level). If a copy process somehow creates a .sas7bdat data file on Unix whose name is mixed case or uppercase, the SAS session won't map to it. In such a scenario, the SAS file explorer might list a data set, but be unable to open it. However, a direct file reference to the data set might work, such as set '~/project1/datasets/MyWeirdlyCasedDataset';
There is a file permission problem with the folder mount, allowing reading of directory entries (the filenames) but not the file contents (the data sets) within. Try opening a terminal session (putty or mobaxterm) and see what the detailed directory listing is for the data folder (ls -l) You might have to also look at the access control lists (lsacl) and get network and IT admin involved.
Are you sure that is a dataset?
Put memtype=data in Proc Datasets as below
proc datasets lib = TEST_LIB memtype=data;
RUN;

SAS Studio-Dealing with Variable Names that have Spaces

When I load in an excel sheet through PROC IMPORT, locally installed SAS automatically replaces the variable names with spaces to an underscore (_). Such as Patient ID will become Patient_ID and Health Records will become Health_Records.
However, when I load the same file in SAS Studio, that renaming convention isn't applied. So Patient ID and Health Records are kept as is...without the underscore in place.
Thus, how would I call these variables in SAS Studio? A syntax error pops when I try to call IF Patient ID THEN this. Would I have to physically add the underscore to my original dataset or is there an easier way?
The difference is caused by the setting of VALIDVARNAME option.
To refer to variable names with spaces you need to use a name-literal
for example.
"Patient ID"n
Quoted string followed by the letter N.
As #data_null_ notes, VALIDVARNAME=ANY is what is causing this.
If you want SAS Studio to behave like your desktop SAS, simply add
options validvarname=v7;
to the top of your program (or to some program that will run before your imports, like an autoexec). Then your underscores will return.

How to read SAS datasets (not in sas naming convention) imported from access

I have imported Access DB into SAS using Libname.
Libname accdb 'c:\mydata\base.accdb'. All the tables in DB are now in accdb Library now. but table names in Access DB are not matching to SAS dataset naming convention.
My question is how to read those datasets available in accdb.
Thanks,
Ravi
You can try setting the option VALIDMEMNAME=EXTEND. You can then reference the members using name literals such as '00ReadMe'n . This should work for any member (table) name that is 32 characters or shorter. I think that for names that are too long you might just have to either rename them in Access or create views that have shorter names that you can use instead.

SAS: Conditional choice of library

I have the same table name in two different libraries, and I want to use a condition in the beginning to choose what library to use (SAS Enterprise Guide). Is it possible to use a variable for the library to achieve something like below?
IF(txt = 'tst")
Select * from TST.TableName
ELSE
Select * form DEV.TableName
The best way to do this varies based on what defines txt. If you are choosing this based on user input (in your example, user chooses TEST or DEV (or PROD) database to point to), then the best way in Enterprise Guide is to create a prompt to create a macro variable, or secondarily directly create a macro variable.
Ben Cochran's paper Be Prompt Now: Creating and Using Prompts in SAS Enterprise Guide is a good introduction to the topic, as well as other sources online. You can set up a prompt that asks the user which environment to point to, and then it will define a macro variable with a value of your choosing. Then add the prompt to the program that you need it to be related to, and presto, it works.
So in your case, you could have it set a variable &env. that contains the value of the table name (TST or DEV). You could also have it control the libname value itself (so you don't change which libname is used, but you instead change which folder or database the libname points to).
If you're not in EG, or if you don't want to use a prompt for this for whatever reason, you similarly can assign that macro variable yourself.
%let env = TST;
Either way, once you've got &ENV=TST established, you just use it in open code:
proc sql;
select * from &ENV..TableName;
quit;
Or, like I said, you could assign the libname based on the macro variable and use a single libname in code; that's often cleaner, though it leaves its own complications.