About Quentin

Quentin · ‎09-08-2012

I wouldn't think you would need the Excel add-in. I've been playing with for a few months. As I understand it, the Add-In as a way to use Excel as a client which can connect to the SAS server and do stuff. So you if you had folks who loved using Excel (sigh) and you wanted to give them the "Power of SAS" (running SAS PROCs or Stored Procedure on Excel data and returning results to Excel), then the add-in is a solution. But if you're a shop of SAS programmers, who plan to keep being SAS programmers just working on a server SAS instead of PC SAS, wouldn't think folks would be interested in the add-in. That said, I would suggest installing EG. It's not a bad programming environment. Has some benefits (and downside) vs Enhanced editor. But of course you can do very well with just a good text editor and a terminal window... HTH, --Q.

Quentin · ‎09-08-2012

Hi PSI_frank, Can you describe the big picture of what you are trying to do? Is it that you are trying to get a stored procedure to write a "native" Excel file? Looks like the current design is have stored process write a file using tagsets.ExcelXP, and then the VB script opens the file in Excel, and saves it as a native format (.xls or .xlsx)? Didn't see an answer to whether your SAS server is running on Windows or *NIX or other? Might ask yourself whether it is really important to have a native Excel file rather than an xml file with an .xls extension which Excel is happy to open. That said, if you really do want a native Excel file, and cannot run the VB script on the server, you might be better off separating the process into two steps. So stored process could run on server and return xml file(s) to the windows world. Then you could run your vb script in Windows to convert the files. I suppose another option would be to play with the addin. When a stored process is run from the add-in the results come back via xml (SASREPORT format), but end up in a native Excel spreadsheet. And I suppose if you wanted to you could use VB to script Excel to run the stored process, as in: http://www.lexjansen.com/wuss/2011/datapresentation/Papers_Beese_T_76227.pdf HTH, --Q.

Quentin · ‎08-25-2012

@lacrefa, So glad you found my blog post helpful: I find an other linked : http://www.bi-notes.com/2012/07/stored-process-ignore-log-your-own-peril/, this link seems to be the best way to explain the simple way outside more knowledge of SAS components. That was my first post for www.bi-notes.com (actually my first blog post anyhwere), I'm hoping to do a few more soon. I am using 9.3, and get the same results as you do. If I have a stored process that returns a pdf, and call it from SPWA with _debug=131, I see the binary representation of the pdf file in the browswer, followed by the log. It does not prompt me to open/save the pdf. Using PROC PRINTTO to send the log to a file works well for me when I'm developing stored processes. Our SAS server runs on a linux box, and I usually develop from Windows. I use Ultradedit. It can open the log file from the server and keep it open. I can then run the stored process, and refresh the file in ultraedit to see the new log. If I write the log file to somewhere accesible via SAMBA, Ultraedit will automatically refresh it when it changes. And for some production stored processes, I write the log to a file named "%sysfunc(compress(%scan(&_program,-1,/)_&_UserName._%sysfunc(datetime(),b8601dt))).log" So the name of the log file is the stored process name, name of user who called it, and a time stamp. --Q.

Quentin · ‎08-24-2012

Hi, Follow-up note about my PROC PRINTTO suggestion. As I understand it, when SPWA detects an error in the log, it pushes html code with the "This request completed with errors... " message to _webout (I think). So even with PROC PRINTTO redirecting most of the log file, if you use ods rtf or tagsets.excelxp, and there are errors in your program, looks like that html code gets appended to your output file. With tagsets.ExcelXP, I ended up with an xml file that should end at </Workbook>, but ends up with the html after it: </Row> </Table> </Worksheet> </Workbook> <h1>Stored Process Error</h1><h3>This request completed with errors.</h3> <script type="text/javascript">/*<![CDATA[*/ function SAS_toggleLog() { var button, content, SASLogDisplay; button = document.getElementById("SASLogbutton"); content = document.getElementById("SASLog"); SASLogDisplay = content.style.display; if (SASLogDisplay == "none") { content.style.display = "inline"; button.value="Hide SAS Log"; } else { content.style.display = "none"; button.value="Show SAS Log"; } } /*]]>*/</script> <form> <input id="SASLogbutton" class="button" type="button" onclick="SAS_toggleLog();" value="Show SAS Log" /> You can see the same junk at the end with ods rtf when SAS code has errors. Word seems happy to ignore the extra html when opening the rtf. Excel 2003 won't open the xml file. I don't know how to check the PDF file to see if this junk is there as well, but it opens fine. In the log checking blog post I linked to, this problem is avoided because when the log checker finds errors in the log, it does not stream the (rtf/pdf/whatever) report back to the user, and instead gives them a custom error report. --Q.

