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?
Related
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;
I'm creating a stored process in SAS EG for some business partners, but I can't seem to get my dataset to output.
A 'Results' viewer shows up but is blank, and my code works perfectly fine when not using a stored process, but the user has to manually change the macro variable for the account they are looking for. With a stored process I can mitigate users accidentally deleting some code, etc.
I can see in my SAS log that the output dataset is being created with variables and observations, but it doesn't automatically pop up like a typical SAS EG job would. I also have some documentation I received from a co-worker around stored processes, and it seems to me that after successful execution a SAS dataset should automatically output.
One thought: Will a stored process output a dataset if there are warnings in the log? I have warnings presented because I am appending datasets to a base file that isn't created, so the lengths of my numeric variables change.
Here's a snippet from the log..
NOTE: The address space has used a maximum of 5504K below the line and 222716K above the line.
104
105 data tran_last;
106 retain TRAN_DT MRCH_NAME MRCH_CITY AMT_TRAN DEB_CRD_IND;
107 set tran_sorted;
108 output;
109 run;
The SAS System
NOTE: There were 164 observations read from the data set WORK.TRAN_SORTED.
NOTE: The data set WORK.TRAN_LAST has 164 observations and 5 variables.
NOTE: The DATA statement used 0.00 CPU seconds and 51817K.
NOTE: The address space has used a maximum of 5504K below the line and 222716K above the line.
The data set WORK.TRAN_LAST is the dataset I wish to be output so that my user can directly copy/paste from there, maybe I'm missing something apparent, but I can't seem to figure this out.
Version 7.1
The answer was extremely simple. I had to use
PROC PRINT DATA = MYDATA ;
RUN;
at the end of my stored procedure.
However, I have books from the SAS Institute that say you can retrieve an "Output Data" file from a stored procedure instead of the "Results Viewer" using proc print. This functionality must have been taken out with newer versions, or maybe I was doing something wrong.
To fix this issue, I have my SAS connected to an excel file that the end-user will run the program(s) from so that they won't need to worry about the output being "Results Viewer".
I'm trying to move a SAS dataset over to our Linux server from a client. They created it on SAS 9.4, 64-bit on Windows 7. I'm using SAS 9.4, 64-bit on Linux.
If I do
proc datasets library=din;
run;
I get the following in my log
Libref DIN
Engine V9
Physical Name /sasUsr/DM/DATA/SAS_DATA/201510_SSI
Filename /sasUsr/DM/DATA/SAS_DATA/201510_SSI
Inode Number 46358529
Access Permission rwxrwxr-x
Owner Name cvandenb
File Size (bytes) 4096
Member File
# Name Type Size Last Modified
1 SAMPLE_FROM_SSI DATA 131072 09/14/2015 17:07:01
2 TEST DATA 131072 09/15/2015 09:35:59
15 run;
but when I do
data test;
set din.sample_from_SSI;
run;
I get
18 data test;
19 set din.sample_from_SSI;
ERROR: File DIN.SAMPLE_FROM_SSI.DATA does not exist.
20 run;
I also created a dummy dataset din.test and was able to proc print it. This seems to either be a version compatibility issue or transmission issue. I thought this would be straightforward. Any suggestions? I'm moving the file from windows to Linux with WinSCP. I'd rather not have to request a .csv and create the input statement, but will if I have to. Your help is appreciated.
Thanks,
Cory
If you are talking about an actual SAS dataset then make sure that the name of the file is in all lowercase letters and has the extension of .sas7bdat. If the source file from Windows did not have an extension of .sas7bdat then perhaps you are not dealing with a SAS dataset, but some other type of file.
In SAS code it does not matter whether you reference a dataset using upper or lower case letters. So you can reference a datasets as sample_from_SSI or Sample_From_Ssi to refer to the same file. The same is true of general filenames on a Windows machine. But on Unix system file names with different use of upper and lower case letters are distinct files. SAS requires that the filename of a SAS dataset must be in all lowercase letters.
So if you write:
libname DIN '/sasUsr/DM/DATA/SAS_DATA/201510_SSI';
proc print data=DIN.SAMPLE_FROM_SSI;
run;
Then you are looking to make a listing of the data in a file named:
/sasUsr/DM/DATA/SAS_DATA/201510_SSI/sample_from_ssi.sas7bdat
I usually get a note about CEDA in this case not missing data.
Create either a CPORT or XPORT file using the associated proc, PROC CPORT or XPORT and then move that file.
Try referring to the data with all caps as well, which I don't think should be the issue, but is possible.
I would try using PROC COPY directly on the libname, as you can select memtype=data that way without explicitly specifying the file.
If SAS still can't do that, then you might have a permissions issue or something else that is outside of the SAS realm I suspect.
Try using PROC CPORT and PROC CIMPORT.
Use the CPORT Procedure to convert the file into a transport file.
Use the CIMPORT Procedure to convert the transport file to a SAS format.
There is an example that sounds similar to what you are doing here.
According to SAS, the general procedure is:
A transport file is created at the source computer using PROC CPORT.
The transport file is transferred from the source computer to the target computer via communications software or a magnetic medium
The transport file is read at the target computer using PROC CIMPORT.
Note: Transport files that are created using PROC CPORT are not
interchangeable with transport files that are created using the XPORT
engine.
If that doesn't work, or it is taking a very long time to figure out, it would be faster to ask them for a CSV and import it directly using PROC IMPORT. It should read in quite easily, especially if it comes from PROC EXPORT.
I have a "wide" SAS data sets that must be exported into a new Excel workbook every week. I want to preserve the column widths and other Excel attributes every week, but I'm having problems getting it to work. Here's what I'm attempting.
I used PROC EXPORT to create a new workbook (using sheet="New_TACs").
I manually adjusted the column widths and other sheet attributes
(like "filters", column widths, wrap, alignment, and "freeze panes").
I deleted all the data rows (leaving the first row with the column
names) and saved it as a new workbook named "template.xlsx".
Using a SAS system call, I copy "template.xlsx" to "this_week.xlsx".
I use PROC EXPORT again to try and update the new workbook, but I
get warnings. The result contains a sheet named "New_TACS1".
Here is the SAS log:
720 proc export data=new_tacs
721 outfile="\\server-path\this_week.xlsx"
722 replace;
723 sheet='New_TACs';
724 run;
WARNING: The target file may contain unmatched range name and sheet name.
WARNING: The target file may contain unmatched range name and sheet name.
WARNING: File _IMEX_.New_TACs.DATA does not exist.
WARNING: Table _IMEX_."New_TACs" has not been dropped.
NOTE: "New_TACs" range/sheet was successfully created.
NOTE: PROCEDURE EXPORT used (Total process time):
real time 23.88 seconds
cpu time 1.80 seconds
I'm at a loss as to what to do and would appreciate any ideas or suggestions.
I think the issue is that with zero rows, SAS isn't properly dealing with the data. I can't get PROC EXPORT to work at all, but with a single dummy row I can at least get it to behave with libname and PROC APPEND. I wouldn't be surprise if the filters are in part responsible for this.
After creating the blank excel file with the SASHELP.CLASS columns, adding a filter, adding one row of dummy data, and saving/closing, I do: (SCANTEXT=NO is mandatory here for update access)
libname newtac "c:\temp\test.xlsx" scantext=no getnames=yes;
proc append base=newtac.'New_TACs$_xlnm#_FilterDatabase'n data=sashelp.class force;
run;
libname newtac clear;
That gets close, at least. I'm getting some blank rows for some reason, perhaps due to other things I did in looking at this.
Your best solution may well be to wait for 9.4 TS1M0 and ODS EXCEL, which will let you do all these things from SAS directly; or to use DDE.
I would recommend checking out SaviCells. http://www.sascommunity.org/wiki/SaviCells. It provides much better SAS to Excel functionality, including creating a template with all your Excel formatting and using that with new data.
Use DDE in SAS to achieve this.
You can create your excel template the way you want it to appear.
Using DDE you would then:
Open Excel
Open the excel file you want to use as the template
Populate it with the updated data
Save the file as a new filename
It's a bit of an antiquated technology but it gets the job done.
Googling for SAS and DDE will find you plenty of code exmaples and tutorials.
I am using Enterprise Guide 4.2 (no choice about this).
I am using PROC APPEND to append about 80k+ observations to a SQL Server table. I believe that there are some issues with the format of the data (such as mismatching variable lengths), but it executes just fine and the table is updated. Then, Enterprise Guide gives me the following message:
The contents of Log(af771r01 (Process Flow)) is too large to display. The window will close, but the contents will remain in the project.
I was able to successfully disable the log by redirecting it to a dummy file:
** The Append Proc below outputs 80k+ lines (in theory) to the log, crashing EG 4.2;
** This statement will temporarily disable logging;
FILENAME JUNK DUMMY;
PROC PRINTTO
LOG=JUNK;
RUN;
** ========================================================
** Archive Summarized Enrollment Data
** ========================================================;
PROC APPEND BASE = Archive.MnthlyMbrCmpArch (
SASDATEFMT=(SYS_SRC_LOAD_DT='mmddyy10.')
)
DATA = Work.R1_MBR_ENRL_ARCHIVE;
RUN;
** Reenable logging;
PROC PRINTTO;
RUN;
This prevents EG from crashing, but I'm losing all of the warning and error messages. I am trying to debug the statement so I want the warnings and errors, I just don't want a flooded log.
Is there a way to partially disable logging without turning it off completely? Or is there a way to redirect the log to a file so that EG doesn't crash while trying to not open it?
I am new to SAS and am open to any suggestions, even if they do not directly answer the question.
Yes, you can redirect the log to a file by specifying a path in the FILENAME statement (instead of saying DUMMY, which refers to a non-existing file):
FILENAME JUNK 'path/file-name.log';
Of course, you must have "write" permission to the location you specify.
You can suppress a lot of information from the log by using:
options nonotes nonotes2;
And/or:
options nomprint nomlogic nosymbolgen nomacrogen; /* IF CODE CONTAINS MACROS */
Errors will still be printed to the screen but you would have little information to debug them unless you turned the logging back on.
Some SAS Documentation: http://support.sas.com/documentation/cdl/en/basess/58133/HTML/default/viewer.htm#a001906177.htm