I am using SAS on Demand for Academics, which is online (if it makes any difference). I am running the following code:
/*import dataset*/
proc import datafile="/home/********/cars.csv"
out=work.cars
dbms=csv
replace;
run;
and i get the error:
ERROR 14-12: Invalid option value EN_CY for SAS option LOCALE.
Please anyone that can help how to solve this? I have already changed the default language to English on Google.
You can set the locale with an options statement, so that should be easy enough.
options locale=English_UnitedStates;
Or whatever the right locale is. See this table for the list of all possible locales; make sure it matches the OPTIONS ENCODING value.
Related
I am attempting to format variables in SAS studio which have been truncated due to the name being longer than 32 characters, when I attempt to format the variables in SAS studio it gives the warning 'this variable in uninitialized'. when I run the same code in SAS EG against the same excel document imported, the code works fine and formats the variable. Why would the same code in SAS studio not work?
code:
data test;
set test1;
format 'variable'n best12.;
run;
Compare the value of option VALIDVARNAME in EG vs Studio. Set it in studio to the same as EG.
Two common ways to view the current setting of an option. Proc OPTIONS or function GetOption
proc options option=validvarname;
run;
%put %sysfunc(getoption(validvarname));
The code won’t be the same because you’re using two different applications with different default settings most likely. As someone else indicated, it’s likely the validvarname option that’s the issue. I would recommend setting it to V7 which avoids these issues. With this setting, SAS converts them to valid variable names by default and you can avoid the rename step entirely.
Supposedly the 32 char limit will be lifted in SAS 9.5. No release date has been announced, SAS 9.4 M5 was recently released so I’m not expecting it super soon.
I am trying to import an excel sheet into sas9.4. Interestingly, I can import most of the data without any problem. But for the date, there are lots of random missing values (there is no missing date in my excel file). Can anyone tell me how to improve my code please.
proc import out= sheet
datafile = 'D:\Date.xlsx'
dbms = excelcs replace;
sheet = "abc" ;
SCANTEXT=YES;
USEDATE=YES;
SCANTIME=NO;
run;
all date looks like this:21/06/2010, 22/06/2010.
Change your DBMS to XLSX and USEDATE to No. Then you'll import the field as a text field.
You can then use an input() function to create a new date variable.
Not ideal, but easily accomplished.
More than likely, your problem is that the automatic conversion is considering those mm/dd/yyyy, but of course they are actually dd/mm/yyyy.
One possible solution is to use the SASDATEFMT option, documented here:
proc import file="myfile.xlsx" out=dataset dbms=excel replace;
dbdsopts="sasdatefmt=(varname=DDMMYY10.)";
run;
That sets the SAS format, but is also alleged by the documentation to affect the informat used to convert it.
It's also possible, though, that your data is actually mixed character/numeric (as it would be if they were entered by hand into excel, in an excel that was expecting mm/dd/yy, and instead were dd/mm/yy). In that case, the simplest answer is to either change your registry to tell Microsoft to scan the whole column (see this SAS tech support note for example ), or to simply convert all of the values to character (or at least the first couple), and then add a mixed=yes; line to your proc import statement.
(The registry setting may not have an effect if you're using PC Files Server, which you may be given the excelcs dbms above. In that case, ignore that particular suggestion.)
I have exported an Enterprise Guide project to Data Integration Studio.
When I run it I get:
Error: The format CHAR was not found or could not be loaded.
Is there any way to fix it without changing the EG project's code?
Thanks,
Gal.
* Edit *
Code exported is very similar to this:
Proc sql;
Create table a as
select put(field_name,char6.) as fn
from source;
Quit;
The EG project isn't mine
and I rather not touch it, as long there's a better solution.
If field_name is text, this should work. But, if it is numeric, you will get this error:
ERROR 48-59: The format CHAR was not found or could not be loaded.
I am guessing that the field_name is supposed to be character, but has somehow come out as numeric. This could happen, for example, when you import from Excel.
If you create a numeric format with the correct name, the code should work.
You can do this by first finding the library that the formats reside:
proc options option=fmtsearch;run;
The code above will tell you the libraries that SAS search for formats. For example, the library APFMTLIB could be one. If you have write access to this library, you can create a permanent dummyformat with this code:
proc format lib=APFMTLIB;
value char;
run;
Now the EG project should work. Hope this helps
Hopefully someone out there will have run into this before. I'm trying to use the street level geocoding capability of SAS' PROC GEOCODE, but I keep getting a cryptic error. I couldn't find anything on the net about it (although to be fair I only spent a half hour looking).
First, I'm using SAS Enterprise Guide (I've tried on both v4.2 and v4.3), although I still prefer to program as I find the point and click interface quite limiting. Maybe this right here is my problem?
Anyway I first get the lookup data sets from http://support.sas.com/rnd/datavisualization/mapsonline/html/geocode.html and follow the instructions in the readme. I also use the pre-written SAS program to import the CSV files. My input dataset contains just 4 variables: street address, city, state, and zip. I then run the following code:
libname josh 'C:\Users\Josh\Desktop\Geocode\SAS files';
proc geocode
method=street
data=SASUSER.Home_Policy_Address_Detail
lookupstreet=josh.USM
out=test;
run;
However I get this error:
ERROR: Variable NAMENC not found in JOSH.USM data set.
Nowhere in the readme or the import program is a variable named "NAMENC" ever mentioned. This is what has me stumped. Is it something wrong with the simple PROC GEOCODE program I wrote? Is it due to me using SAS EG (although I've yet to run into a base SAS procedure that hasn't worked on EG)? Or something else?
Any help/guidance would be much appreciated. Thanks in advance!
Check your SAS version. You can use the 'Help' menu in DMS mode or submit this statement:
%put &sysvlong;
It looks like you are using SAS 9.3 but your lookup data JOSH.USM is the lookup data formatted for SAS 9.4.
PROC GEOCODE street lookup data comes in two slightly different formats, one for SAS 9.3 and another for 9.4. When you download the nationwide lookup data from the SAS MapsOnline geocoding page, make sure to download the version appropriate for your SAS release.
I'm having large headers for my columns like the one below (it is only a sample as I have 2000 columns with as many headers).
Each column is separated by a semi-colon.
BAL_RT,ET-CAP,EXT_EA16,SEXL-SA,UK;BAL_RT,ET-CAP,EXT_EA16,IBON-SA,TA;BAL_RT,ET-CAP,EXT_EA16,TARO-SA,XR
1;7.2;3
35;8;0.99
I'm using the following command line in SAS to do the import
options macrogen symbolgen ;
PROC IMPORT OUT= Work.fic38_fic1
DATAFILE= "C:\cygwin\home\appEuro\pot\fic38.csv"
DBMS=DLM REPLACE;
DELIMITER='3B'x;
GETNAMES=YES;
DATAROW=2;
GUESSINGROWS=32767;
RUN;
proc sort data=Work.fic38_fic1 ; by date ; run ;
However, for some unknown reasons, the headers got truncated.
BAL_RT,ET-CAP,EXT_EA16,SEXL-SA;BAL_RT,ET-CAP,EXT_EA16,IBON-SA;BAL_RT,ET-CAP,EXT_EA16,TARO-SA
I read the internet and they were talking about the option LRCL.
Does it make sense to anyone?
Any help will be appreciated.
Cheers.
It sounds like the issue is actually that you have 34-50 character wide variable names. SAS has a maximum of 32 characters for variable names, so you will not be able to use the entire length in the variable name. You may be able to use it as a variable label, but likely you would need to code that yourself if PROC IMPORT isn't going to do it for you. You could take the code out of the log and use that code with the additional text added by hand if you like.