Quentin · ‎08-23-2012

Hi Scott, Often I find it's easiest to just use PROC PRINTTO to write the log somewhere, and then read it in your favorite text editor. The downside of this is that this completely redirects the log, so if you specify "show log" or &_debug=131 or whatever, you will only see the log up until proc printto was called. (Would be nice if you could avoid this by using OPTIONS ALTLOG in a SAS session rather than PRINTTO, but only works at invocation) I think the benefits to having the full log in a flat file are worth it. For example, you can do automated log scanning. Can also keep an archive of log files, helpful when you have multiple users running stored processes you developed, who might call you tomorrow to say that they got a weird result from a report they ran last week... --Q.

Quentin · ‎08-20-2012

Hi, I don't understand what you mean by executed normally vs executed via a stored process. Can you explain a bit more? Is the code executed by Enterprise Guide in each scenario? Are you saying you have a stored procedure, and the source code of the stored procedure %includes some other code? And you want to tell if that second bit of code has been %included by a stored process or not? Thanks, --Q.

Quentin · ‎08-20-2012

Thanks Alex, Agree, your solution of having a dynamically generated odbc.ini file (ideally based on a SAS dataset which developers can easily add records to), is a good one. Or the admins might be more comfortable if they wrote the tool, and forced us to type into ito it. I could even live with having the non-data driven approach, as long there is agreement that it's reasonable for SAS users to add to the odbc.ini file somehow.... --Q.

Quentin · ‎08-15-2012

Glad that modifying the tagset worked. Thank's for posting the code. SAS-L is a great resource.

Quentin · ‎08-14-2012

Hmmm, Sounds like tagsets.csv is writing the quotes around text values. I don't see an option for controlling that behavior. I suppose you could try modifying the tagset (or creating your own). Or may be easier to use a data _null_ step to write the csv file . HTH, --Q.

Quentin · ‎08-14-2012

Agree with Astounding's response. To understand what happens when you have a variable collission in a merge, you need to think in terms of the PDV, and when records are read into the PDV, when the PDV is initialized, etc. I think the bottom line is that variable collissions in a merge are BAD, and there is no rule that variables from the second dataset overwrite the first. I turn msglevel=i on to notify me of collissions, which I treat as an error (to be avoided with drop/keep/rename etc). I find the note to the log to be one of the most misleading messages that SAS produces, as it no doubt reinforces the belief that variables from the second dataset will overwrite the first, when in fact you can end up with a mix of the two. Using Art's data with msglevel=i turned on: 52 options msglevel=i; 53 data want1; 54 merge ds1(in=in1) ds2(in=in2); 55 by id; 56 run; INFO: The variable category on data set WORK.DS1 will be overwritten by data set WORK.DS2. NOTE: There were 8 observations read from the data set WORK.DS1. NOTE: There were 2 observations read from the data set WORK.DS2. NOTE: The data set WORK.WANT1 has 8 observations and 2 variables.

Quentin · ‎08-08-2012

Thanks Tom, I agree that it is very nice having the code, log, and results incorporated into a project! And data, and flat files, and.... Just to me, I would prefer to have the option of incorporating the log into the project as a link (just as I incorporate code, data, stored processes, and flat files via links), rather than actually having the log stored in the .egp file. --Q.

Quentin · ‎08-08-2012

Thanks Chris, That automation is definitely neat stuff, and it's a useful method for extracting the log from a project into a separate file. But still seems to me like it would be nice to have an option to just write the log (or a copy of the log) to a file by default. --Q.

Quentin · ‎08-08-2012

Hi All, Wondering if users (or developers) would see much benefit of adding an option to have EG store the log (or project log) as a txt file (.log) outside of the .egp file. Seems like over time EG has been moving from saving stuff (code, data) inside the actual project file (.egp) to having mostly links in the project file to files sitting elsewhere (code, data, stored processes). I like that. As someone who is used to running DMS / batch SAS, I'm used to having a text log file from my jobs. It's nice for archiving, for log scanning, etc. Obviously PROC PRINTTO is an option in EG, but then you don't see the log. Since -ALTLOG can only be specified at start-up, it can't really help when EG connects to a server and users want to specify where the log is sent. I would LOVE to be able to specify options ALTLOG= ; within a session. So I think it would be nice to have an option to have the log automatically written to a .log file, and just have a link to that log file in the project. Would be interested to hear what others think. Or please let me know if there is already a way to set this up. I'm still new to EG. Only recently discovered that I could actually view both a program and log at the same time, thanks to a bi-notes.com post from Sunil Gupta: http://http://www.bi-notes.com/2012/02/sas-enterprise-do-you-know-its-top-three-unknown-benefits/ Almost feels like using DMS SAS... Thanks, --Q.

