It would be nice to be able to optionally extend the standard file properties shown in Enterprise Guide File Explorer. Out of the box EG gives you Name, Type, Modified and Size (see screenshot below).Presumably there is an OS level command such asd dir or ls going on under the hood and some file information is subsequently being thrown away. File details such as owner and permissions would be very useful to see.
If my idea is implemented then if an ordered list contains a node which has an error in its log, then the ordered lists's icon would also have red "X" l. Now, if, instead, there are any nodes in the same ordered list with a warning in the log, then the ordered list's icon would have a yellow triangle just as that(those) particular node(s) do because of the warning in the log.
Recently it has come to my attention that the SAS UE VM can run out of space in /tmp permanently, as revealed here: https://communities.sas.com/t5/SAS-Analytics-U/How
I am really surprised that SAS has not implemented a mechanism that cleans up any remnants of crashed previous workspace server sessions when the VM starts (which is basically a system boot, I think).
So I suggest that at least running the cleanwork utility is implemented at startup of the SA UE VM.
The ability to automatically bin values in maps.
This would allow users to control how sizes and colours are assigned to maps, giving much more control over the way the maps look.
Users would ideally have following options:
Equal sized ranges
User specifies number of ranges and VA automatically calculates the boundaries and groups items
User specifies the boundaries for ranges to use as bins
Equal sized bins
User specifies the number of bins and VA automatically calculates ranges that group equal numbers of items together.
VA calculates the median and then sets ranges at 1 SD intervals
All above options would need to work dynamically and auto adjust if the user filtered the map content.
Below is a screen grab from a popular GIS that offers this functionality
I think it would be a great improvement when dealing with Metadata Folders to be able to create shortcuts to specific folder locations. Oftent the desired Metadata Folder location can be down a very long and complex path. allowing a user to create a shortcut in their [MyFolder] folder to a Metadata Folder location would increase speed of access and reduce the number of "wrong turns" down the Metadata Folder path.
Such a facility would be the equivalent of a Shortcut in Windows Explorer, a Favourite in Internet Explorer or a Bookmark in Firefox.
We all know that SAS develops its software in separate teams, but it can be really annoying when it becomes apparent that several associated teams haven't planned together how a SAS procedure will work.
I'm going to take as an example PROC IMPORT, which is part of Base SAS, but is also included in SAS/ACCESS. When you run the following program all the variables created begin with VAR, i.e. VAR1, VAR2, VAR3, VAR4, VAR5, etc., and this would also be true for DBMS=TAB and DLM:
PROC IMPORT FILE = "test.csv" DBMS = CSV REPLACE; GETNAMES = NO; RUN;
However, using similar PROC IMPORT code for DBMS=EXCEL, in SAS/ACCESS for PC Files, will create variables beginning with F, i.e. F1, F2, F3, F4, F5, etc.:
PROC IMPORT FILE = "test.xls" DBMS = EXCEL REPLACE; GETNAMES = NO; RUN;
More shocking though is using PROC IMPORT code for DBMS=XLS or XLSX in UNIX or Windows, in SAS/ACCESS for PC Files, as this will create variables with no prefix at all, i.e. A, B, C, D, E, etc.:
PROC IMPORT FILE = "test.xls" DBMS = XLS REPLACE; GETNAMES = NO; RUN;
This inconsistency even extends to using GETNAMES = YES too when there are multiple columns with the same label.
If you want to import a CSV file, instead of an Excel file, or indeed import an Excel file in UNIX, then the subsequent processing step will have to be updated to use the new variable names (annoying!). Why can't the procedure be consistent, or, at least, have a parameter, like PREFIX=, that allows users to choose the prefix?
Suggestion 1: Change sub-option SHEET_NAME behavior so that when used after the first ODS EXCEL statement ODS system creates a new worksheet with the given name for which subsequent ODS output will be placed.
Suggestion 2: Make an option named NEW_SHEET, which does as it says, creates a new worksheet for which subsequent ODS output will be placed. Sub-option SHEET_NAME should beable to name the new sheet.
Suggestion 3: make a new sub-option SHEET_INTERVAL="BREAK_NOW", which imeadiately creates a new sheet for which subsequent ODS output will be placed. Sub-option SHEET_NAME should beable to name the new sheet. SHEET_INTERVAL option could be called "BREAK_NOW", "BREAK_NEXT" (thinking in terms of "page breaks" or "sheet" breaks), "ON_NEXT_PROC", "ON_NEXT_OUTPUT" ... "NEW", etc.
Using EG is like walking on glass shards, so I will not attempt to list all the deep cuts and all the paper cuts one has to continuously deal with. Still, one is annoying and repetitive enough that I must take the time to raise it here:
When deleting a table, one is sometimes told that the table is locked, as seen above.
The table is not visible in the process tree even though it is opened (without being identified) by one of the programs, and the easiest way is then to go back to the process flow view, search for the table somewhere in the flow, delete its shortcut there, and then one can delete the table proper.
Please provide a prompt instead of this ludicrous "unexpected error".
I have been working with SAS now about 2 years. Coming from other softwares like SATA, I loved the flexibility of SAS code, the diversity and the power.
However, many things could be imrpoved, especially when it comes to the way SAS uses/displayes the data variables/table columns.
STATA had a great feature: It displayed the names of the data variables / tables columns headers in a tab so that you dont need to remeber them or get en error when you misspell them. Double clicking the variable name in STATA inserts it into the line code directly, which is very handy
This becomes very frustrating in SAS when you are working on multiple projects, each of which might have several tables and tens of variables.
SAS enterprise with its Intellisense/auto-complete, but nevertheless the feature dosent always solve the issue (still needs improving)
I am wondering whether there is a way in SAS to get the variables displayed like STATA or is it a feature that should be requested to make life easier when using SAS?
SAS Studio (online version) dose have this feature by the way... though you cant double click it to insert into code text like STATA
Some functions truncate strings in PROC SQL:
data TEST; length X $300; X=repeat('X',299); run; proc sql; create table WANT as %* Var Len; select trim(X) as TRIM %* 300; , translate(X,'a','b') as TRANSLATE %* 300; , scan(X,1) as SCAN %* 300; , left(X) as LEFT %* 300; , prxchange('s/a/b/',1,X) as PRXCHANGE %* 200; , cat(X) as CAT %* 200; , case when 1 then cat(X) end as CASE %* 200; from TEST; quit;
But this can be fixed in some cases by forcing the variabel length:
proc sql; create table WANT as %* Str Len; select trim(X) as TRIM length=300 %* 300; , translate(X,'a','b') as TRANSLATE length=300 %* 300; , scan(X,1) as SCAN length=300 %* 300; , left(X) as LEFT length=300 %* 300; , prxchange('s/a/b/',1,X) as PRXCHANGE length=300 %* 300; , cat(X) as CAT length=300 %* 300; , quote(X) as QUOTE length=302 %* 302; , case when 1 then quote(X) end as CASE length=302 %* 0 <==; from TEST; quit;
The case statement however does not pass on the defined length to the executed function. It should.
In MySQL, you can use the group_concat function to concatenate across rows with a by group. I think this would be a valuable addition to the functions available in proc sql.
create table EXAMPLE as
select ID, STRING, group_concat(STRING) as ALL_STRINGS
group by ID;
Currently, just a few options (they don't all appear when running proc options group= errorhandling allow to decide how message are displayed in the LOG (I am not too sure what the last 2 do...), like:
Issues a warning message for an unresolved macro reference.
Issues a warning message when a macro variable reference does not match a macro variable.
Specifies the maximum size that user-created formats and informat names can be before an error or warning is issued.
SAS issues an error message and stops processing if the SORT procedure attempts to sort a _NULL_ data set.
Specifies the error level to report when a variable is missing from an input data set during the processing of a DROP=, KEEP=, or RENAME= data set option.
Specifies the error level to report when a variable is missing from an output data set during the processing of a DROP=, KEEP=, or RENAME= data set option.
Issues an error message and stops processing when a SAS data set cannot be found.
Specifies the type of message that is issued when MERGE processing occurs without an associated BY statement.
Specifies the type of message to write to the SAS log when a variable is not initialized.
Specifies the type of message to write to the SAS log when the length of the variable that is being read is longer than the length that is defined for the variable.
Specifies the type of message that PROC DS2 generates.
Displays a transcoding error when illegal values are read from a remote application.
SAS issues an error message when a BY variable exists in one data set but not another when the other data set is _NULL_.
We need more ways to customise how messages are displayed in the LOG when some events are flagged.
Some of the messages we consider worthy of a warning (some signal a fact that can't even be fixed!) include:
WARNING: The intervals on the axis labeled XXX are not evenly spaced
WARNING: The enhanced date axis procedure has failed
WARNING: Compression was disabled for data set
They give us a hard time for monitoring automated production jobs.
On the contrary notes like these are flagged as show-stoppers:
NOTE: MERGE statement has more than one data set
NOTE: Library XXX does not exist.
NOTE: SAS went to a new line
NOTE: DATA STEP stopped due...
It would be nice to be able to raise valid alarms and avoid false alarms by setting the type of message for the various messages that SAS produces.
Currently VA doesn't allow users to use existing aggregated measures when creating new ones (i.e. it cannot perform an aggregation on an aggregation). The only solution is to perform these calculations prior to uploading the data to LASR, which can be prohibitively resource intensive when dealing with a large number of possible variable combinations.
This feature would give designers much more control when creating new measures within VA and provide workarounds for many complex data requests.
When I make a format, about 99.9% of the time I expect it to be exhaustive of the values that will be encountered. It would be nice to be able to define a format that would throw an error to the log if a value was not found.
proc format; value sex 1='F' 2='M' other=_ERROR_ /*pseudo code*/ ; run; data have; input sex ; cards; 1 1 3 ; run;
When the format is used, it would throw an error to the log. So below PROC step and DATA step would both throw errors, ideally listing the invalid value:
proc freq data=have; tables sex;
format sex sex.; run; data want; set have; sexC=put(sex,sex.); run;
I know there are alternatives, e.g.,
data want; set have; sexC=put(sex,sex.); if sexC="_ERROR_" then put "ERROR: invalid value " sex=; run;
But it would be nice to have a way to say when a format is created, "if any value is outside the domain of values defined in the format, throw an error [or warning or note]."
It's very helpful to name your graphic images in a consistent way when creating items in SAS/GRAPH with a name statement. Currently we are limited to 8 characters. It would be great to go to 32 characters as for variable and data set names. I'm old enough to remember when we were limited to 5 characters for variable names on some antiquated systems (i.e. UNIVAC) so I'm pretty good at trimming down names but I'd rather not have to!
The datetime output is identical to that of the E8601DTw.d format except for the T separator.
"yyyy-mm-dd hh:mm:ss.ffffff" instead of
A format generating the same output for date (and time?) variables would be useful too as some tools like Impala can only use timestamps, not dates.
I know this can be done using a picture format. Doing so makes the code a lot less portable though.
I think it is long overdue that SAS adds support for at least the .ods file format.
Enterprise Guide for export and import
SAS Studio the same
PROC EXPORT and PROC IMPORT
LIBNAME ODS (working like libname xlsx)
Since the core of the ods file format is compressed xml, just as in the modern Microsoft Office formats, this should not be very hard to achieve.
If I edit a program entry in EG, I have find, replace, and line/column numbers (and perhaps other features).
If I edit the SAS code for a stored process in EG, I get a crippled editor with none of these features.
I have a stored process that's 1000+ lines long. If I get an error in the log, it would be handy to be able to search the code for the offending line. If I'm trying to get the indentation right on a block of code that doesn't fit in the editor, having the column number would help.
In short, have *consistent* editor functionality in both scenarios (as well as any other place in EG where you can edit code).
can we have a function named lead which does the opposite of lag.
input a b;
Ouput should look something like this
a b c d
1 2 . 4
3 4 2 6
5 6 4 .