I am trying to use SAS Studio in VirtualBox, when I run certain scripts though- I get numerous errors. Namely, when I run the following code:
proc import datafile = "UTDCASESTUDYDATA1.xlsx"
out = ti
dbms = excel;
run;
I get the error:
ERROR: DBMS type EXCEL not valid for import. NOTE: The SAS System
stopped processing this step because of errors. NOTE: PROCEDURE
IMPORT used (Total process time):
real time 0.01 seconds
cpu time 0.00 seconds
I am wondering, what is the functionality of SAS Studio compared to the normal desktop version of the program? For example, when I try to run PROC ASSOC or certain plotting functions, I get an error that the function is "unavailable" so Im wondering if these procedures are simply limited from SAS Studio or if I have syntax errors.
Any help is appreciated.
You can use the XLSX engine instead of the EXCEL engine to directly read XLSX files without having access to Microsoft products.
Sounds like you are using SAS University Edition. PROC ASSOC is not available in that because it requires a license for Enterprise Miner.
See this thread on SAS Communities
https://communities.sas.com/t5/SAS-Procedures/Association-analysis-proc-assoc-and-proc-rulegen/td-p/122287
Related
I am currently working on optimizing a script in SAS EG.
The script basically has to be run for each month since 2012 on a daily-basis.
Up until 2022 the code for all periods took less than 24 hours to run but every now and then, it exceed this treshold.
The process (which is a macro) is structured as follow:
Retrieve data from several Oracle tables
Transform (transpose/concatenate...)
Compute statistics based on explicit rules
Delete statistics for the given month in Result Oracle table
Insert the new statistics for the given month in Result Oracle table
The reason why it takes so much time is because we run the program sequentially, looping on every periods.
%macro run_all_periods;
%let start_date = 31jan2012; * define start date;
%let i = %sysfunc(inputn(&start_date, date9.)); * date format;
* define last date to be considered ;
%let today = %sysfunc(inputn(%sysfunc(date(), date9.), date9.)); * today;
%let last_date = %sysfunc(intnx(month, &today,-1, e)); * last period to be considered;
%do %until (&i > &last_date); * do loop for all reference periods until last_date;
%let date=%sysfunc(putn(&i, date9.));
%run_script(period=&date);
%let i = %sysfunc(intnx(month, &i, +1, e)); * following period;
%mend;
As the periods are independant to each other (i.e., it doesn't matter the order for which it run) I think that it would be better to run all periods in parallel instead of optimizing the script in itself.
Therefore, is there any way to run the same script in SAS EG in parallel with different argument (in my case periods)?
At the same time, we are currently testing SAS Viya at work. While looking into the functionnalities, I found out about the Background Submit.
You can run a saved SAS program, query, task, or flow as a background submission, which means that the file can run while you continue to use SAS Studio. You can view the status of files that have been submitted in the background, and you can cancel files that are currently running in the background.
And the associated note caught my eye:
Note: Because a background submission uses a separate compute server, any libraries or tables that are created by the submission do not appear in the Libraries section of the navigation pane in SAS Studio
Would it be possible to leverage this functionnality to run several times the same script in background with different periods ?
There are at least ten different ways to do this, both on SAS 9.4 and SAS Viya. Viya is a bit more "native" to this concept, as it tries to do everything as parallel as possible, but 9.4 would also do this no problem.
Command line submission - you can write a .bat/.ps1/shell script/etc. to run SAS for each of your jobs, and submit them all in parallel. That's how we do it usually - we call SAS once for each job.
SAS/CONNECT - using MP CONNECT, this is very easy to do. Just make sure you have it set up to run things in parallel and not wait until the point you want it to wait for (if any exists).
Grid multiprocessing - using the SAS Grid Manager. Not that different from how SAS/CONNECT works, really. You use PROC SCAPROC to analyze the program and identify splits, or just do it yourself.
Background submits in SAS Studio - this is possible in both 9.4 and Viya. Each job is in a separate session. This is somewhat manual though, so you'd have to submit each job by hand.
Use Python to do the parallelization, then SASPy (94) or SWAT (Viya) to submit the SAS jobs.
Directly call SAS (using x command) for each of your sub-jobs
Use EG's built in ability to run multiple processes at once - see The SAS Dummy for more.
Use EG's scheduling interface to run multiple jobs
Use the built-in SAS Scheduler to run the various jobs
Modify your script to use BY group processing so that you can do the whole thing at once but still take advantage of efficiencies (some jobs this will work for, some it won't).
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 suddenly got an error message when exporting from SAS to Excel. I've been using the code below.
libname xls excel '..\Test.xlsx' ver=2007;
proc datasets lib = xls nolist;
delete Sweden;
quit;
data xls.Sweden;
set WORK.falcon_cases_2;
run;
libname xls clear;
This is what the log says:
NOTE: SAS variable labels, formats, and lengths are not written to DBMS tables.
ERROR: Execute: Unable to insert row
NOTE: The SAS System stopped processing this step because of errors.
NOTE: There were 4865 observations read from the data set WORK.FALCON_CASES_2.
WARNING: The data set XLS.Sweden may be incomplete. When this step was stopped there were 4864
observations and 14 variables.
ERROR: ROLLBACK issued due to errors for data set XLS.Sweden.DATA.
That's the error message I got. I've googled the error message and it seems like it usually indicates that the data set contains to many rows for Excel, 65 000 something. The data set I'm trying to export is only about 5500 rows.
Thanks for your help!
Things I would look into:
Funny characters. Excel might have had a transcoding problem if there are unicode characters in the data that don't transcode properly to wlatin1 (or whatever your default encoding is for Windows).
Disk space. Did your disk run out of space while running this?
Network or disk corruption. Is this replicable (does it occur if you try again)?
Can you try running that code on a basic dataset, like sashelp.class? Does that still cause the problem?
I have data inside SAS.
I want to store the datafile to SPSS format (*.sav)
I use the following program:
PROC export Data=SASdataToStoreInSPSS
FILE="Path\Filename_%sysfunc(today(),date9.).sav"
dbms=sav replace;
RUN;
This works great. Except when I open the file in SPSS the dates are strangly formatted.
For example:
156405 08:51:00
Should be
3-Jan-2011 08:51
I can manually change the data formats in SPSS. So the values are correct date values, except they are not automatically formatted in a readable format.
I tried to change the format in SAS before saving to DATETIME20. or DATETIME23.3. But this does not help.
I want this to work without having to open SPSS and run a Syntax there.
The SPSS files that SAS spits out have to be directly mailed to other users of the data.
I think this is either a bug with SAS's export, or an issue with SPSS where some default changed. What's happening is that SAS is storing it as a SPSS Date - but with width 16, which is not long enough to hold the complete datetime. I don't think you can use DBDSOPTS with DBMS=SPSS, so I don't know that there is a good workaround short of importing the file into SPSS.
You could do that automatically, though, using the SPSS Production facility; I've written an import script before and asked SAS to run spssprod with the batch file. That's an irritating workaround, but it might be the easiest, unless SAS Tech Support can help you (and certainly try that - they are usually only a few hours' turnaround for initial contact at least).
SAS mentioned it has to do with the SPSS driver they use. Apparently it is not an easy fix so they forwarded the issue to second-line tech support.
The workaround you will need is split the dates in two columns. One with date and one with time.
data SPSS2;
set SPSS;
date = put(datepart(DatumSPSS), date9.);
time = put(timepart(DatumSPSS), time8.);
run;
Or you can tell the end user how to change the format of the date in SPSS.
For an automated approach, try this .NET app. You need SPSS, but SAS is not required to convert a large collection of SAS files automatically.
Manual Process included code samples or Application Download
I have a lot of files in SAS format, and I'd like to be able to read them in programs outside of SAS. I don't have anything except the base SAS system installed. I could manually convert each one, but I'd like a way to do it automatically.
You'll need to have a running SAS session to act as a data server. You can then access the SAS data using ODBC, see the SAS ODBC drivers guide.
To get the local SAS ODBC server running, you need to:
Define your SAS ODBC server setup at described in the SAS ODBC drivers guide. In the example that follows, I'll connect to a server that is set up with the name "loclodbc".
Add an entry in your services file, (C:\WINDOWS\system32\drivers\etc\services), like this:
loclodbc 9191/tcp
...set the port number (here: 9191) so that it fits into your local setup. The name of the service "loclodbc" must match the server name as defined in the ODBC setup. Note that the term "Server" has nothing to do with the physical host name of your PC.
Your SAS ODBC server is now ready to run, but is has no assigned data resources available. Normally you would set this in the "Libraries" tab in the SAS ODBC setup process, but since you want to point to data sources "on the fly", we omit this.
From your client application you can now connect to the SAS ODBC server, point to the data resources you want to access, and fetch the data.
The way SAS points to data resources is through the concept of the "LIBNAME". A libname is a logical pointer to a collection of data.
Thus
LIBNAME sasadhoc 'C:\sasdatafolder';
assigns the folder "C:\sasdatafolder" the logical handle "sasiodat".
If you from within SAS want access to the data residing in the SAS data table file "C:\sasdatafolder\test.sas7bdat", you would do something like this:
LIBNAME sasadhoc 'C:\sasdatafolder';
PROC SQL;
CREATE TABLE WORK.test as
SELECT *
FROM sasadhoc.test
;
QUIT;
So what we need to do is to tell our SAS ODBC server to assign a libname to C:\sasdatafolder, from our client application. We can do this by sending it this resource allocation request on start up, by using the DBCONINIT parameter.
I've made some sample code for doing this. My sample code is also written in the BASE SAS language. Since there are obviously more clever ways to access SAS data, than SAS connecting to SAS via ODBC, this code only serves as an example.
You should be able to take the useful bits and create your own solution in the programming environment you're using...
SAS ODBC connection sample code:
PROC SQL;
CONNECT TO ODBC(DSN=loclodbc DBCONINIT="libname sasadhoc 'c:\sasdatafolder'");
CREATE TABLE temp_sas AS
SELECT * FROM CONNECTION TO ODBC(SELECT * FROM sasadhoc.test);
QUIT;
The magic happens in the "CONNECT TO ODBC..." part of the code, assigning a libname to the folder where the needed data resides.
There's now a python package that will allow you to read .sas7bdat files, or convert them to csv if you prefer
https://pypi.python.org/pypi/sas7bdat
You could make a SAS-to-CSV conversion program.
Save the following in sas_to_csv.sas:
proc export data=&sysparm
outfile=stdout dbms=csv;
run;
Then, assuming you want to access libname.dataset, call this program as follows:
sas sas_to_csv -noterminal -sysparm "libname.dataset"
The SAS data is converted to CSV that can be piped into Python. In Python, it would be easy enough to generate the "libname.dataset" parameters programmatically.
I have never tried http://www.oview.co.uk/dsread/, but it might be what you're looking for: "a simple command-line utility for working with datasets in the SAS7BDAT file format." But do note "This software should be considered experimental and is not guaranteed to be accurate. You use it at your own risk. It will only work on uncompressed Windows-format SAS7BDAT files for now. "
I think you might be able to use ADO,
See the SAS support site for more details.
Disclaimer:
I haven't looked at this for a while
I'm not 100% sure that this doesn't require additional licensing
I'm not sure if you can do this using Python