Quentin · ‎08-07-2012

Thanks much Vince, that does the trick, and is a better approach than any of the 3 options I proposed. Guess I need to spend more time reading through the definition of %stpbegin to see how it is parameterized. Effectively, there already is a body= parameter that defaults to _webout. But since %stpbegin doesnt have any parameters defined :smileyalert:, it's taken from &_ODSOPTIONS. After reading your solution, it of course becomes clear as day. (Below snippets from %stpbegin() with my comments added): %*Figure out if user has specified an output file in &_ODSOPTIONS; %let TEMPSTR=%qupcase(%qcmpres(%bquote(&_ODSOPTIONS))); %if (%index(&TEMPSTR, BODY=) GT 0) or (%index(&TEMPSTR, BODY 😃 GT 0) or (%index(&TEMPSTR, FILE=) GT 0) or (%index(&TEMPSTR, FILE 😃 GT 0) %then %let BODYFLAG=1; .... %*If user is streaming output and has not specified an output file, send stream to _webout; %else %if (%qupcase(%qcmpres(&_RESULT)) eq STREAM) and (&BODYFLAG eq 0) %then %do; %let ODSOPT=&ODSOPT body=_WEBOUT; %end;

Quentin · ‎08-06-2012

Hi, This could be a crazy idea, but I'm was wondering if I could hijack _webout to send results to a file instead of the browser, when using %stpbegin/%stpend. So far, seems like the answer is no. Asked another way, suppose I want to write results to a file on the server (pdf/html/rtf), rather than stream them to a browser, when a user runs a stored process (through SPWA). I see 3 possibilities: 1. Wanting to use %stpbegin/%stpend in the stored process, was thinking I would try just redirecting the _webout fileref to point to a file. But clearly _webout is more than your typical fileref. So filename _webout "~/somewhere/myfile.htm" fails. Is there a way to hijack _webout? 2. Assuming I can't redirect _webout, another option would be to redefine %stpbegin(), adding a parameter for body= which would default to _webout, but allow the developer to specify an altenative. So %stpbegin(body="~/somewhere/myfile.htm") or something like that. But then there is part of me that hates the idea of putting a revised definition of %stpbegin() in my personal/project autocall library to replace the SI provided macro. Because anyone who sees %stpbegin() will assume it's calling the usual %stpbegin, and of course SAS will likely keep expanding the functionality of %stpbegin() over time. 3. Which makes me think I'll just write my own, limited, alternative to %stbegin(). A simple macro that would generate an ODS &_odsdest statement, sending results to a user-specified file, with user-specified options. Benefit of this approach is that I have control (and understanding) of what it does. But down side is I would potentially miss out on some of the magical possibilities of %stpbegin(). Currently I've been playing with #3, but was wondering if #1 is possible, or if people would share my concerns about #2. Thanks, --Q.

Online Status	Offline
Date Last Visited	yesterday

Re: How to Reg on each row?! with Slope/Intercept saved out?!

Re: How to Reg on each row?! with Slope/Intercept saved out?!

Re: Report with 1000 days from now

Re: problem with ODS in SAS EG 8.3

Re: problem with ODS in SAS EG 8.3

Re: Create a catalog table

Re: Combine the coding on arrays in the same data step

Re: How to use a macro variable in a if else condition

Re: How to use a macro variable in a if else condition

Re: SAS macro in conjunction with PROC PYTHON

Re: SAS 9.4M8 and Git Integration

Re: VALIDVARNAME=V7

Re: How to Reg on each row?! with Slope/Intercept saved out?!

Re: sending emails from sas

Re: PROC COMPARE label attribute is missing

Re: Use of Infile and Input statements

Re: SAS macro in conjunction with PROC PYTHON

Re: send email +attach log file only in case of error or warning

Re: chart representing thestructure of data

Re: send email +attach log file only in case of error or warning

Re: Should we install the Add-In?

Re: X CScript

Re: How can I view the SAS log from the stored process web application...

Re: How can I view the SAS log from the stored process web application...

Re: How can I view the SAS log from the stored process web application...

Re: Detect if code is running in stored process

Re: Create libname pointing to SQL server database

Re: stpsrv_header used to export file, but it has double quotes around...

Re: stpsrv_header used to export file, but it has double quotes around...

Re: strange merge issue

Re: Suggestion: Enable EG to store log (or project log) as an external...

Re: Suggestion: Enable EG to store log (or project log) as an external...

Suggestion: Enable EG to store log (or project log) as an external .lo...

Re: Can I hijack _webout?

Can I hijack _webout?

SAS Inner Circle Panel

SUGA

SAS User Groups

SAS Global Forum 2017

SAS Explore