Hi All, I'm trying to write a stored process that will read in a MS Access file, and make some plots.  I'm stuck on how to read in the access file. The SAS server is a linux box, and we have SAS/ACCESS to PC files.  We don't have SAS/SHARE. The access file is sitting on a windows file server. Questions: 1. With this set up, am I forced to have the stored process upload the file from the windows server to the SAS server, so that the stored process can see the data? (I think so, but didn't know if there is some way to magically span the gap between windows and linux by using an infomap or DI studio or registering a libref or....) 2.  If I do need to upload the file, is there a way to set up a prompt to upload a file (using EG 4.3)  without writing my own html form?  http://support.sas.com/documentation/cdl/en/stpug/61271/HTML/default/viewer.htm#a003254547.htm (I like the logic and capabiliies that come with the prompting structure, don't really wan't to give all that up, or have to replicate it myself, just to upload a file).  I thought maybe I could just use SAS to create the standard prompt interface, then I could modify that by adding a little html.  But reading a bit, quickly became confused as to how I would go about that (quickly got over my head reading about javascript, and somewhere saw that I might need to re-register code and restart servers and oh my...) I think long term the best solution is for me to talk folks out of using Access and getting their data into a real database.  But in the mean time, there is a lot of Access data floating around, which I would like to be able to report on. Thanks, --Q. ... View more

Hi All, Short question: Why does the open() function apparently unquote macro variables. For example: 340  %put %sysfunc(open  (in(where=(var="%nrstr(%Something)")))); WARNING: Apparent invocation of macro SOMETHING not resolved. 0 The user has quoted the value because %Something is a text string, not a macro invocation, but the open function is unmasking it, producing the warning message. (The result is still fine). Compare the above result to the length() function, which does NOT unmask the value (expected behavior). 341  %put %sysfunc(length(in(where=(var="%nrstr(%Something)")))); 28 In this simple case of course user could change the code to use single quotes to hide the percent sign:   %put %sysfunc(open(in(where=(var='%Something'))); But wondering if people agree that it is odd that open() is unquoting, and if there is a way to prevent this.  It feels like a bug to me, does it to you? Longer version/background: This came up because an autocall library had a %nobs macro, something like: %macro nobs(data);   /*macro function in autocall library to return # obs in a dataset*/ %local nobs dsid rc; %let dsid=%sysfunc(open(&data)); %let nobs=%sysfunc(attrn(&dsid,NLOBSF)); %let rc=%sysfunc(close(&dsid)); &nobs %mend nobs; User wrote a macro like: %macro report(data=,type=); %if %nobs(&data(where=(type="&type")))=0 %then %do;   data _null_;     file print;     put "There were no records in &data with type=&type";   run; %end; %else %do;   title1 "Printout of &data where Type=&Type";   proc print data=&data;       where type="&type";   run;   title1; %end; %mend report; And got the warning message when they ran: data test; input Year Type $14. Value; cards; 2001 AbsoluteChange 10 2002 AbsoluteChange 20 2003 AbsoluteChange 30 2001 %Change        5 2002 %Change        10 2003 %Change        15 ; run; %report(data=test,type=%nrstr(%Change)) So the user deduces that it is %nobs which is unmasking the percent sign in %Change, and calls the guy who maintains the autocall library and asks him to fix it.  But I don't see how %nobs can be fixed to avoid this problem.  Given the number of %nobs (and other) macro functions that are floating around autocall libraries that use the open function, was wondering if anyone had a good fix. If not, I guess I'm stuck adding a limitation to every macro that uses the open() function to say that it will unquote values, and telling the user to redesign %report. Thanks, --Quentin ... View more

Hi All, Despite having spent ~15 years writing SAS programs for myself, and SAS macros for myself and other SAS programmers, I have never done any real application development.  And I want that to change, so I'm looking for suggestions on where a complete newbie should start. Scenario: Say I'm a SAS programmer, working in a clinical trial group.  My job is to facilitate trial monitoring.  So every (day/week/month/whatever) I run a trial monitoring report (tables/figures/listings showing accrual, participant demographics, folllow-up rate, whatever), and save it (pdf) to a network drive where the trial team (statistician, project manager, regulatory, etc) can review it. Goal: Move from this system (where I am running these reports via a scheduled task or whatever), to developing an application, which will allow users to submit jobs to a SAS server that will generate canned reports, or their own custom reports, or live dashboards, or data extracts, or whatever.  All of the users are in-house, so I don't need to worry about folks connecting via internet, and related security. The users will not be programmers, so hoping to develop a simple user interface (could be just  a web page).  The users will not have SAS licenses. Limitations: I know SAS, and basic html, but not much more.  So while I'm excited to start learning something new, I'd appreciate a solution that will allow me to be at least minimally effective without spending months learning new language(s). It seems SAS has a number of different solutions for this sort of work (SAS/AF, SAS/INTRNET, Enterprise Guide, Microsoft Office add-on, etc.).  I'm imagining the general approach will be to take my parameterized macros (%AccrualTable, %DemographicTable etc.), and set them up as stored procedures so that a naive user can pass values via a pretty dialogue box, and view/export results in a reasonable format.  So was hoping folks might have suggestions on pros/cons of different approaches, or a favorite SGF paper that might provide an entry point for me. Kind Regards, --Quentin ... View more