SAS Forecast Studio is a programming tool that is used for business intelligence forecasting. It (presumably) generates SAS code on the back end that then produces the output.
Is there any way to get access to the generated SAS code that was used to produce the output, and save it as a .SAS file, a program in the project, or to the clipboard?
Late answer, but I hope it can be useful for someone;
The SAS code is available from the Forecast Studio.
Access your project, click "Project" in the menu bar and select "SAS Code..."
Related
Need a free editor or tool to read/open .sas7bat or .wpd files.Trying to open/read a sas files.I don`t have SAS installed
tried using sublime and notepad++
SAS provides a tool called SAS® Universal Viewer
From the link:
The SAS Universal Viewer is a replacement for the SAS System Viewer. The SAS Universal Viewer enables you to view, sort, and filter SAS data sets and other simple text-based files. You cannot edit SAS data sets with the SAS Universal Viewer. You do not have to invoke SAS or install SAS on your computer in order to use the SAS Universal Viewer.
The most recent release is SAS Universal Viewer 1.42.
You can use this free tool: www.clinbay.com/datasly which allows to open SAS datasets in .sas7bdat and XPT formats, and also export them to Excel format as well.
You can pull them into R using the Haven package (part of the tidyverse)
https://cran.r-project.org/web/packages/haven/readme/README.html
I was wondering if there is a easy and fast way to get the code from the programs that I have created in SAS Enterprise Guides process flow?
I am creating the program in SAS Enterprise Guide, and then creating a script for later usage in SAS, as I am not strong enough to program it from scratch.
At the moment, I am opening each step and copying the code, but there must be a faster way.
Any suggestions?
Thanks
This is an option in the File menu:
File -> Export -> Export all Code in Process Flow
If you rename the file from an EGP to a .zip and then open the file you'll see you have folders relating to objects in the EG project.
You can then pull extract these pieces of SAS code and rename as necessary.
I've also seen some software which can examine EGP files if you do a search.
This has been updated instead of File -> Export -> Export all Code in Process Flow.
You can find this under the Share button in the Process Flow tab.
Share -> Export all Code in Process Flow
There is a 'Code Coverage Results' window in Visual Studio which allows you to view the contents of a *.coverage file (generated by one of the VS performance tools). I was wondering if there was a way to export the Code Coverage Results to excel for further analysis. The tools in the Code Coverage Results window seem somewhat limited and was wondering if I was missing something.
I've queried quite a few statements and cannot find the answer I was hoping to find. There were three main questions which did not seem to have answers:
Can you search the data within the code coverage results? The typical VS search will not allow you to search within the Code Coverage Results window
Can the Code Coverage Results be exported to excel, or as a *.csv file? If not, then can the *.coveragexml file (which seems to be the only export option) be imported into excel in a way that i would get a table similar to the one in the Code Coverage Results window?
Is there an 'Expand All'/'Collapse All' button for the Code Coverage Results window? It would be nice to be able to expand all of the Code Coverage Result tree if possible ... or at least be able to expand a group of branches which have been expanded.
Any suggestions/input would be useful.
What you can do is this:
Export to XML (I renamed it to ...coverage.xml so it is recognized as an XML file but not sure if that's necessary)
Load with Visual Studio
Format in VS (Ctrl+K, Ctrl+D)
Now you can open this in Notepad++ for example (or any other good XML viewer). There you choose to close or open all text blocks.
In the enhanced editor, the coloring might give you a hint. However, on the mainframe I don't believe there is anything, in the editor, that will help you.
I use
OPTIONS OBS=0 noreplace;
The obs=0 option specifies that 0 observarions are read in from the input
dataset and NOREPLACE tells SAS not to overwite an existing SAS dataset with one of the
same name. If you are creating a new datastet, it will be created with all the attributes,
but with 0 observations. (Be sure to reset the options, if needed, to Options Obs=max replace ; when no more syntax errors are found).
I'd be interested in any other techniques.
Thanks
Explanation about options came from here.
I use the cancel option on the run statement. It will check the syntax of the data step then terminate it without actually executing it. It's the data step analog to the noexec option in proc sql.
data something;
<stuff here>
run cancel;
Lots more details in this SUGI pdf
I write all of my code on my PC with SAS on my PC and the enhanced, color coded editor. I then use SAS/CONNECT to process it on the mainframe. If the datasets are on DASD, I use SAS/CONNECT and Enterprise Guide to directly run the code onthe mainframe (no JCL!) If there is a data tape involved and therefore must be a batch run, I use SAS/CONNECT and the SAS ftp engine to send the code to the mainframe batch queue. I use the SAS email engine to email me back my output and my log. I put and ODS sandwich aound my code to have the mainframe generate a WORD document for output. I use a PROC download to download the output to my server so I can open it in WORD.
This advice is language agnostic.
I would argue that a preferable technique for catching syntax (and logic) errors is to perform a close read (or inspection) of your own code (which should catch the majority of syntax errors), followed by unit tests on small datasets (which will catch any remaining syntax errors, as well as many logic errors if your tests are well-designed).
I agree there's some worth to syntax checking in isolation, but to read and understand your code thoroughly enough before the first compile so that you know it will compile is a good ideal to strive for. Steve McConnell touches on this idea in Code Complete (see page 827 of the 2nd Edition).
P.S. You mentioned syntax highlighting in your original post; there are other editors (such as VIM) that will perform syntax highlighting on SAS files.
I want to create templates for base new reports on to have common designs. How do you do it?
The need to produce reports with a common starting design and format is key to any project involving clients and their reports. I have been working on reports for over 10 years now. This has not been the largest portion of my jobs through the years but it has been a very import one. The key to any report project is not to recreate the mundane aspects of the reports for each but to use templates. The use of templates is not a common task or knowledge for Microsoft's SQL Server Reporting Services. Knowing how to save reports templates so that you and your team can create these shortcuts at the creation of a new report in Visual Studio 2005 will help save time and have all reports use the same layout and design.
Create of a set of reports with the following suggestions:
Page size -- 8.5 by 11 (letter) and 8.5 by 14 (legal)
Orientation -- portrait and landscape for all paper sizes
Header -- Text Box for report name, Text Box for report subtitle, client or brand logo
Footer -- page number/total pages, date and time report printed
Take all the rdl files for the reports created from the suggestions and copy the files to the following directory:
C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\ProjectItems\ReportProject
When creating a new report in your Visual Studio 2005 report project through Add|New Item
alt text http://www.cloudsocket.com/images/image-thumb14.png
The new report dialog will present the list of items from the directory where the new templates were placed.
alt text http://www.cloudsocket.com/images/image-thumb15.png
Select the report that fits the requirement needed and proceed to develop your reports without needing to create the basics.
Further more, I would suggest wrapping up your template perhaps with externally linked images into an .msi for easier distribution. It is a lot easier to ask people in a department to run an installer than it is to hope they find the right path to put the reporting template in. Make sure you use the proper program files variables etc to account for "Program Files" vs "Program Files(x86)" and other variations users sometimes do with their environment variable settings.